Hi,
On 06.08.12 14:34, "Kenneth Hoste" <[email protected]> wrote: > >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. 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 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 :) > > > >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. -----
