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