You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Wayne Beaton <wa...@eclipse.org> on 2007/04/22 15:39:20 UTC
Linux libstdc++.so.5 dependency
I recently tried running Harmony on a fresh installation of Debian Linux. It
failed, complaining that libstdc++.so.5 is not available. After a quick
search, I confirmed that libstdc++.so.5 is indeed not anywhere on the
machine, but libstdc++.so.6 is there.
As I understand it (and I'll admit I don't understand it well),
libstdc++.so.5 is considered legacy.
Should this dependency be updated, or is there some way to make the
dependency version agnostic?
Thanks,
Wayne
--
Wayne Beaton
The Eclipse Foundation
wayne.beaton@eclipse.org
Skype, YIM: waynebeaton
http://www.eclipse.org
http://wbeaton.blogspot.com/
http://www.planeteclipse.org/planet/
Re: Linux libstdc++.so.5 dependency
Posted by Mark Hindess <ma...@googlemail.com>.
On 24 April 2007 at 8:58, Tim Ellison <t....@gmail.com> wrote:
> Egor Pasko wrote:
> > To summarize the thread. We have several ideas on how to treat
> > libstdc++ diversity on various linux systems:
> >
> > 1. create both snapshots (libstdc++ 5 and 6 separately) plus a good
> > instruction for not-very-geeky users (like me:) on how to check what
> > version of libstdc++ you have on your system
>
> We just declare which distro the snapshot is designed to work on. I
> don't think we would expect users to seek out the libstdc++ version.
+1.
I'm just testing a change (and some new icu libs for x86 only) to add an
option to build with libstdc++6 - that is, "-Duse.libstdc++6=true".
What should the default be? Currently all the linux platform libs that
are checked in depend on libstdc++.so.5 but I'd be surprised if this
was still the most common version? (Of course, the fact that all the
platforms have been "independently" compiled and ended up like using
libstdc++.so.5 would imply that I'm wrong.)
> > 2. download libstdc++ and recompile it in our build, link in a way
> > whatever is convenient (does it need to tweak gcc afterwards?)
>
> Please, no.
Agreed. This would make the install considerably more error prone and
time consuming. ;-)
> > not many ideas. I would appreciate comments and final decisions on this.
>
> I think we declare the snapshot's intended target, then it becomes a
> community issue of whether we have people who are willing to provide a
> snapshot configuration on a given disro.
-Mark.
Re: Linux libstdc++.so.5 dependency
Posted by Tim Ellison <t....@gmail.com>.
Egor Pasko wrote:
> On the 0x2C2 day of Apache Harmony Tim Ellison wrote:
>> Egor Pasko wrote:
>>> To summarize the thread. We have several ideas on how to treat
>>> libstdc++ diversity on various linux systems:
>>>
>>> 1. create both snapshots (libstdc++ 5 and 6 separately) plus a good
>>> instruction for not-very-geeky users (like me:) on how to check what
>>> version of libstdc++ you have on your system
>> We just declare which distro the snapshot is designed to work on. I
>> don't think we would expect users to seek out the libstdc++ version.
>
> OK, agreed, that should work well in most cases
>
> do I get it right that we should get ICU sources and rebuild them in
> the distro we are providing snapshots for?
Yes, since we seem to require the very latest ICU versions it is
probably best that we continue to build and distribute them, at least
for the moment. That would mean that we build a copy with c++ 5 and a
copy with c++ 6 separately.
Regards,
Tim
Re: Linux libstdc++.so.5 dependency
Posted by Mark Hindess <ma...@googlemail.com>.
On 24 April 2007 at 14:28, Egor Pasko <eg...@gmail.com> wrote:
> On the 0x2C2 day of Apache Harmony Tim Ellison wrote:
> > Egor Pasko wrote:
> > > To summarize the thread. We have several ideas on how to treat
> > > libstdc++ diversity on various linux systems:
> > >
> > > 1. create both snapshots (libstdc++ 5 and 6 separately) plus a good
> > > instruction for not-very-geeky users (like me:) on how to check what
> > > version of libstdc++ you have on your system
> >
> > We just declare which distro the snapshot is designed to work on. I
> > don't think we would expect users to seek out the libstdc++ version.
>
> OK, agreed, that should work well in most cases
>
> do I get it right that we should get ICU sources and rebuild them in
> the distro we are providing snapshots for?
Try with r531868 and "ant -Duse.libstdc++6=true".
-Mark.
Re: Linux libstdc++.so.5 dependency
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x2C2 day of Apache Harmony Tim Ellison wrote:
> Egor Pasko wrote:
> > To summarize the thread. We have several ideas on how to treat
> > libstdc++ diversity on various linux systems:
> >
> > 1. create both snapshots (libstdc++ 5 and 6 separately) plus a good
> > instruction for not-very-geeky users (like me:) on how to check what
> > version of libstdc++ you have on your system
>
> We just declare which distro the snapshot is designed to work on. I
> don't think we would expect users to seek out the libstdc++ version.
OK, agreed, that should work well in most cases
do I get it right that we should get ICU sources and rebuild them in
the distro we are providing snapshots for?
> > 2. download libstdc++ and recompile it in our build, link in a way
> > whatever is convenient (does it need to tweak gcc afterwards?)
>
> Please, no.
>
> > not many ideas. I would appreciate comments and final decisions on this.
>
> I think we declare the snapshot's intended target, then it becomes a
> community issue of whether we have people who are willing to provide a
> snapshot configuration on a given disro.
>
> Regards,
> Tim
>
--
Egor Pasko
Re: Linux libstdc++.so.5 dependency
Posted by Tim Ellison <t....@gmail.com>.
Egor Pasko wrote:
> To summarize the thread. We have several ideas on how to treat
> libstdc++ diversity on various linux systems:
>
> 1. create both snapshots (libstdc++ 5 and 6 separately) plus a good
> instruction for not-very-geeky users (like me:) on how to check what
> version of libstdc++ you have on your system
We just declare which distro the snapshot is designed to work on. I
don't think we would expect users to seek out the libstdc++ version.
> 2. download libstdc++ and recompile it in our build, link in a way
> whatever is convenient (does it need to tweak gcc afterwards?)
Please, no.
> not many ideas. I would appreciate comments and final decisions on this.
I think we declare the snapshot's intended target, then it becomes a
community issue of whether we have people who are willing to provide a
snapshot configuration on a given disro.
Regards,
Tim
Re: Linux libstdc++.so.5 dependency
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x2C2 day of Apache Harmony Egor Pasko wrote:
> On the 0x2C1 day of Apache Harmony Gregory Shimansky wrote:
>
> [snip]
>
> > > 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
>
> cool :)
>
> > (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.
>
> well, the difference in linking is quite small, no bugs expected, but
> would make Harmony easier to install for non-professionals. So, I do
> not like it so much.
oops, I mean, I _do_ like the solution of special build for snapshots
for end-user simplicity.
--
Egor Pasko
Re: Linux libstdc++.so.5 dependency
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x2C1 day of Apache Harmony Gregory Shimansky wrote:
[snip]
> > 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
cool :)
> (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.
well, the difference in linking is quite small, no bugs expected, but
would make Harmony easier to install for non-professionals. So, I do
not like it so much.
> The problem is that I think we cannot distribute the binaries of it,
ah, those license issues, I am not an expert at all :(
> 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.
To summarize the thread. We have several ideas on how to treat
libstdc++ diversity on various linux systems:
1. create both snapshots (libstdc++ 5 and 6 separately) plus a good
instruction for not-very-geeky users (like me:) on how to check what
version of libstdc++ you have on your system
2. download libstdc++ and recompile it in our build, link in a way
whatever is convenient (does it need to tweak gcc afterwards?)
not many ideas. I would appreciate comments and final decisions on this.
--
Egor Pasko
Re: Linux libstdc++.so.5 dependency
Posted by Gregory Shimansky <gs...@gmail.com>.
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
Re: Linux libstdc++.so.5 dependency
Posted by Tim Ellison <t....@gmail.com>.
Egor Pasko wrote:
> On the 0x2C0 day of Apache Harmony Tim Ellison wrote:
>> Gregory Shimansky wrote:
>>> 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
Too bad.
> 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
>
> 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)
>
> 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'm not sure that carrying around more and more of the system code with
us is the right answer -- even if the license does allow it (i.e. can we
redistribute that code from Apache's servers?).
If we are looking for more work we can produce different packages for
different distributions already. Otherwise we may have to pick one
version, probably the most popular on developers' machines being version
6(?), and list that as a pre-requisite for our snapshots. If people
want to use the other version they will have to recompile.
Regards,
Tim
Re: Linux libstdc++.so.5 dependency
Posted by Egor Pasko <eg...@gmail.com>.
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
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
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)
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.
--
Egor Pasko
Re: Linux libstdc++.so.5 dependency
Posted by Tim Ellison <t....@gmail.com>.
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?
Regards,
Tim
Re: Linux libstdc++.so.5 dependency
Posted by Gregory Shimansky <gs...@gmail.com>.
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.
> [1]
> https://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/README.txt?view=markup
>
>
> Linux users may need to install an appropriate libc compatibility patch
> to their
> operating system if they see the following error message when attempting
> to run
> a Java application with the built class library components on a
> compatible VM :
>
> <error: unable to load ICUInterface34 (libstdc++.so.5: cannot open
> shared object
> file: No such file or directory)>
>
> Where to obtain the required patch and the precise means of applying it
> will
> obviously differ according to Linux distribution. On Debian the advanced
> package
> tool apt-get could be used as follows :
>
> user@server:~$> apt-get install libstdc++5
>
> On a Red Hat Enterprise Linux machine the rpm tool may be used to
> install the
> equivalent package thus :
>
> user@server:~$> rpm -Uvh compat-libstdc++-33-3.2.3-47.3.i386.rpm
>
> Consult the system administration documentation of your particular Linux
> distribution for more information.
>
>
> On 4/22/07, Wayne Beaton <wa...@eclipse.org> wrote:
>> I recently tried running Harmony on a fresh installation of Debian
>> Linux. It
>> failed, complaining that libstdc++.so.5 is not available. After a quick
>> search, I confirmed that libstdc++.so.5 is indeed not anywhere on the
>> machine, but libstdc++.so.6 is there.
>>
>> As I understand it (and I'll admit I don't understand it well),
>> libstdc++.so.5 is considered legacy.
>>
>> Should this dependency be updated, or is there some way to make the
>> dependency version agnostic?
>>
>> Thanks,
>>
>> Wayne
>> --
>> Wayne Beaton
>> The Eclipse Foundation
>> wayne.beaton@eclipse.org
>> Skype, YIM: waynebeaton
>> http://www.eclipse.org
>> http://wbeaton.blogspot.com/
>> http://www.planeteclipse.org/planet/
>>
>>
>
--
Gregory
Re: Linux libstdc++.so.5 dependency
Posted by Nathan Beyer <nd...@apache.org>.
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.
[1] https://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/README.txt?view=markup
Linux users may need to install an appropriate libc compatibility patch to their
operating system if they see the following error message when attempting to run
a Java application with the built class library components on a compatible VM :
<error: unable to load ICUInterface34 (libstdc++.so.5: cannot open shared object
file: No such file or directory)>
Where to obtain the required patch and the precise means of applying it will
obviously differ according to Linux distribution. On Debian the advanced package
tool apt-get could be used as follows :
user@server:~$> apt-get install libstdc++5
On a Red Hat Enterprise Linux machine the rpm tool may be used to install the
equivalent package thus :
user@server:~$> rpm -Uvh compat-libstdc++-33-3.2.3-47.3.i386.rpm
Consult the system administration documentation of your particular Linux
distribution for more information.
On 4/22/07, Wayne Beaton <wa...@eclipse.org> wrote:
> I recently tried running Harmony on a fresh installation of Debian Linux. It
> failed, complaining that libstdc++.so.5 is not available. After a quick
> search, I confirmed that libstdc++.so.5 is indeed not anywhere on the
> machine, but libstdc++.so.6 is there.
>
> As I understand it (and I'll admit I don't understand it well),
> libstdc++.so.5 is considered legacy.
>
> Should this dependency be updated, or is there some way to make the
> dependency version agnostic?
>
> Thanks,
>
> Wayne
> --
> Wayne Beaton
> The Eclipse Foundation
> wayne.beaton@eclipse.org
> Skype, YIM: waynebeaton
> http://www.eclipse.org
> http://wbeaton.blogspot.com/
> http://www.planeteclipse.org/planet/
>
>
Re: Linux libstdc++.so.5 dependency
Posted by Xiao-Feng Li <xi...@gmail.com>.
I met the same problem. In my understanding, this dependence actually
is caused by a third-party software (external dependence) which we
have no way to change. (I found this by printing the dependent libs of
the complaining component, and then printing the dependent libs of its
dependent libs, and so on.) Currently I can't recall which lib it is,
I only recall that this issue was resolved by copying a
libstdc++.so.5. But it was last year, I had thought it was solved.
Thanks,
xiaofeng
On 4/22/07, Wayne Beaton <wa...@eclipse.org> wrote:
> I recently tried running Harmony on a fresh installation of Debian Linux. It
> failed, complaining that libstdc++.so.5 is not available. After a quick
> search, I confirmed that libstdc++.so.5 is indeed not anywhere on the
> machine, but libstdc++.so.6 is there.
>
> As I understand it (and I'll admit I don't understand it well),
> libstdc++.so.5 is considered legacy.
>
> Should this dependency be updated, or is there some way to make the
> dependency version agnostic?
>
> Thanks,
>
> Wayne
> --
> Wayne Beaton
> The Eclipse Foundation
> wayne.beaton@eclipse.org
> Skype, YIM: waynebeaton
> http://www.eclipse.org
> http://wbeaton.blogspot.com/
> http://www.planeteclipse.org/planet/
>
>
--
http://xiao-feng.blogspot.com