[CLN-list] Result of building cln-1.1.13 on pc (Windows XP) with cygwin

[Richard Haney]

Building cln-1.1.13 has a few nice improvements, but there were a few
build problems that required adjustments and reruns.

In summary, these facts are notable about the build process:

1. Configure ran in only about two minutes, and it was nice to note
that the old misleading problem with "checking whether make sets
$(MAKE)" was gone and in its place was a nice, unconfusing "... yes".]

2. The compile failure for "cl_random_from.cc" is now gone and the
library builds nicely thanks in part, apparently, to patch(es) from
Sheplyakov Alexei.

3. The "--disable-shared" option for configure seems desirable in a
cygwin/mingw environment, and in fact it seems a good idea for a
distributed version of CLN to make "--disable-shared" an automatic
default in such an environment.

4. The default value "/usr/bin/install -c" (without quotes) for INSTALL
in the Makefiles will cause "make install" for doc/Makefile to crash. 
An appropriate command-line override for INSTALL appears necessary.

5. The problem with "Illegal number syntax" at test "test_I_io" is
still present.

6. Is seems that all executables (.exe) get rebuilt when make is rerun,
regardless of whether changes have been made to dependent files.  In
particular, it seems that the Makefiles do not correctly specify the
extension .exe as part of the dependency information for the
executables.  For example, "exam" (not "exam.exe") is listed as part of
the value for PROGRAMS in tests/Makefile, and $(PROGRAMS) is provided
as a (collective) target for building excutables with $(LIBTOOL_LINK);
so it appears that make looks for the file "exam" rather that
"exam.exe" in deciding whether to rebuild "exam.exe" (which it "thinks"
is "exam"); since there is generally no file "exam", "exam.exe" always
gets rebuilt.  This consideration appears to apply to the executables
in directories "examples" and "benchmarks" as well.)

My initial configure command was:

CC=C:/Dev-Cpp/bin/gcc  CFLAGS="-O2  -finline-limit=1000 
-fno-exceptions"  CXX=C:/Dev-Cpp/bin/g++  CXXFLAGS="-O2 
-finline-limit=1000  -fno-exceptions"  INSTALL="C:/cygwin/bin/install
-c"  ./configure  --disable-shared  --prefix=C:/gnu/cln-1.1.13/gcc342 
&>  config_out.txt

but without the INSTALL=... argument and without the --disable-shared
option.

I did the CLN build without using the "--disable-shared" option because
I wanted to double-check the likelihood that no DLLs would be produced.
 Evidently, DLLs won't be produced in a cygwin/mingw environment.  (See
http://www.cebix.net/pipermail/ginac-list/2006-July/000865.html in
regard to no DLLs for GiNaC; it seems the same considerations apply to
CLN as well.  See also documentation for "a2dll" (for converting static
libraries to DLLs) in the "mingw-utils-0.3.tar.gz" distribution.  But
note also that the readline build does produce DLLs.  So, from this
test and the situation with GiNaC builds vis-a-vis DLLs, it seems
advisable that the "--disable-shared" option should also be used in a
cygwin/mingw environment in order to eliminate the unnecessary
duplicate build of objects for a shared library.  Perhaps configure
should be modified (in a future distribution) to provide this option as
a default for a cygwin/mingw environment.  Apparently, by the "a2dll"
documentation, even if someone were industrious enough to produce a DLL
for CLN, there is no need for separate object modules anyway in a win32
environment.  So even if DLL-building were supported in this
environment, very likely only one object module per C++ source module
would need to be built.)

Thus, my preference would be to add the "--disable-shared" option (for
the current cln-1.1.13) as shown above.

After correcting a problem with an inappropriate version of rm.exe
vis-a-vis "hidden" .lnk extensions (problem solved by rearranging the
order of directories in my PATH variable) and restarting from scratch,
"make" took an hour and 14 minutes to run (compiling a "shared" and a
"static" version of object modules for each source module).  So it
appears that configure's "--disable-shared" option would definitely be
useful.

I then ran "make check" and encountered the problem with "Illegal
number syntax" at test "test_I_io", as I did with previous builds of
CLN.  I then commented out the test "test_I_io" in tests/test_I.cc and
reran "make check" again, which not only rebuilt test_I.o and test.exe,
but seems to have also rebuilt all the other executables (.exe), in
directories tests , examples , and benchmarks .  It seems that the
Makefiles probably do not correctly specify the extension .exe as part
of the dependency information for the executables.

The resulting "make check" ran without error.

I then ran "make install", but found that make produced the following
error message while processing in directory doc:

/usr/bin/install -c -m 644 ./cln.info
C:/gnu/cln-1.1.13/gcc342/share/info/cln.info
process_begin: CreateProcess((null), /usr/bin/install -c -m 644
./cln.info C:/gnu/cln-1.1.13/gcc342/share/info/cln.info, ...) failed.
make (e=3): The system cannot find the path specified.
c:\Dev-Cpp\bin\make.exe[1]: *** [install] Error 3

So I reran the configure command line again, but this time with the
INSTALL=... argument as specified in the command line given above (but
without the "--disable-shared" option).  And then I reran "make
install" again and this time it ran to completion without errors
(determined by searching for the string "error" without case
limitations).

System specs:

OS:  Microsoft Windows XP Home Edition
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
_mingw.h: #define __MINGW32_VERSION 3.7
w32api.h: #define __W32API_VERSION 3.2
bash :  GNU bash, version 2.05b.0(8)-release (i686-pc-cygwin)
CLN:  version 1.1.13
computer:  Dell Inspiron 2650
processor:  x86 Family 15 Model 2 Stepping 7 GenuineIntel ~1495 Mhz
total physical memory (RAM):  384.00 MB

Best regards,

Richard Haney


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com