Menu

#162 CDAT4.0 build issues (causing import cdms failure)

Robustness_issues
open
nobody
5
2014-08-16
2005-12-21
Mike Grant
No

Platform: RHEL WS3, FC2

When doing the standard express install, I ended up
with an installation that would fail to import cdms
(giving errors like "ImportError:
(blah)CDAT-4.0/lib/python2.4/site-packages/cdms/Cdunif.so:
undefined symbol: ZNSs4_Rep11_S_terminalE", as also
reported in bug #1103853). After some investigation, I
found this to be due to the stdc++ library not being
linked at any point in the build process (or at
runtime). There seemed to be two ways to fix this:
1) edit pysrc/python.sh and remove the --without-cxx
so that Python built with C++ support (and would load
the stdc++ libraries for you) - half tested, seemed to work
2) fix the exsrc build so that the stdc++ dependency
is acknowledged

I looked at option 2 a bit more because libnc-dap was
also failing to build fully with the express install.
When it tried to link ncdump, the link would fail due
to missing libstdc++ again (the static libdap.a requi
res it but ncdump is linked with gcc, so the stdc++
library isn't linked by default). The easiest way to
solve this appeared to be to remove the
--disable-shared arguments to configure in libdap.sh,
libnc-dap.
sh, libxml.sh (and also hdf.sh and curl.sh for good
measure) and build shared libraries instead of static
ones, thus incorporating the libstdc++ link requirement
in the .so file so that the runtime linker can sort it out.

I'm not sure exactly why CDAT doesn't build shared
libraries by default, but this seems like a pretty easy
fix if there's not a strong requirement for static
libraries.

Discussion


Log in to post a comment.