Egor Pasko wrote:
On the 0x2C0 day of Apache Harmony Tim Ellison wrote:
Gregory Shimansky wrote:
Nathan Beyer wrote:
There's a comment about this in the classlib README, that I just
found. It seems this is a dependency from the ICU 3.4 libraries.
There's been off an on talk about upgrading to the latest ICU release.
Maybe it has upgraded its dependencies.
I think this dependency doesn't come inherently from the 3.4 version of
ICU. It comes from the host which was used to compile ICU binaries.
Apparently it had libstdc++.so.5 as default stdc++ library. If ICU was
compiled on a more modern distribution, it would depend on version 6.
To get rid of this dependency ICU could be linked with libstdc++
statically.
Couldn't we also link in a reference to the library unversioned, and
pick up whatever the ldconfig has defined?
1. they are not compatible
Yes I also think that they aren't.
2. not only libICU uses libstdc++, DRLVM uses libstdc++-X too, where X
is 5 or 6, and the actual number depends on the GCC version, that
built DRLVM
Strictly speaking I think it depends on the distribution. GCC version
and libstdc++ version are defined by the distribution and the packaging.
The change from version 5 to 6 happened somewhere between gcc version
3.3.x to version 3.4.x but different distributions chose a different gcc
version to make a change.
3. to compile libstdc++ statically for non-x86 (for example, x86_64)
we need to compile libstdc++-X.a with -fPIC option by hand (because
it is a very rare configuration)
Gentoo has libstdc++_pic.a (e.g.
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.1.1/libstdc++_pic.a), maybe some
other distros have something similar, but I agree that it is not a rule
to have this static lib compiled with -fpic.
IMHO, the best way is to go (3) for snapshots and releases to make our
binaries independant of library version on the target system. But for
development needs the easiest way is to install both libstdc++-5 and
libstdc++-6.
I wouldn't want to separate development from snapshots and releases. If
there is no big reason it would be better to use the same environment
for development as the one we use for snapshots.
The problem is that I think we cannot distribute the binaries of it, but
we can download and build it at the build time in a way similar to what
DRLVM does to apr, apr-utils and log4cxx.
--
Gregory
