September 2010 - CLN-list

CLN patch 1
by Jan private 15 Feb '11

15 Feb '11

Problem: MSVC creates different symbol names for 'extern "C" uint32 mulu32_high' when declared inside the cln namespace, and when defined inside it. Linking produces "unresolved external symbol" errors. ----- Which is allowed by the Standard (specifically, [dcl.link]). However, it also says: "At most one function with a particular name can have C language linkage. Two declarations for a function with C language linkage with the same function name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same function. Two declarations for an object with C language linkage with the same name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same object. [Note: because of the one definition rule (3.2), only one definition for a function or object with C linkage may appear in the program; that is, sucha function or object must not be defined in more than one namespace scope." ----- Solution: Moved declarations into global namespace and prefixed with cln_

4 6

Difficulty building rpm of CLN
by galen 22 Sep '10

22 Sep '10

I am working on an updated rpm of your library for PCLinuxOS. I was hoping for some assistance, as I am running out of ideas. I appreciated any attention you may offer to this problem. Thanks for this library. First of all, I can build the library successfully using ./configure, make, and make install. However, when I try to build it with a spec file, it comes up with all kinds of errors. I started with the spec PCLinuxOS spec file for 1.1.13, then looked for clues from Mandriva, Fedora and the included cln.spec.in. Here seems to be the environment created for building the rpm: + CFLAGS='-O2 -pipe -Wp,-D_FORTIFY_SOURCE=2 -fomit-frame-pointer -march=i586 -mtune=generic -fasynchronous-unwind-tables' + export CFLAGS + CXXFLAGS='-O2 -pipe -Wp,-D_FORTIFY_SOURCE=2 -fomit-frame-pointer -march=i586 -mtune=generic -fasynchronous-unwind-tables' + export CXXFLAGS + FFLAGS='-O2 -pipe -Wp,-D_FORTIFY_SOURCE=2 -fomit-frame-pointer -march=i586 -mtune=generic -fasynchronous-unwind-tables' Here are the errors when I build without any other modifications: checking whether build environment is sane... /usr/share/automake-1.11/am/depend2.am: am__fastdepCCAS does not appear in AM_CONDITIONAL /usr/share/automake-1.11/am/depend2.am: The usual way to define `am__fastdepCCAS' is to add `AM_PROG_AS' /usr/share/automake-1.11/am/depend2.am: to `configure.ac' and run `aclocal' and `autoconf' again. src/Makefile.am: Preprocessed Assembler source seen but `CCAS' is undefined src/Makefile.am: The usual way to define `CCAS' is to add `AM_PROG_AS' src/Makefile.am: to `configure.ac' and run `aclocal' and `autoconf' again. src/Makefile.am: Preprocessed Assembler source seen but `CCASFLAGS' is undefined src/Makefile.am: The usual way to define `CCASFLAGS' is to add `AM_PROG_AS' src/Makefile.am: to `configure.ac' and run `aclocal' and `autoconf' again. yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking how to run the C++ preprocessor... g++ -E ./configure: line 4759: CL_AS_UNDERSCORE: command not found ./configure: line 4760: CL_AS_NOEXECSTACK: command not found ./configure: line 4762: syntax error near unexpected token `autoconf' ./configure: line 4762: ` CL_CANONICAL_HOST(autoconf)' make: *** [config.status] Error 2 make: *** Waiting for unfinished jobs.... make: *** [Makefile.in] Error 1 error: Bad exit status from /home/galen/src/tmp/rpm-tmp.68019 (%build) RPM build errors: Bad exit status from /home/galen/src/tmp/rpm-tmp.68019 (%build) From this output, I've tried adding: echo 'AM_PROG_AS' >> configure.ac aclocal autoconf just before %configure. This leads to other errors which I'll gladly outline if necessary. Thank you for taking the time to read this, and any feedback would be appreciated. Galen

2 1

Conversion bug?
by Jens Vollinga 21 Sep '10

21 Sep '10

Hi, is there maybe a bug in the implementation of double_approx()? If I do something like #include <iostream> #include <cln/cln.h> using namespace std; using namespace cln; int main() { cl_F c = cl_F("1.23456789012345678901234567890_200"); cout << c << endl; cout << double_approx(c) << endl; return 0; } the second output gives only single precision (aka float_approx)! Regards, Jens

2 1

CLN patch 2
by Jan private 11 Sep '10

11 Sep '10

Hello Alexei, here is another hairy one. 1. Problem: MSVC does not tag "extern cl_private_thing cl_I_constructor_from_UL (uint32 wert);" in cln/number.h with the cln namespace because it is declared inside the body of an inlined function (symbol created is >>?cl_I_constructor_from_UL@@YAPAUcl_anything@cln@@K@Z<<) But cl_I_constructor_from_UL is defined inside cln namespace in cl_I_from_UL.cc (symbol created is >>?cl_I_constructor_from_UL@cln@@YAPAUcl_anything@1@K@Z<<) So we get unresolved external symbols on every assignment and constructor operation. 2. Solution (rather, work-around): Create an auxiliary function cln::cl_private_thing cl_I_constructor_from_UL (uint32 wert); outside of namespace cln which references cln::cl_private_thing cln::cl_I_constructor_from_UL(wert); Note: The attached patch is exemplary only. As soon as the method to solve this issue is agreed on, similar patches will have to be made for other constructors Best regards, Jan

1 0