Appended to this message is the result of building and testing GiNaC with "make check-TESTS". In summary, all three of the "runs" (run_exams, run_checks, run_times) failed although some of the subtests passed. Also appended are listings of the "exams.out", "checks.out", and "times.out" files. Here are some relevant system specs: OS: Windows XP gcc: gcc version 3.4.2 (mingw-special) ld: GNU ld version 2.15.91 20040904 installer package (for mingw tools): devcpp-4.9.9.2_setup.exe gdb: version 5.2.1 (from gdb-5.2.1-1.exe ) _mingw.h: #define __MINGW32_VERSION 3.7 w32api.h: #define __W32API_VERSION 3.2 bash (for environment variables & executing configure & make commands): GNU bash, version 2.05b.0(8)-release (i686-pc-cygwin) CLN: version 1.1.11 GiNaC: version 1.3.4 Hopefully, with my description of the problems someone can provide information on how to resolve them and perhaps clear up some other dubious points that this description suggests. Hopefully, the problems are even very simple to correct. I decided to build the readline library although I suppose I may have been able to use "cygreadline5.dll"; in fact a test (after I had partially built the readline library) suggested that this is likely so; I surmise that essential .dll linkage specifications tend to be more stable and universal (and compiler-independent) than are static library linkage specifications. (The static cygwin libraries were most likely built with an "ancient" gcc and I surmised that they probably would not be compatible with a more recent gcc's output -- I think I've tried linking to some of them before.) I also built the termcap library to use with the examples in the readline library build. First, I briefly describe the problems with CLN: In building CLN I had to do considerable finagling with the Makefiles. (Typically, as from earlier experience in building an earlier version of CLN and GiNaC, I had to temporarily comment out the mingw's make.exe so that Borland's make.exe (the next make.exe in PATH) would answer configure's question "checking whether make sets $(MAKE)" with the right answer: yes; the test with mingw's make.exe says "no", but "yes" seems to be the appropriate answer for mingw's make.exe. Also, I had to change "/cygdrive/c" to "C:" (and sometimes also "/usr/bin" to "C:/cygwin/bin") in the Makefile pathnames for build tools and libraries and add "--tag=CXX" to libtool lines, especially if I wanted to execute make in a subdirectory.) And I ran into one error with "make check" at "test_I_io", resulting in the output "Illegal number syntax" evidently from function read_number_bad_syntax() in "cl_read_err_bad.cc". But when I commented out that test for "test_I_io" in function test_I(), the "make check" run was otherwise fine. I also set up a run of only the "test_I_io" test and found that the error occurred when I compiled the tests modules with -O2 optimization, but the error did not occur when I compiled them with the no (i.e., -O0) optimization. I also tried to use gdb with tests.exe but found that I could not set breakpoints in cl_I_read.cc, cl_I_read_stream.cc, or cl_read_err_bad.cc even though I recompiled these modules with the "-g -O0" flags and then rebuilt "libcln.a" using these three rebuilt object modules. (I even tried removing these three modules from the library build and putting them in the "tests" directory, but I seem to have run into "order-of-initialization" problems as suggested in header file "cln/modules.h"; the linker error in this case was "C:/Dev-Cpp/lib/libmingw32.a(main.o)(.text+0x106):main.c: undefined reference to `WinMain@16'".) I also made sure the -s linker flag did not appear in the commands in building "libcln.a" as well as "tests.exe". (However, I surmise that libtool may be doing some rather mysterious things in getting "database" information from mysterious files; but in each case -s did not appear in the immediately subsequent g++ command line that I surmise is generated by libtool and that seemingly should be regarded as the unequivocal description of what g++ is doing to build "libcln.a".) I also set up a rebuild of tests.exe and used "drmingw tests.exe" and an intended exception/fault in "cl_read_err_bad.cc", but the stack traceback output I got seemed slightly erratic. (If I recall correctly, I think there was listed an extraneous call to cl_abort() before the call to read_number_bad_syntax().). I surmised later that the erratic output was probably due to the fact that most of the relevant object modules for tests.exe were built with -O2. I also set up a run to force linkage of tests.exe to link to the mpatrol library to see if the error could be due to heap-memory or C-memory-function errors, but even though I got a rather large, verbose, three-figure MB log file, that log file showed no memory errors. Unfortunately, read_number_bad_syntax() calls something like cl_abort() rather than returning control to the calling function with an error indication. As a result an after-failure call to an "outside hook" function cannot easily be made for setting breakpoints and examining variables with gdb -- note that gdb breakpoints _can_ be set in functions whose object modules are not a part of the CLN library. (But rebuilding the library after its input object modules have been built is rather time-consuming as well, discouraging experimentation.) So with the dependency of the test on using optimization (or not) in compiling and linking the "tests" modules, I figured the problem was probably connected with the "order-of-module-initialization" issues described in header file "cln/modules.h" (which issues are apparently dependent on optimization); and so I decided to proceed with building the readline libraries and GiNaC, and possibly come back to this issue with "test_I_io" later, depending on how successful I was with GiNaC. Problems with GiNaC: Because of earlier experience, I generally made modifications to all of GiNaC's Makefiles in accordance with the ideas discussed above for CLN. I also liberally listed library names (sometimes pathnames) for the various "LIBS" and "..._LIBS" variables (even though many of these variables are not used), and I included "-lstdc++ -lmingw32" for these variables because an earlier build of GiNaC suggested that they were needed. I figured that duplication of library names on command lines probably wouldn't hurt and the Makefiles could be more easily adjusted if necessary, if duplication problems did arise. And I decided I needed to copy "libreadline.5.dll" (and "libhistory.5.dll" even if not needed) to "C:\Dev-Cpp\bin", the binary folder for my mingw gcc 3.4.2 and other mingw tools. This "bin" is in my PATH variable used to search for executables. I also had to make several adjustments of to config.h to account for the fact that I actually did have a readline library even though configure said I didn't -- three macro variables should say I have readline and two should provide the version numbers. (I copied "libreadline.5.dll" to "C:\Dev-Cpp\bin" after I ran GiNaC's configure.) I also had to modify "ginsh_parser.cc" (in folder "ginsh") and "timer.h" and "timer.cpp" (in folder "check") to use header <ctime> and function clock() in place of header <sys/resource.h> and function getrusage(), which apparently are not in my mingw runtime libraries. I also commented out (with //) all the "#line" (presumably comment) lines in ginsh_parser.cc because a comment in an earlier version of GiNaC said some compilers may choke on them -- I was trying to make the setup as robust as possible. (By the way, ginsh.exe seems to be working as intended.) So after a horrendous amount of finagling and discovery of what works and what doesn't, I finally completed the "make check-TESTS" test for GiNaC. Since the problems don't seem to be obviously trivial, even if minor adjustments could fix them, I have decided to see if I can get some help on this. I could send a zip file of my most recently modified Makefiles (particularly the .rtf backup versions that have manual modifications highlighted in boldface) and modified .cc, .cpp, and .h files if anyone is interested. (I usually create the text-format Makefiles from the .rtf backup versions). I also use the "modified" time-stamps in backups with descriptive file names and output files to keep a chronological history of what I've tried. And I often use "touch -m --reference=..." to synchronize text versions with .rtf backup versions, which are easier to edit with WordPad. (A newly created "Makefile" from an .rtf backup is what I usually use as the reference in the touch command to synchronize the Makefile with its backup. And I often add date/time stamps in the file names for easy overviews in Windows Explorer with files sorted as to modified date/time. The date/time stamps in the file names also serve to keep the output file names distinct in a sequence of experimentally varied trial runs.) Richard Haney Here are the appended listings of files: make_check-TESTS_out.rtf: GiNaC will now take an exam with specific input (like a pupils' exam): examining several historic failures just out of paranoia........./exams.ref exams.out differ: char 39, line 2 FAIL: run_exams GiNaC will now run through some rather costly random consistency checks: checking consistency of numeric types.. passed checking consistency of symbolic functions.... passed checking symbolic matrix manipulations./checks.ref checks.out differ: char 153, line 6 FAIL: run_checks GiNaC will now run through some basic timings: timing commutative expansion and substitution.... passed size: 50 100 200 400 time/s: 0.19 0.719 3.109 13.8 timing Laurent series expansion of Gamma function.... passed order: 10 15 20 25 time/s: 0.16 0.51 2.49 9.349 timing determinant of univariate symbolic Vandermonde matrices./times.ref times.out differ: char 192, line 6 FAIL: run_times ====================================== 3 of 3 tests failed Please report to <ginac-list@ginac.de> ====================================== c:\Dev-Cpp\bin\make.exe: *** [check-TESTS] Error 1 exams.out: ----------several historic failures: Assertion failed: e.op(1).is_equal(_ex2), file indexed.cpp, line 701 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. checks.out: ---------consistency of numeric types: (no output) ---------consistency of symbolic functions: (no output) ---------symbolic matrix manipulations: Assertion failed: e.op(1).is_equal(_ex2), file indexed.cpp, line 701 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. times.out: -------commutative expansion and substitution: (no output) -------Laurent series expansion of Gamma function: (no output) -------determinant of univariate symbolic Vandermonde matrices: Assertion failed: e.op(1).is_equal(_ex2), file indexed.cpp, line 701 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. ==== end of message ==== __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Dear Richard and others, I won't be addressing most of your observations. I could have a small look if time permits, but am not going to promise anything. I did fix the bug that you found, though. Thank you for having submitted it. On Wed, 12 Jul 2006, Richard Haney wrote:
Assertion failed: e.op(1).is_equal(_ex2), file indexed.cpp, line 701
Assertion failed: e.op(1).is_equal(_ex2), file indexed.cpp, line 701
Assertion failed: e.op(1).is_equal(_ex2), file indexed.cpp, line 701
I would say that you can quite safely just delete this assertion. In CVS I fixed this bug so that even if "make check" is ran with assertions enabled, it will no longer cause this problem. Unfortunately, I'm not sure that I can do this for the 1.3 branch because it involves using some functions that are not present in the 1.3 branch to begin with. For developers: the problem was that in mul.cpp a few times get_all_dummy_indices was called instead of get_all_dummy_indices_safely. Best wishes, Chris
On Thu, Jul 13, 2006 at 06:21:20PM +0200, Chris Dams wrote:
Dear Richard and others,
I won't be addressing most of your observations. I could have a small look if time permits, but am not going to promise anything.
Actually, I've already submitted patches which solve most of portability issues, these patches are already in CVS (1.4 branch). I've attached two patches. First patch is for GiNaC 1.4. It solves solves "no readline" issue. Second one is for GiNaC 1.3 ("backport" from 1.4 branch) -- it contains *all* changes which make GiNaC compile on MinGW. -- All science is either physics or stamp collecting.
Dear Alexei, On Fri, 14 Jul 2006, Sheplyakov Alexei wrote:
I've attached two patches. First patch is for GiNaC 1.4. It solves solves "no readline" issue.
Second one is for GiNaC 1.3 ("backport" from 1.4 branch) -- it contains *all* changes which make GiNaC compile on MinGW.
Thank you! I have put these patches into CVS. Best wishes, Chris
Hello, On Wed, Jul 12, 2006 at 11:55:39AM -0700, Richard Haney wrote:
I decided to build the readline library although I suppose I may have been able to use "cygreadline5.dll"; in fact a test (after I had partially built the readline library) suggested that this is likely so; No. You'd better not mix Cygwin and MinGW libraries.
[snip]
In building CLN I had to do considerable finagling with the Makefiles. I don't think this is necessary. As a matter of fact, CLN builds with *unmodified makefiles* just fine. However, it is necessary to modify src/base/random/cl_random_from.cc. (see the attachment).
(Typically, as from earlier experience in building an earlier version of CLN and GiNaC, I had to temporarily comment out the mingw's make.exe so that Borland's make.exe GNU make (supplied with MinGW) works for me.
And I ran into one error with "make check" at "test_I_io", resulting in the output "Illegal number syntax" evidently from function read_number_bad_syntax() in "cl_read_err_bad.cc". This one fails for me too. I don't know why [yet]. Sorry, I'm not a CLN hacker...
[huge snip]
Problems with GiNaC:
[huge snip] I'm sorry to confuse you, but the only useful information in your report is: ----------several historic failures: Assertion failed: e.op(1).is_equal(_ex2), file indexed.cpp, line 701
I could send a zip file of my most recently modified Makefiles (particularly the .rtf backup versions that have manual modifications highlighted in boldface) and modified .cc, .cpp, and .h files if anyone is interested. Leaving aside weird format, I don't think staring through diffs of automatically generated files is a good idea.
Best regards, Alexei. -- All science is either physics or stamp collecting.
In building CLN I had to do considerable finagling with the Makefiles. I don't think this is necessary. As a matter of fact, CLN builds with *unmodified makefiles* just fine. However, it is necessary to modify src/base/random/cl_random_from.cc. (see the attachment).
Oops, I've forgotten to attach the patch. -- All science is either physics or stamp collecting.
Alexei, I wasn't aware of you having such a patch. Have you ever sent it to me? Sheplyakov Alexei wrote:
------------------------------------------------------------------------
--- src/base/random/cl_random_from.cc 2005-12-21 20:15:03.000000000 +0300 +++ src/base/random/cl_random_from.cc~ 2005-12-21 20:11:40.000000000 +0300 @@ -1,5 +1,9 @@ // random_state constructor.
+#if defined(_WIN32) +#include <windows.h> // for GetCurrentProcessId() +#endif + // General includes. #include "cl_sysdep.h"
@@ -11,12 +15,12 @@
#include "cl_base_config.h" #include "cl_low.h" +#include <cstdlib> // declares rand()
-#if defined(unix) || defined(__unix) || defined(_AIX) || defined(sinix) || (defined(__MACH__) && defined(__APPLE__)) || (defined(_WIN32) && defined(__GNUC__)) || defined(__BEOS__) +#if defined(unix) || defined(__unix) || defined(_AIX) || defined(sinix) || (defined(__MACH__) && defined(__APPLE__)) || (defined(__CYGWIN__) && defined(__GNUC__)) || defined(__BEOS__)
#include <sys/types.h> #include <unistd.h> // declares getpid() -#include <cstdlib> // declares rand()
#if defined(HAVE_GETTIMEOFDAY)
@@ -52,8 +56,20 @@
#endif
+#elif defined(_WIN32) +#include <sys/time.h> +#include <sys/timeb.h> + +inline uint32 get_seed (void) +{ + struct timeb timebuf; + ftime(&timebuf); + return cln::highlow32(timebuf.time, (long)(timebuf.millitm)*1000); +} + #endif
+ namespace cln {
// Counter, to avoid that two random-states created immediately one after @@ -64,10 +80,13 @@ { var uint32 seed_hi; var uint32 seed_lo; -#if defined(unix) || defined(__unix) || defined(_AIX) || defined(sinix) || (defined(__MACH__) && defined(__APPLE__)) || (defined(_WIN32) && defined(__GNUC__)) || defined(__BEOS__) +#if defined(unix) || defined(__unix) || defined(_AIX) || defined(sinix) || (defined(__MACH__) && defined(__APPLE__)) || (defined(__CYGWIN) && defined(__GNUC__)) || defined(__BEOS__) seed_lo = ::get_seed(); seed_hi = (rand() // zuf�llige 31 Bit (bei UNIX_BSD) bzw. 16 Bit (bei UNIX_SYSV) << 8) ^ (uintL)(getpid()); // ca. 8 Bit von der Process ID +#elif defined(_WIN32) + seed_lo = ::get_seed(); + seed_hi = (rand() << 8) ^ (uintL)(GetCurrentProcessId()); #elif defined(__atarist) seed_lo = highlow32(GEMDOS_GetDate(),GEMDOS_GetTime()); // 16+16 zuf�llige Bits seed_hi = XBIOS_Random(); // 24 Bit zuf�llig vom XBIOS, vorne 8 Nullbits
------------------------------------------------------------------------
But before commiting this, let me ask: is the handling of preprocessor macros really correct? In particular I'm wondering about your removal of one #if defined(__CYGWIN__) and the addition of an #if defined(__CYGWIN) in another place. I'm going to check this in to CVS ASAP if you can confirm that this won't break anything. Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hello, On Wed, Jul 19, 2006 at 11:09:13PM +0200, Richard B. Kreckel wrote:
I wasn't aware of you having such a patch. Have you ever sent it to me? I've posted something very similar to CLN list (in reply to MinGW user who could not compile CLN).
[snipped]
But before commiting this, let me ask: is the handling of preprocessor macros really correct? The original code treats system with
(defined (_WIN32) && defined (__GNUC__)) as an ordinary *NIX. But this assumption is wrong (e.g. MinGW defines both _WIN32 and __GNUC__, but has no <unistd.h> and getpid()), and checking for __CYGWIN__ would be more appropirate.
In particular I'm wondering about your removal of one #if defined(__CYGWIN__) in another place. The original version does not contain check for defined(__CYGWIN__) at all: $ grep src/base/random/cl_random_from.cc.bak -e '__CYGWIN__' [nothing]
I'm going to check this in to CVS ASAP if you can confirm that this won't break anything. I've tested the patch under GNU/Linux and ReactOS. It should work on *NIXes (the patch does not change *NIX-specific code) and Cygwin (because CYGWIN is treated as *NIX, as in the original version). That said, I have *not* tested my patch on Cygwin. And I won't be able to do this in near future...
Best regards, Alexei. -- All science is either physics or stamp collecting.
Sheplyakov Alexei wrote:
I've tested the patch under GNU/Linux and ReactOS. It should work on *NIXes (the patch does not change *NIX-specific code) and Cygwin (because CYGWIN is treated as *NIX, as in the original version). That said, I have *not* tested my patch on Cygwin. And I won't be able to do this in near future...
Your patch didn't apply because it wasn't from CVS, so I had to apply it manually. Please, give it a try. Thanks -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hello! On Mon, Jul 24, 2006 at 12:04:16AM +0200, Richard B. Kreckel wrote:
Your patch didn't apply because it wasn't from CVS, so I had to apply it manually. It looks like you failed to do this properly.
I've attached patch for cln_1-1 branch. In order to build from CVS I had to modify configure.ac and different m4 macros, see the second attached file. Best regards, Alexei. -- All science is either physics or stamp collecting.
Sheplyakov Alexei wrote:
Hello!
On Mon, Jul 24, 2006 at 12:04:16AM +0200, Richard B. Kreckel wrote:
Your patch didn't apply because it wasn't from CVS, so I had to apply it manually.
It looks like you failed to do this properly.
I've attached patch for cln_1-1 branch.
In order to build from CVS I had to modify configure.ac and different m4 macros, see the second attached file.
Okay, but these are new compared to <http://www.ginac.de/pipermail/ginac-list/2006-July/000863>. :-)
------------------------------------------------------------------------
diff --git a/src/base/random/cl_random_from.cc b/src/base/random/cl_random_from.cc index 0470a4e..e858473 100644 --- a/src/base/random/cl_random_from.cc +++ b/src/base/random/cl_random_from.cc @@ -1,4 +1,7 @@ // random_state constructor. +#if defined(_WIN32) +#include <windows.h> // for GetCurrentProcessId() +#endif
// General includes. #include "cl_sysdep.h" @@ -9,10 +12,6 @@ #include "cln/random.h"
// Implementation.
-#if defined(_WIN32) -#include <windows.h> // for GetCurrentProcessId() -#endif - #include "cl_base_config.h" #include "cl_low.h" #include <cstdlib> // declares rand() @@ -47,14 +46,12 @@ #endif #include <sys/times.h> extern "C" clock_t times (struct tms * buffer);
-namespace cln { inline uint32 get_seed (void) { var struct tms tmsbuf; var uint32 seed_lo = times(&tmsbuf); return seed_lo + tmsbuf.tms_utime + tmsbuf.tms_stime; } -} // namespace cln
#endif
@@ -62,14 +59,12 @@ #elif defined(_WIN32) #include <sys/time.h> #include <sys/timeb.h>
-namespace cln { inline uint32 get_seed (void) { struct timeb timebuf; ftime(&timebuf); return cln::highlow32(timebuf.time, (long)(timebuf.millitm)*1000); } -} // namespace cln
#endif
I assume these are not the reason for it failing. I've deliberately put get_seed into namespace cln.
------------------------------------------------------------------------
diff --git a/configure.ac b/configure.ac index a47ef2e..c2e0f7c 100644 --- a/configure.ac +++ b/configure.ac @@ -69,6 +69,14 @@ dnl check for build configurat dnl PACKAGE=cln dnl libtool wants PACKAGE +case $host_os in + *mingw32*) + AC_LIBTOOL_WIN32_DLL + ;; + *) + ;; +esac + dnl convince libtool to build win32 dll
Is this really the right place? Maybe updating libtool would be more appropiate?
AC_PROG_LIBTOOL dnl sets variable LIBTOOL
@@ -94,12 +102,12 @@ CL_VERSION_MAJOR=1 CL_VERSION_MINOR=1 CL_VERSION_PATCHLEVEL=12 dnl release version for cln/config.h, so it can be tested by the preprocessor -AC_DEFINE_UNQUOTED(CL_VERSION_MAJOR, $CL_VERSION_MAJOR) -AC_DEFINE_UNQUOTED(CL_VERSION_MINOR, $CL_VERSION_MINOR) -AC_DEFINE_UNQUOTED(CL_VERSION_PATCHLEVEL, $CL_VERSION_PATCHLEVEL) +AC_DEFINE_UNQUOTED(CL_VERSION_MAJOR, $CL_VERSION_MAJOR, [CLN major version]) +AC_DEFINE_UNQUOTED(CL_VERSION_MINOR, $CL_VERSION_MINOR, [CLN minor version]) +AC_DEFINE_UNQUOTED(CL_VERSION_PATCHLEVEL, $CL_VERSION_PATCHLEVEL, [CLN patchlevel version]) dnl concatenated release version CL_VERSION=$CL_VERSION_MAJOR.$CL_VERSION_MINOR.$CL_VERSION_PATCHLEVEL -AC_DEFINE_UNQUOTED(CL_VERSION, $CL_VERSION) +AC_DEFINE_UNQUOTED(CL_VERSION, $CL_VERSION, [CLN version]) AC_SUBST(CL_VERSION)
dnl @@ -151,8 +159,10 @@ CL_MACHINE([floating-point types and beh dnl dnl interfacing to GNU gmp (must be at least version 3) dnl -AC_ARG_WITH(gmp, [ --with-gmp use external fast low-level functions from GNU MP 3. - [default=yes]], ,with_gmp="yes") +AC_ARG_WITH(gmp, AS_HELP_STRING([--with-gmp], + [use external fast low-level functions from GNU MP 3 (default: yes).]), + with_gmp="$withval", + with_gmp="yes") if test "$with_gmp" = yes; then CL_GMP_H_VERSION if test "$cl_cv_new_gmp_h" = no; then with_gmp="no"; fi @@ -163,7 +173,7 @@ if test "$with_gmp" = yes; then fi if test "$with_gmp" = yes; then CL_GMP_SET_UINTD - AC_DEFINE(CL_USE_GMP) + AC_DEFINE(CL_USE_GMP, ,[Define if GNU MP library is available]) else AC_MSG_WARN([disabling external GNU MP library]) fi diff --git a/m4/c++-constructors.m4 b/m4/c++-constructors.m4 index 2eb9889..48df183 100644 --- a/m4/c++-constructors.m4 +++ b/m4/c++-constructors.m4 @@ -37,7 +37,7 @@ rm -f conftest* ]) if test "$cl_cv_cplusplus_ctorprefix" '!=' unknown; then ac_value='"'"$cl_cv_cplusplus_ctorprefix"'"' - AC_DEFINE_UNQUOTED(CL_GLOBAL_CONSTRUCTOR_PREFIX,$ac_value) + AC_DEFINE_UNQUOTED(CL_GLOBAL_CONSTRUCTOR_PREFIX,$ac_value, [Global ctor prefix]) AC_CACHE_CHECK(for the global destructors function prefix, cl_cv_cplusplus_dtorprefix, [ cat > conftest.cc << EOF @@ -63,7 +63,7 @@ rm -f conftest* ]) if test "$cl_cv_cplusplus_dtorprefix" '!=' none; then ac_value='"'"$cl_cv_cplusplus_ctorprefix"'"' - AC_DEFINE_UNQUOTED(CL_GLOBAL_DESTRUCTOR_PREFIX,$ac_value) + AC_DEFINE_UNQUOTED(CL_GLOBAL_DESTRUCTOR_PREFIX,$ac_value, [Global dtor prefix]) fi dnl Check whether the global constructors/destructors functions are file-scope dnl only by default. This is the case in egcs-1.1.2 or newer. @@ -93,7 +93,7 @@ fi rm -f conftest* ]) if test "$cl_cv_cplusplus_ctorexport" = yes; then - AC_DEFINE(CL_NEED_GLOBALIZE_CTORDTOR) + AC_DEFINE(CL_NEED_GLOBALIZE_CTORDTOR, ,[Define if global ctor/dtors are file-scope by default]) fi fi fi diff --git a/m4/general.m4 b/m4/general.m4 index 0c550af..3a0b403 100644 --- a/m4/general.m4 +++ b/m4/general.m4 @@ -129,6 +129,64 @@ AC_CANONICAL_HOST
AC_DEFUN([CL_CANONICAL_HOST_CPU], [AC_REQUIRE([CL_CANONICAL_HOST])AC_REQUIRE([AC_PROG_CC]) +AH_TOP([ +#ifndef _CL_CONFIG_H +#define _CL_CONFIG_H +/* CLN's idea about CPU model */ +#ifndef __i386__ +#undef __i386__ +#endif +#ifndef __m68k__ +#undef __m68k__ +#endif +/* NB: GCC def's __mips__ both on big-endian and little-endian systems. */ +#ifndef __mips__ +#undef __mips__ +#endif +#ifndef __mipsel__ +#undef __mipsel__ +#endif +#ifndef __mips64__ +#undef __mips64__ +#endif +#ifndef __sparc__ +#undef __sparc__ +#endif +#ifndef __sparc64__ +#undef __sparc64__ +#endif +#ifndef __alpha__ +#undef __alpha__ +#endif +#ifndef __hppa__ +#undef __hppa__ +#endif +#ifndef __arm__ +#undef __arm__ +#endif +#ifndef __rs6000__ +#undef __rs6000__ +#endif +#ifndef __m88k__ +#undef __m88k__ +#endif +#ifndef __convex__ +#undef __convex__ +#endif +#ifndef __ia64__ +#undef __ia64__ +#endif +#ifndef __x86_64__ +#undef __x86_64__ +#endif +#ifndef __s390__ +#undef __s390__ +#endif +]) +AH_BOTTOM([ +#endif /* _CL_CONFIG_H */ +]) + case "$host_cpu" in changequote(,)dnl i[4567]86 ) @@ -182,6 +240,7 @@ else fi ;; esac + dnl was AC_DEFINE_UNQUOTED(__${host_cpu}__) but KAI C++ 3.2d doesn't like this cat >> confdefs.h <<EOF #ifndef __${host_cpu}__ diff --git a/m4/gmp.m4 b/m4/gmp.m4 index 93bdc5d..5fc110b 100644 --- a/m4/gmp.m4 +++ b/m4/gmp.m4 @@ -62,5 +62,5 @@ #endif AC_MSG_ERROR([Don't know which C-type has sizeof $gmp_retval.]), AC_MSG_ERROR([cross-compiling - cannot determine])) ]) -AC_DEFINE_UNQUOTED($cl_gmp_demands) +AC_DEFINE_UNQUOTED($cl_gmp_demands, ,[sizeof(uintD) == sizeof(mp_limb_t)]) ]) diff --git a/m4/longdouble.m4 b/m4/longdouble.m4 index 069de22..72cecce 100644 --- a/m4/longdouble.m4 +++ b/m4/longdouble.m4 @@ -23,6 +23,6 @@ AC_TRY_COMPILE([ ], , cl_cv_c_longdouble=yes, cl_cv_c_longdouble=no)]) ]) if test $cl_cv_c_longdouble = yes; then - AC_DEFINE(HAVE_LONGDOUBLE) + AC_DEFINE(HAVE_LONGDOUBLE, ,[Define if compiler support long double type]) fi ]) diff --git a/m4/param.m4 b/m4/param.m4 index 2a6b07d..21a7b84 100644 --- a/m4/param.m4 +++ b/m4/param.m4 @@ -31,9 +31,9 @@ CC=`echo "$CC " | sed -e 's/-O //g'` fi AC_TRY_EVAL(ac_link) CC="$ORIGCC" -if test -s conftest; then +if test -s conftest${ac_exeext}; then echo "creating $cl_machine_file_h" - ./conftest > conftest.h + ./conftest${ac_exeext} > conftest.h if cmp -s "$cl_machine_file_h" conftest.h 2>/dev/null; then # The file exists and we would not be changing it rm -f conftest.h
Am I right assuming that the last hunk is the only non-cosmetic one? If that's the case I'm going to apply it to the branch (to be released RSN) and the rest to MAIN. Makes sense? -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
On Mon, Jul 31, 2006 at 11:34:59PM +0200, Richard B. Kreckel wrote:
In order to build from CVS I had to modify configure.ac and different m4 macros, see the second attached file.
Okay, but these are new compared to <http://www.ginac.de/pipermail/ginac-list/2006-July/000863>. :-)
As you have noticed, that patch was not for CVS version. I couldn't use it because of numerious auto* tools errors: $ autoreconf -iv autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: configure.ac: tracing autoreconf: running: libtoolize --copy Using `AC_PROG_RANLIB' is rendered obsolete by `AC_PROG_LIBTOOL' Putting files in AC_CONFIG_AUX_DIR, `autoconf'. libtoolize: `config.guess' exists: use `--force' to overwrite libtoolize: `config.sub' exists: use `--force' to overwrite libtoolize: `ltmain.sh' exists: use `--force' to overwrite autoreconf: running: /usr/bin/autoconf autoreconf: running: /usr/bin/autoheader autoheader: warning: missing template: CL_USE_GMP autoheader: Use AC_DEFINE([CL_USE_GMP], [], [Description]) autoheader: warning: missing template: CL_VERSION autoheader: warning: missing template: CL_VERSION_MAJOR autoheader: warning: missing template: CL_VERSION_MINOR autoheader: warning: missing template: CL_VERSION_PATCHLEVEL autoreconf: /usr/bin/autoheader failed with exit status: 1
------------------------------------------------------------------------
diff --git a/src/base/random/cl_random_from.cc b/src/base/random/cl_random_from.cc index 0470a4e..e858473 100644 --- a/src/base/random/cl_random_from.cc +++ b/src/base/random/cl_random_from.cc @@ -1,4 +1,7 @@ // random_state constructor. +#if defined(_WIN32) +#include <windows.h> // for GetCurrentProcessId() +#endif
// General includes. #include "cl_sysdep.h" @@ -9,10 +12,6 @@ #include "cln/random.h"
// Implementation.
-#if defined(_WIN32) -#include <windows.h> // for GetCurrentProcessId() -#endif - #include "cl_base_config.h" #include "cl_low.h" #include <cstdlib> // declares rand() @@ -47,14 +46,12 @@ #endif #include <sys/times.h> extern "C" clock_t times (struct tms * buffer);
-namespace cln { inline uint32 get_seed (void) { var struct tms tmsbuf; var uint32 seed_lo = times(&tmsbuf); return seed_lo + tmsbuf.tms_utime + tmsbuf.tms_stime; } -} // namespace cln
#endif
@@ -62,14 +59,12 @@ #elif defined(_WIN32) #include <sys/time.h> #include <sys/timeb.h>
-namespace cln { inline uint32 get_seed (void) { struct timeb timebuf; ftime(&timebuf); return cln::highlow32(timebuf.time, (long)(timebuf.millitm)*1000); } -} // namespace cln
#endif
I assume these are not the reason for it failing.
No, this is exactly the reason of compilation errors. First of all, <windows.h> *must* be the very first of the included files.
I've deliberately put get_seed into namespace cln. Then you should have done s/::get_seed/get_seed/g I've attached yet another variant of patch, it puts *all* definitions of get_seed into namespace cln.
------------------------------------------------------------------------
diff --git a/configure.ac b/configure.ac index a47ef2e..c2e0f7c 100644 --- a/configure.ac +++ b/configure.ac @@ -69,6 +69,14 @@ dnl check for build configurat dnl PACKAGE=cln dnl libtool wants PACKAGE +case $host_os in + *mingw32*) + AC_LIBTOOL_WIN32_DLL + ;; + *) + ;; +esac + dnl convince libtool to build win32 dll
Is this really the right place?
From the libtool manual: \begin{quote} -- Macro: AC_LIBTOOL_WIN32_DLL This macro should be used if the package has been ported to build clean dlls on win32 platforms. Usually this means that any library data items are exported with `__declspec(dllexport)' and imported with `__declspec(dllimport)'. If this macro is not used, libtool will assume that the package libraries are not dll clean and will build only static libraries on win32 hosts. This macro must be called *before* `AC_PROG_LIBTOOL', and provision must be made to pass `-no-undefined' to `libtool' in link mode from the package `Makefile'. Naturally, if you pass `-no-undefined', you must ensure that all the library symbols *really are* defined at link time! \end{quote} Note that CLN is *not* clean win32 dll [yet]...
Maybe updating libtool would be more appropiate? Updating libtool won't hurt. BTW, private copy of libtool.m4 is *evil*, isn't it?
AC_PROG_LIBTOOL dnl sets variable LIBTOOL
@@ -94,12 +102,12 @@ CL_VERSION_MAJOR=1 CL_VERSION_MINOR=1 CL_VERSION_PATCHLEVEL=12 dnl release version for cln/config.h, so it can be tested by the preprocessor -AC_DEFINE_UNQUOTED(CL_VERSION_MAJOR, $CL_VERSION_MAJOR) -AC_DEFINE_UNQUOTED(CL_VERSION_MINOR, $CL_VERSION_MINOR) -AC_DEFINE_UNQUOTED(CL_VERSION_PATCHLEVEL, $CL_VERSION_PATCHLEVEL) +AC_DEFINE_UNQUOTED(CL_VERSION_MAJOR, $CL_VERSION_MAJOR, [CLN major version]) +AC_DEFINE_UNQUOTED(CL_VERSION_MINOR, $CL_VERSION_MINOR, [CLN minor version]) +AC_DEFINE_UNQUOTED(CL_VERSION_PATCHLEVEL, $CL_VERSION_PATCHLEVEL, [CLN patchlevel version]) dnl concatenated release version CL_VERSION=$CL_VERSION_MAJOR.$CL_VERSION_MINOR.$CL_VERSION_PATCHLEVEL -AC_DEFINE_UNQUOTED(CL_VERSION, $CL_VERSION) +AC_DEFINE_UNQUOTED(CL_VERSION, $CL_VERSION, [CLN version]) AC_SUBST(CL_VERSION)
dnl @@ -151,8 +159,10 @@ CL_MACHINE([floating-point types and beh dnl dnl interfacing to GNU gmp (must be at least version 3) dnl -AC_ARG_WITH(gmp, [ --with-gmp use external fast low-level functions from GNU MP 3. - [default=yes]], ,with_gmp="yes") +AC_ARG_WITH(gmp, AS_HELP_STRING([--with-gmp], + [use external fast low-level functions from GNU MP 3 (default: yes).]), + with_gmp="$withval", + with_gmp="yes") if test "$with_gmp" = yes; then CL_GMP_H_VERSION if test "$cl_cv_new_gmp_h" = no; then with_gmp="no"; fi @@ -163,7 +173,7 @@ if test "$with_gmp" = yes; then fi if test "$with_gmp" = yes; then CL_GMP_SET_UINTD - AC_DEFINE(CL_USE_GMP) + AC_DEFINE(CL_USE_GMP, ,[Define if GNU MP library is available]) else AC_MSG_WARN([disabling external GNU MP library]) fi diff --git a/m4/c++-constructors.m4 b/m4/c++-constructors.m4 index 2eb9889..48df183 100644 --- a/m4/c++-constructors.m4 +++ b/m4/c++-constructors.m4 @@ -37,7 +37,7 @@ rm -f conftest* ]) if test "$cl_cv_cplusplus_ctorprefix" '!=' unknown; then ac_value='"'"$cl_cv_cplusplus_ctorprefix"'"' - AC_DEFINE_UNQUOTED(CL_GLOBAL_CONSTRUCTOR_PREFIX,$ac_value) + AC_DEFINE_UNQUOTED(CL_GLOBAL_CONSTRUCTOR_PREFIX,$ac_value, [Global ctor prefix]) AC_CACHE_CHECK(for the global destructors function prefix, cl_cv_cplusplus_dtorprefix, [ cat > conftest.cc << EOF @@ -63,7 +63,7 @@ rm -f conftest* ]) if test "$cl_cv_cplusplus_dtorprefix" '!=' none; then ac_value='"'"$cl_cv_cplusplus_ctorprefix"'"' - AC_DEFINE_UNQUOTED(CL_GLOBAL_DESTRUCTOR_PREFIX,$ac_value) + AC_DEFINE_UNQUOTED(CL_GLOBAL_DESTRUCTOR_PREFIX,$ac_value, [Global dtor prefix]) fi dnl Check whether the global constructors/destructors functions are file-scope dnl only by default. This is the case in egcs-1.1.2 or newer. @@ -93,7 +93,7 @@ fi rm -f conftest* ]) if test "$cl_cv_cplusplus_ctorexport" = yes; then - AC_DEFINE(CL_NEED_GLOBALIZE_CTORDTOR) + AC_DEFINE(CL_NEED_GLOBALIZE_CTORDTOR, ,[Define if global ctor/dtors are file-scope by default]) fi fi fi diff --git a/m4/general.m4 b/m4/general.m4 index 0c550af..3a0b403 100644 --- a/m4/general.m4 +++ b/m4/general.m4 @@ -129,6 +129,64 @@ AC_CANONICAL_HOST
AC_DEFUN([CL_CANONICAL_HOST_CPU], [AC_REQUIRE([CL_CANONICAL_HOST])AC_REQUIRE([AC_PROG_CC]) +AH_TOP([ +#ifndef _CL_CONFIG_H +#define _CL_CONFIG_H +/* CLN's idea about CPU model */ +#ifndef __i386__ +#undef __i386__ +#endif +#ifndef __m68k__ +#undef __m68k__ +#endif +/* NB: GCC def's __mips__ both on big-endian and little-endian systems. */ +#ifndef __mips__ +#undef __mips__ +#endif +#ifndef __mipsel__ +#undef __mipsel__ +#endif +#ifndef __mips64__ +#undef __mips64__ +#endif +#ifndef __sparc__ +#undef __sparc__ +#endif +#ifndef __sparc64__ +#undef __sparc64__ +#endif +#ifndef __alpha__ +#undef __alpha__ +#endif +#ifndef __hppa__ +#undef __hppa__ +#endif +#ifndef __arm__ +#undef __arm__ +#endif +#ifndef __rs6000__ +#undef __rs6000__ +#endif +#ifndef __m88k__ +#undef __m88k__ +#endif +#ifndef __convex__ +#undef __convex__ +#endif +#ifndef __ia64__ +#undef __ia64__ +#endif +#ifndef __x86_64__ +#undef __x86_64__ +#endif +#ifndef __s390__ +#undef __s390__ +#endif +]) +AH_BOTTOM([ +#endif /* _CL_CONFIG_H */ +]) + case "$host_cpu" in changequote(,)dnl i[4567]86 ) @@ -182,6 +240,7 @@ else fi ;; esac + dnl was AC_DEFINE_UNQUOTED(__${host_cpu}__) but KAI C++ 3.2d doesn't like this cat >> confdefs.h <<EOF #ifndef __${host_cpu}__ diff --git a/m4/gmp.m4 b/m4/gmp.m4 index 93bdc5d..5fc110b 100644 --- a/m4/gmp.m4 +++ b/m4/gmp.m4 @@ -62,5 +62,5 @@ #endif AC_MSG_ERROR([Don't know which C-type has sizeof $gmp_retval.]), AC_MSG_ERROR([cross-compiling - cannot determine])) ]) -AC_DEFINE_UNQUOTED($cl_gmp_demands) +AC_DEFINE_UNQUOTED($cl_gmp_demands, ,[sizeof(uintD) == sizeof(mp_limb_t)]) ]) diff --git a/m4/longdouble.m4 b/m4/longdouble.m4 index 069de22..72cecce 100644 --- a/m4/longdouble.m4 +++ b/m4/longdouble.m4 @@ -23,6 +23,6 @@ AC_TRY_COMPILE([ ], , cl_cv_c_longdouble=yes, cl_cv_c_longdouble=no)]) ]) if test $cl_cv_c_longdouble = yes; then - AC_DEFINE(HAVE_LONGDOUBLE) + AC_DEFINE(HAVE_LONGDOUBLE, ,[Define if compiler support long double type]) fi ]) diff --git a/m4/param.m4 b/m4/param.m4 index 2a6b07d..21a7b84 100644 --- a/m4/param.m4 +++ b/m4/param.m4 @@ -31,9 +31,9 @@ CC=`echo "$CC " | sed -e 's/-O //g'` fi AC_TRY_EVAL(ac_link) CC="$ORIGCC" -if test -s conftest; then +if test -s conftest${ac_exeext}; then echo "creating $cl_machine_file_h" - ./conftest > conftest.h + ./conftest${ac_exeext} > conftest.h if cmp -s "$cl_machine_file_h" conftest.h 2>/dev/null; then # The file exists and we would not be changing it rm -f conftest.h
Am I right assuming that the last hunk is the only non-cosmetic one? No. All of hunks (except the last one) are necessary to make auto* tools happy. The last hunk is the only win32-specific.
Best regards, Alexei. -- All science is either physics or stamp collecting.
Sheplyakov Alexei wrote:
As you have noticed, that patch was not for CVS version. I couldn't use it because of numerious auto* tools errors:
$ autoreconf -iv autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: configure.ac: tracing autoreconf: running: libtoolize --copy Using `AC_PROG_RANLIB' is rendered obsolete by `AC_PROG_LIBTOOL' Putting files in AC_CONFIG_AUX_DIR, `autoconf'. libtoolize: `config.guess' exists: use `--force' to overwrite libtoolize: `config.sub' exists: use `--force' to overwrite libtoolize: `ltmain.sh' exists: use `--force' to overwrite autoreconf: running: /usr/bin/autoconf autoreconf: running: /usr/bin/autoheader autoheader: warning: missing template: CL_USE_GMP autoheader: Use AC_DEFINE([CL_USE_GMP], [], [Description]) autoheader: warning: missing template: CL_VERSION autoheader: warning: missing template: CL_VERSION_MAJOR autoheader: warning: missing template: CL_VERSION_MINOR autoheader: warning: missing template: CL_VERSION_PATCHLEVEL autoreconf: /usr/bin/autoheader failed with exit status: 1
Oops, sorry. Last two times I tried to switch to system-provided auto* it turned out a nightmare. Before that, it had turned out a nightmare for Bruno. So, for the time being: $ make -f Makefile.devel configures Maybe the time would be ripe, now. I don't know.
------------------------------------------------------------------------
diff --git a/src/base/random/cl_random_from.cc b/src/base/random/cl_random_from.cc index 0470a4e..e858473 100644 --- a/src/base/random/cl_random_from.cc +++ b/src/base/random/cl_random_from.cc @@ -1,4 +1,7 @@ // random_state constructor. +#if defined(_WIN32) +#include <windows.h> // for GetCurrentProcessId() +#endif
// General includes. #include "cl_sysdep.h" @@ -9,10 +12,6 @@ #include "cln/random.h"
// Implementation.
-#if defined(_WIN32) -#include <windows.h> // for GetCurrentProcessId() -#endif - #include "cl_base_config.h" #include "cl_low.h" #include <cstdlib> // declares rand() @@ -47,14 +46,12 @@ #endif #include <sys/times.h> extern "C" clock_t times (struct tms * buffer);
-namespace cln { inline uint32 get_seed (void) { var struct tms tmsbuf; var uint32 seed_lo = times(&tmsbuf); return seed_lo + tmsbuf.tms_utime + tmsbuf.tms_stime; } -} // namespace cln
#endif
@@ -62,14 +59,12 @@ #elif defined(_WIN32) #include <sys/time.h> #include <sys/timeb.h>
-namespace cln { inline uint32 get_seed (void) { struct timeb timebuf; ftime(&timebuf); return cln::highlow32(timebuf.time, (long)(timebuf.millitm)*1000); } -} // namespace cln
#endif
I assume these are not the reason for it failing.
No, this is exactly the reason of compilation errors. First of all, <windows.h> *must* be the very first of the included files.
Uuuaaaaarrrrghhhhhllll!!!
I've deliberately put get_seed into namespace cln.
Then you should have done s/::get_seed/get_seed/g I've attached yet another variant of patch, it puts *all* definitions of get_seed into namespace cln.
You're so right. Thanks for pointing it out.
------------------------------------------------------------------------
diff --git a/configure.ac b/configure.ac index a47ef2e..c2e0f7c 100644 --- a/configure.ac +++ b/configure.ac @@ -69,6 +69,14 @@ dnl check for build configurat dnl PACKAGE=cln dnl libtool wants PACKAGE +case $host_os in + *mingw32*) + AC_LIBTOOL_WIN32_DLL + ;; + *) + ;; +esac + dnl convince libtool to build win32 dll
Is this really the right place?
From the libtool manual: \begin{quote} -- Macro: AC_LIBTOOL_WIN32_DLL This macro should be used if the package has been ported to build clean dlls on win32 platforms. Usually this means that any library data items are exported with `__declspec(dllexport)' and imported with `__declspec(dllimport)'. If this macro is not used, libtool will assume that the package libraries are not dll clean and will build only static libraries on win32 hosts.
This macro must be called *before* `AC_PROG_LIBTOOL', and provision must be made to pass `-no-undefined' to `libtool' in link mode from the package `Makefile'. Naturally, if you pass `-no-undefined', you must ensure that all the library symbols *really are* defined at link time! \end{quote}
Note that CLN is *not* clean win32 dll [yet]...
[And likely never will be, as far as ugly __declspec(dllexport) is concerned.] But now I'm confused: if it's not clean [yet], why include that macro?
Maybe updating libtool would be more appropiate?
Updating libtool won't hurt. BTW, private copy of libtool.m4 is *evil*, isn't it?
Sure it's evil. But it's saved me an awful lot of trouble in the past.
Am I right assuming that the last hunk is the only non-cosmetic one?
No. All of hunks (except the last one) are necessary to make auto* tools happy. The last hunk is the only win32-specific.
Okay, but as I mentioned: not all auto* tools are used. Anyway, thanks. -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
On Thu, Aug 03, 2006 at 12:24:53AM +0200, Richard B. Kreckel wrote:
Sheplyakov Alexei wrote:
As you have noticed, that patch was not for CVS version. I couldn't use it because of numerious auto* tools errors:
$ autoreconf -iv autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: configure.ac: tracing autoreconf: running: libtoolize --copy Using `AC_PROG_RANLIB' is rendered obsolete by `AC_PROG_LIBTOOL' Putting files in AC_CONFIG_AUX_DIR, `autoconf'. libtoolize: `config.guess' exists: use `--force' to overwrite libtoolize: `config.sub' exists: use `--force' to overwrite libtoolize: `ltmain.sh' exists: use `--force' to overwrite autoreconf: running: /usr/bin/autoconf autoreconf: running: /usr/bin/autoheader autoheader: warning: missing template: CL_USE_GMP autoheader: Use AC_DEFINE([CL_USE_GMP], [], [Description]) autoheader: warning: missing template: CL_VERSION autoheader: warning: missing template: CL_VERSION_MAJOR autoheader: warning: missing template: CL_VERSION_MINOR autoheader: warning: missing template: CL_VERSION_PATCHLEVEL autoreconf: /usr/bin/autoheader failed with exit status: 1
Oops, sorry. Last two times I tried to switch to system-provided auto* it turned out a nightmare. Before that, it had turned out a nightmare for Bruno. So, for the time being:
$ make -f Makefile.devel configures
Maybe the time would be ripe, now. I don't know.
[huge snip]
Okay, but as I mentioned: not all auto* tools are used. What is (was) the reason of that? Would you accept a patch which converts CLN build system to usual automake/autoconf/libtool?
Best regards, Alexei. -- All science is either physics or stamp collecting.
Sheplyakov Alexei wrote:
Okay, but as I mentioned: not all auto* tools are used.
What is (was) the reason of that? Would you accept a patch which converts CLN build system to usual automake/autoconf/libtool?
Let's ask undogmatically: What would be the reason for converting CLN? The user who wants to compile the library is confronted with the well-known configure / make / make install steps. So, there's adherance to quasi-standards. The developer will have to remember that Makefile.devel will have to be used instead of autoreconf. Big deal. It is already autoconfed and libtooled. The only thing is that it carries its own copy of some files, but that is (was?) for a good reason: It enabled us to actually create the configure script when we needed to despite disruptive changes in the macro repository in Debian/RedHat/whatever. Okay, so what about automake? CLN's sources are modularly structured in a deep hierarchy, not a flat or shallow one. If I'm not mistaken, converting it to automake would involve putting a Makefile.am in every directory (there are 107 of them) and having to list at least every .cc file (there are 854 of them). Quite frankly, the current scheme appears much more elegant. Sure I would accept a patch if it was lightweight and elegant and worked well. But I don't think I'm ever going to see one. And I'm sure that pursuing such a patch is not worth the effort since it would only save a couple of minutes of every aspiring maintainer (how many of these are there?). Let's go, fix some serious bugs elsewhere, instead. Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
On Thu, Aug 03, 2006 at 10:11:26PM +0200, Richard B. Kreckel wrote:
Sheplyakov Alexei wrote:
Okay, but as I mentioned: not all auto* tools are used.
What is (was) the reason of that? Would you accept a patch which converts CLN build system to usual automake/autoconf/libtool?
Let's ask undogmatically: What would be the reason for converting CLN? The point is to compile CLN easy not only on particular version of particular GNU/Linux distro.
The user who wants to compile the library is confronted with the well-known configure / make / make install steps. Before that one needs re-libtoolize the package (otherwise compilation fill fail). I don't think this step is well-known or easy.
So, there's adherance to quasi-standards. I'm not an expert at building libraries (and even if I were, I won't re-invent the wheel anyway), so I use tools written by others: libtool _and_ automake.
The developer will have to remember that Makefile.devel will have to be used instead of autoreconf. Big deal. Yes. Maintaining your private build system is not that easy.
It is already autoconfed and libtooled. Manully writing proper rules for libtool is a compilcated task. Rules in CLN's Makefile.in contain a lot of errors. For example,
LIBTOOL_COMPILE = $(LIBTOOL) --mode=compile %.lo : %.cc $(LIBTOOL_COMPILE) $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c $< Invoking make as make -j2 CC='distcc gcc' CXX='distcc g++' will result in cd src && make all make[1]: Entering directory `/tmp/obj/src' make SUBDIR=base make[2]: Entering directory `/tmp/obj/src' /bin/sh ../libtool --mode=compile distcc g++ -O -I../include -I/mnt/host/home/pc7135/varg/src/cln-1.1.12/include -I/mnt/host/home/pc7135/varg/src/cln-1.1.12/src/base -c /mnt/host/home/pc7135/varg/src/cln-1.1.12/src/base/cl_debug.cc /bin/sh ../libtool --mode=compile distcc g++ -O -I../include -I/mnt/host/home/pc7135/varg/src/cln-1.1.12/include -I/mnt/host/home/pc7135/varg/src/cln-1.1.12/src/base -c /mnt/host/home/pc7135/varg/src/cln-1.1.12/src/base/cl_debugout.cc libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' make[2]: *** [cl_debugout.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... The rule should be something like CXXCOMPILE = $(LIBTOOL) --tag=CXX --mode=compile %.lo: %.cc $(CXXCOMPILE) $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c $< But that is not the end of the story, since source dependencies are not taken into account: change some header file, and run make, wait for a while (due to recursive make) and nothing gets recompiled! Yet another example is using C compiler (instead of C++ one) when linking, this was the reason of many weird linker errors (see, e.g. http://www.ginac.de/pipermail/ginac-list/2005-October/000749.html) I think fixing such errors is even much more complicated then using automake.
The only thing is that it carries its own copy of some files, but that is (was?) for a good reason: It enabled us to actually create the configure script when we needed to despite disruptive changes in the macro repository in Debian/RedHat/whatever.
The library with obsolete libtool is going to FTBFS (in a very weird way), so what is the point of generating non-working configure script?
Okay, so what about automake? CLN's sources are modularly structured in a deep hierarchy, not a flat or shallow one. All of these object files end up linked into a single library, so in fact it is *flat*.
If I'm not mistaken, converting it to automake would involve putting a Makefile.am in every directory (there are 107 of them) Incorrect. BTW, there are already Makeflags files in (almost) every directory.
and having to list at least every .cc file (there are 854 of them). Yes, automake requires this (for good reason which is explained in the manual). Anyway, inserting the output of
Quite frankly, the current scheme appears much more elegant. IMHO that deeply recursive $(MAKE) SUBDIR=$(foo) with a lot of
find src -type f -name '*.cc' -or -name '*.h' into Makefile.am is not very compicated. directory-specific preprocessor flags is ugly. But that is a matter of taste, the problems are 1) It is not obvoius what file gets included by #include "cl_foo.h". 2) Re-compilation after changing a couple of files takes unnecessary long time.
Sure I would accept a patch if it was lightweight and elegant and worked well. It does work well, but it is not lightweight.
But I don't think I'm ever going to see one. And I'm sure that pursuing such a patch is not worth the effort since it would only save a couple of minutes of every aspiring maintainer (how many of these are there?). It would save _a lot_ of time for many CLN users.
Best regards, Alexei. -- All science is either physics or stamp collecting.
Sheplyakov Alexei wrote:
But I don't think I'm ever going to see one. And I'm sure that pursuing such a patch is not worth the effort since it would only save a couple of minutes of every aspiring maintainer (how many of these are there?).
It would save _a lot_ of time for many CLN users.
Sorry, I don't buy that. I estimate that about 90% of all CLN users take .rpm or .deb package from their distros. Of the remaining users, 90% do configure / make / make install, nothing more. Heck, they don't even read the INSTALL file! Of the remaining library users, only 10% fiddle with their own options or flags. Of these remaining 0.1%, nobody has ever complained about distcc not working (well, until two days ago, that is). Don't get me wrong: I very much appreciate your keen interest in making CLN more, well, easier to use for the casual autoconf hacker. But in my experience, hacking these scripts is an extremely time-consuming task and in my opinion not at all worth it. Case in point: your last patch that disabled shared libraries for MinGW turned out to be buggy -- not in theory, but in practice (check out the fixed version and believe me, it's needed, as silly as it looks). I was going to release CLN 1.1.12 and this issue has ruined my day until I realized how it interfered with a bug in certain autoconf versions. :-( For me, these scripts are simply a time-sink that keeps me away from more important tasks. If you wish to submit an elegant patch, you are welcome. But if you want me to apply it, you must also take the responsibility and assume maintainership of the build-system until the initial problems have been sorted out and fixed! Call me a bullhead, but otherwise a change in the build-system is not going to happen anytime soon. Best wishes -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
On Thu, Aug 03, 2006 at 10:11:26PM +0200, Richard B. Kreckel wrote:
Let's ask undogmatically: What would be the reason for converting CLN? The user who wants to compile the library is confronted with the well-known configure / make / make install steps.
The developer will have to remember that Makefile.devel will have to be used instead of autoreconf. Big deal.
Autoconf *can* be used without automake (e.g., one could write Makefile.in manually), and some major open-source projects (such as GCC and Mozilla) do use it in such a way (but CLN's Makefile.in is just wrong, see my previous mail). The reason why autoreconf fails is some buggy m4 macros used by CLN. So I wonder why you are insisting on not using standard tool (autoreconf) instead of fixing those macros? -- All science is either physics or stamp collecting.
On Thu, Aug 03, 2006 at 12:24:53AM +0200, Richard B. Kreckel wrote:
Note that CLN is *not* clean win32 dll [yet]...
[And likely never will be, as far as ugly __declspec(dllexport) is concerned.] __declspec is not really a problem. The actual problem is MAYBE_INLINE hack. On non-ELF platforms (such as Darwin, MinGW) it causes linker errors due to to multiple definition of the same symbol.
But now I'm confused: if it's not clean [yet], why include that macro? OK, let's skip it.
Best regards, Alexei. -- All science is either physics or stamp collecting.
Hi, again! Sheplyakov Alexei wrote:
On Mon, Jul 24, 2006 at 12:04:16AM +0200, Richard B. Kreckel wrote:
Your patch didn't apply because it wasn't from CVS, so I had to apply it manually.
It looks like you failed to do this properly.
I've attached patch for cln_1-1 branch.
In order to build from CVS I had to modify configure.ac and different m4 macros, see the second attached file.
I've applied all the hunks that I gathered were necessary and rolled a tarball. Could you, please, try if <ftp://ftpthep.physik.uni-mainz.de/pub/kreckel/cln-1.1.12-pre.tar.bz2> works on MinGW (statically only, I suppose)? Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
On Fri, Aug 04, 2006 at 12:11:35AM +0200, Richard B. Kreckel wrote:
I've applied all the hunks that I gathered were necessary and rolled a tarball. Could you, please, try if <ftp://ftpthep.physik.uni-mainz.de/pub/kreckel/cln-1.1.12-pre.tar.bz2> works on MinGW (statically only, I suppose)?
Thank you, Richard. It works (compiled and passed `make check'). Could you please apply this patch too? --- configure.ac.orig 2006-08-04 19:35:07.000000000 +0400 +++ configure.ac 2006-08-04 19:40:02.000000000 +0400 @@ -69,6 +69,15 @@ dnl PACKAGE=cln dnl libtool wants PACKAGE + +case $host_os in + *mingw*) + AC_DISABLE_SHARED + dnl Shared libraries are not supported on some platforms [yet] + ;; + *) + ;; +esac AC_PROG_LIBTOOL dnl sets variable LIBTOOL Best regards, Alexei. -- All science is either physics or stamp collecting.
Sheplyakov Alexei wrote:
Could you please apply this patch too?
[snip] Done. Thanks. -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
participants (4)
-
Chris Dams
-
Richard B. Kreckel
-
Richard Haney
-
varg＠theor.jinr.ru