[bugfix] Actually compile in version info into the library.
src/base/cl_version.cc: don't #include "cl_sysdep.h", so the version info
actually gets compiled into the library.
Due to the changes introduced in 7da4d3ae ("build: switch to ordinary auto*
tools system") including "cln/version.h" after "cl_config.h" is no-op (yes,
this is intended).
benchmarks: time{catalan,euler,exp1,zeta3}.cc actually compile and work now.
These benchmarks use internal CLN functions. Even worse -- they expect to
find these functions in the global namespace. Declare internal CLN functions
in the namespace cln.
1. If a header file gets modified, all dependent stuff gets rebuilt.
No need for 'make clean' after each header modification, no more
spurious errors, no more spurious rebuilds.
2. No more errors due to redefined preprocessor, compiler, and linker
FLAGS.
3. Build scripts don't try to build every *.cc file which happen to
lurk in the source directory.
Replace CL_REQUIRE/CL_PROVIDE(cl_UP) with portable code.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
Replace CL_REQUIRE/CL_PROVIDE(cl_UP_no_ring) with portable code.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
Replace CL_REQUIRE/CL_PROVIDE(cl_UP_named) with portable code.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
Replace CL_REQUIRE/CL_PROVIDE(cl_UP_unnamed) with portable code.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
Get rid CL_REQUIRE/CL_PROVIDE(cl_F_epsneg), it is not really necessary.
Move static variables [SFDL]F_negative_epsilon into LF_negative_epsilon()
function (which is the only user of those variables) in order to avoid
possible static order initialization problems. While at it, make
LF_negative_epsilon() function static.
Get rid CL_REQUIRE/CL_PROVIDE(cl_F_epspos), it is not really necessary.
Move static variables [SFDL]F_epsilon into LF_epsilon() function (which
is the only user of those variables) in order to avoid possible static
order initialization problems. While at it, make LF_epsilon() function
static.
Get rid CL_REQUIRE/CL_PROVIDE(cl_F_leastneg), it is not really necessary.
Move static variables least_negative_[SFDL]F into least_negative_LF() function
(which is the only user of those variables) in order to avoid possible static
order initialization problems. While at it, make least_negative_LF() function
static.
Get rid CL_REQUIRE/CL_PROVIDE(cl_F_leastpos), it is not really necessary.
Move static variables least_positive_[SFDL]F into least_positive_LF() function
(which is the only user of those variables) in order to avoid possible static
order initialization problems. While at it, make least_positive_LF() function
static.
Get rid CL_REQUIRE/CL_PROVIDE(cl_F_mostneg), it is not really necessary.
Move static variables most_negative_[SFDL]F into most_negative_LF() function
(which is the only user of those variables) in order to avoid possible static
order initialization problems. While at it, make most_negative_LF() function
static.
Get rid CL_REQUIRE/CL_PROVIDE(cl_F_mostpos), it is not really necessary.
Move static variables most_positive_[SFDL]F into most_positive_LF() function
(which is the only user of those variables) in order to avoid possible static
order initialization problems. While at it, make most_positive_LF() function
static.
Get rid of CL_REQUIRE/CL_PROVIDE(cl_F_catalanconst_var).
Turn cl_[SDFL]F_catalanconst global variables into functions (which return
a reference to the static value) in order to avoid static initialization
order problems.
Get rid of CL_REQUIRE/CL_PROVIDE(cl_F_eulerconst_var).
Turn cl_[SDFL]F_eulerconst global variables into functions (which return
a reference to the static value) in order to avoid static initialization
order problems.
Turn cl_[SDFL]F_exp1 global variables into functions (which return a reference
to the static value) in order to avoid static initialization order problems.
Turn cl_[SDFL]F_ln10 global variables into functions (which return a constant
reference to the static value) in order to avoid static initialization order
problems.
Turn cl_[SDFL]F_ln2 global variables into functions (which return a constant
reference to the static value) in order to avoid static initialization order
problems.
Turn cl_[SDFL]F_pi global variables into functions (which return a constant
reference to the static value) in order to avoid static initialization order
problems.
Replace CL_REQUIRE/CL_PROVIDE(cl_GV_I) with portable code.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
Replace CL_REQUIRE/CL_PROVIDE(cl_GV_number) with portable code.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
Replace CL_REQUIRE/CL_PROVIDE(cl_SV_number) with portable code.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
Replace CL_REQUIRE/CL_PROVIDE(cl_SV_ringelt) with portable code.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
Get rid CL_REQUIRE/CL_PROVIDE(cl_fmt_scaleexp), it is not necessary.
Move a bunch of static objects (tenth, SF_zero, FF_zero, etc) into
the function get_float_params (which is the only user of those variables)
in order to avoid possible static order initialization problems.
Remove CL_REQUIRE/CL_PROVIDE(cl_I_doublefactorial) as it's unnecessary.
The only user of doublefakul_table array is doublefactorial function, so
put that array inside it in order to avoid possible static initialization
order problems.
Remove CL_REQUIRE/CL_PROVIDE(cl_I_factorial) as it's not really necessary.
factorial() is the only function which uses fakul_table[] array, so move
it into that function in order to avoid possible static initialization
order problems.
Replace CL_REQUIRE/CL_PROVIDE(cl_MI) with portable code.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
Replace CL_REQUIRE/CL_PROVIDE(cl_RA_ring) with portable code.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
Replace CL_REQUIRE/CL_PROVIDE(cl_I_ring) with portable code.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
Replace CL_REQUIRE/CL_PROVIDE(cl_R_ring) with portable code.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
Replace CL_REQUIRE/CL_PROVIDE(cl_LF_globals) with portable code.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
Replace CL_REQUIRE/CL_PROVIDE(cl_FF_globals) with portable code.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
While at it, remove work around for ancient (fixed in 8+ years) glibc/Linux
bug (the kernel and/or libc was initializing FPU into non-IEEE mode, so division
by 0 resulted in SIGFPE instead of NaN).
Replace CL_REQUIRE/CL_PROVIDE(cl_DF_globals) with portable code.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
Replace CL_REQUIRE/CL_PROVIDE(cl_C_ring) with portable code.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
Replace CL_REQUIRE/CL_PROVIDE(cl_symbol) with portable code.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
Replace CL_REQUIRE/CL_PROVIDE(cl_st_null) with portable code.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
Replace CL_REQUIRE/CL_PROVIDE(cl_no_ring) with portable code.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
Replace CL_REQUIRE/CL_PROVIDE(cl_random_def) with portable code.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
Replace CL_REQUIRE/CL_PROVIDE(cl_prin_globals) with portable code.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
replace CL_REQUIRE/CL_PROVIDE(cl_0_ring) with (more) portable code.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
Bruno Haible [Sat, 23 Feb 2008 18:06:32 +0000 (18:06 +0000)]
Change "make alls" and "make allo" to recurse into subdirectories.
* src/Makefile.in (alls-local): Renamed from alls.
(allo-local): Renamed from allo.
(SUBDIRS_TARGET_ALL): Renamed from SUBDIRS_TARGET.
(alls, allo): New rules.
(SUBDIRS_TARGET_ALLS, SUBDIRS_TARGET_ALLO): New variables.
Richard Kreckel [Mon, 4 Feb 2008 23:51:56 +0000 (23:51 +0000)]
Fix cl_F output of more than 2^32 decimal digits:
* src/base/string/cl_sstring.cc (cl_sstring): make len uintC.
* src/base/string/cl_sstring.h: Likewise.
git://www.ginac.de / cln.git / log