On 26/06/15 15:56, Ward Poelmans wrote:
On Fri, Jun 26, 2015 at 3:47 PM, Stolpe, Oliver
<oliver.sto...@bihealth.de> wrote:
Hello List,
I got another issue and wondered whether this is intentional or if there is
a workaround for this. I am using easybuild on a debian right now. A lot of
tools were compiled with the goolf-1.4.10 toolchain (GCC 4.7.2). When GCC is
loaded, the command `wget` doesn't work anymore:
$ wget
wget: missing URL
$ module load GCC/4.7.2
$ wget
wget: /tools/easybuild/software/GCC/4.7.2/lib64/libstdc++.so.6: version
`CXXABI_1.3.8' not found (required by
/usr/lib/x86_64-linux-gnu/libicuuc.so.52)
Same happens for GCC/4.8.3. It works with GCC/4.9.2. I really wondered if
this is intended behaviour. Thanks for any comments.
Hi Oliver,
That's because your Debian uses a newer GCC. Meaning: wget was
compiled with GCC-4.9 and if you load an older version of GCC, the
icuuc library will be looking for a symbol that did not yet exists in
that version of GCC. The only workaround here is to compile wget also
with EB, so that it can work with GCC/4.7.2. Or use a fully statically
linked version of wget.
Clashes between (older) version of base software are partially
unavoidable. The only real option is to have an environment completely
seperated from the distro libraries.
Well, there are other options, but they're not supported (yet) by EasyBuild.
The issue is caused by having an older libstdc++.so in $LD_LIBRARY_PATH
after loading the GCC/4.7.x module.
If GCC was built with RPATH linking by EasyBuild, there's no need to set
$LD_LIBRARY_PATH (in theory, there still are reasons to do so), and then
wget would break.
Same with static linking (which is a lot more difficult overal, e.g.
when building Python).
regards,
Kenneth
