[GiNaC-list] about CLN versus win32 patch

[Richard B. Kreckel]

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/>