Bug #402
Problem with 64-bit BOOST on Linux (Werner)
Description
Werner says:./configure complains that it does not find some Boost libraries. I searched my system and I have Boost installed (at least I think so). Two of the mentioned libraries exist in the directory /usr/lib64; the third one also seems to exist but its name is extended by -mt on my system (in fact, it seems that I have two copies of most Boost libraries and one always has an additional -mt in its name).
Related issues
History
#1
Updated by John Abbott over 10 years ago
Updated by Output of ./configure command
[seiler@spencer CoCoALib-0.9953]$ ./configure Starting configuration process for CoCoALib... Using GMP version 5.0.2 with gmpxx at system default location Not using BOOST ==> compilation of CoCoA5+GUI disabled REASON: CoCoA-5 needs the following missing BOOST sublibraries: libboost_thread libboost_filesystem libboost_system The C++ compiler is g++ The C++ compilation flags are "-Wall -pedantic -fPIC -O2" OPTIONAL external libraries: Not using Frobby Not using GSL Not using Normaliz ------------------------------------------------------- CoCoALib configuration process complete Configuration info saved in file configuration/autoconf.mk Output of "make" (relevant parts) ================================= [seiler@spencer CoCoALib-0.9953]$ make ======================================================= Compiling CoCoALib-0.9953 CXX = g++ CXXFLAGS = -Wall -pedantic -fPIC -O2 CXXFLAGS_DEFINES = -DCoCoA_ULONG2LONG=1 ======================================================= [...] -------------------------------------------- *** Compilation of CoCoALib completed. *** -------------------------------------------- make[2]: Leaving directory `/home/seiler/CoCoA/CoCoALib-0.9953/src' make[2]: Entering directory `/home/seiler/CoCoA/CoCoALib-0.9953/doc' make[2]: Leaving directory `/home/seiler/CoCoA/CoCoALib-0.9953/doc' make[2]: Entering directory `/home/seiler/CoCoA/CoCoALib-0.9953/src/server' Compiling CoCoA4io.o Compiling SocketStream.o Compiling RegisterServerOps.o Compiling RegisterServerOpsUser.o Compiling RegisterServerOpsFrobby.o Compiling ServerOp.o Compiling CoCoAServer.o g++: Fehler: fehlendes Argument für »-L« make[2]: *** [CoCoAServer] Fehler 1 make[2]: Leaving directory `/home/seiler/CoCoA/CoCoALib-0.9953/src/server' make[1]: *** [server] Fehler 2 make[1]: Leaving directory `/home/seiler/CoCoA/CoCoALib-0.9953' make: *** [default] Fehler 2
#2
Updated by John Abbott over 10 years ago
I note that Werner's transcript reports a problem with an arg to -L.
Perhaps the configuration scripts do not work as they should when BOOST is deemed to be absent? JAA will investigate.
#3
Updated by John Abbott over 10 years ago
- Category set to Portability
- Status changed from New to In Progress
- Assignee set to John Abbott
JAA is considering simplifying the script for locating BOOST:
essentially it stops as soon as it finds an installation (first in the path).
If that installation is not sufficiently complete then it produces an error.
I suppose I could try to make it search for the first sufficiently complete installation? Seems trickier, and the extra complexity may not be worth it.
#4
Updated by John Abbott over 10 years ago
- % Done changed from 0 to 10
JAA has sent to Werner 4 modified files -- awaiting confirmation that they work for him.
The "solution" is a cheap hack (in the script boost-find-lib.sh); it might not work if there are both lib64 and lib versions of BOOST, and the user wants to the lib version -- this scenario could arise if a user wants to compile a 32-bit version on a 32+64 bit system. Is it worth trying to allow this?
There was also a stupid design decision in configure.
#5
Updated by John Abbott over 10 years ago
- % Done changed from 10 to 20
Werner reports that a quick check suggests that my hack works.
#6
Updated by John Abbott over 10 years ago
- Status changed from In Progress to Feedback
- % Done changed from 20 to 80
There was one true (design) error: I have now modified configure and fixed_part2 so that they are now sensible/correct.
I have added a hack to boost-find-lib.sh which looks for a lib64/ directory first, and uses it if it exists; otherwise its looks for lib/, and uses that. This will probably make it tricky to do a 32-bit build on a 32-64 platform (but is this really such a problem?).
I hope that 32-64 platforms will eventually be entirely supplanted by proper 64-bit platforms; at that point the hack will become a pointless waste of time.
#7
Updated by John Abbott over 10 years ago
- Status changed from Feedback to Closed
- % Done changed from 80 to 100
The matter was finally resolved via Skype -- an extra complication arose because Werner had an "anomalous" multiple installation of BOOST on his computer :-(
Regarding this issue as fully resolved, so closing.