On 08/03/2012 04:42 PM, Cédric LACZNY wrote:
Hello,
I just have a little comment to add to point 4 :)
On 03.08.12 16:25, "Fotis Georgatos" <[email protected]> wrote:
(4) Compiling/Linking against boost and such libraries
While building Cufflinks, Cedric came across this issue:
http://stackoverflow.com/questions/11688893/decoding-gcc-specs-file-line
To summarize what I understand, there is a subtle difference in the gcc
spec strings and we wonder if there is some funny interaction between
Debian/Easybuild/gcc; can you supply the following command from your side?
$ gcc -dumpspecs|grep -A1 multilib:
# Most RHEL clones give: . !m64 !m32;64:../lib64 m64 !m32;32:../lib !m64
m32;
(check it character-per-character, it's hard exercise for the human
reader)
Actually, there is no problem in the compilation of Cufflinks (we are
interested in the most recent version, being 2.0.2 IIRC). It is building
fine and linking correctly against the (by us) specified boost-version
1.50. Needed some patching and renaming, but this is nicely handled via
the easyconfig and easyblock.
The problem arised when I wanted to link against the as-a-dependency
easybuild-built boost version (1.50) with a simple C++ program. Even
though the easybuild does specify the LIBRARY_PATH environment variable
(set using make_module_req_guess() ) to point correctly to the "local"
libs (the easybuild ones, in opposite to the default system libraries),
when using the GCC with goalf (eventually coming from easybuild) the order
of the paths in LIBRARY_PATH is somehow mixed up thus making the gcc pick
the system libs (under /usr...) instead of the "local" libs (1.50).
Interestingly, using the dummy gcc does not cause this problem and uses
LIBRARY_PATH as it is found e.g. With the env command - no mix up seems to
occur.
If you wonder why Cufflinks worked fine: this is simply because it uses
"-L/with/boost/libs/dir" and this gets top-priority in linking, even
before LIBRARY_PATH.
I have seen an issue like this, but this was caused by one of the
Makefiles redefining LD_LIBRARY_PATH itself.
Other than this, I don't see why this would happen.
Can you collect verbose output when building the simple C++ program,
using -v?
It should spit out (a) whether it's trying to use the library found in
LD_LIBRARY_PATH, and (b) if it does, why it doesn't use it.
regards,
Kenneth
