hi cedric,
(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.
I will provide the output soon, but to my understanding, this is not
caused by LD_LIBRARY_PATH (used during runtime) but by LIBRARY_PATH (used
during compile time to tell where to look for suitable libraries).
LD_LIBRARY_PATH must contain the path of course during runtime too (e.g.
When using ldd on the binary).
I think that using "-L" in Makefiles (especially when using a mechanism
like autoconf) is a good idea to make sure the specified path (e.g. Coming
from a configure-provided option like "--with-boost") gets top priority
LIBRARY_PATH is only used when you link with gcc, it is ignored when
linking with eg ld (and -L takes preference on LIBRARY_PATH). most
software links with ld, but simple cases typiclaly use gcc
but for the purpose of providing an easybuild for a library that users may
then load, I think it is important to make sure that this can then be used
just like any other library on the system (e.g. Installed via a
package-manager from the distribution). This is basically the major
driving-point for me in this situation to make the whole setup as
transparent for the user as possible :)
actually it can't be used just like any other library on the system.
only linking with -L$SOFTROOTBOOST/lib will garantee the proper library
is used (and should be the only supported way, but i agree that this is
not easy with easybuild (eg try to guess the mkl path after you load the
ictce toolkit).
we will have some extra features in 0.9 (or later) to help with building
own software using easybuild installed libraries. details will follow ;)
but lets wait for the output of your case to see what is going on.
stijn
regards,
Kenneth
Best,
Cedric
Cedric Laczny,
PhD Student
UNIVERSITÉ DU LUXEMBOURG
LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
Campus Belval | House of Biomedicine
7, avenue des Hauts-Fourneaux
L-4362 Esch-sur-Alzette
T +352 46 66 44 6398
F +352 46 66 44 6949
[email protected] http://lcsb.uni.lu <http://lcsb.uni.lu/>
-----
This message is confidential and may contain privileged information. It is
intended for the named recipient only. If you receive it in error please
notify me and permanently delete the original message and any copies.
-----
