[SM-Discuss] new glibc hits stable
Arwed von Merkatz
v.merkatz at gmx.net
Sat Feb 26 06:59:15 EST 2005
On Fri, Feb 25, 2005 at 05:05:14PM -0800, Andrew wrote:
> On Fri, Feb 25, 2005 at 04:24:06PM -0800, Seth Alan Woolley wrote:
> > On Fri, Feb 25, 2005 at 04:11:53PM -0800, Andrew wrote:
> > > As a consequence though, to the end users (smgl for example), everyone who
> > > builds stuff from source gets the shaft. You'd get the same problems if
> > > you used a binary distro and then updated to 3.4 then started building
> > > a few things here and there, they wouldnt work and all your binary
> > > packages would either need to be updated (and their probably arent
> > > updates), or you'd have to give up using gcc 3.4 until their were. Or
> > > on other source distros youd have similar (if not the same) issues,
> > > its not really a unique to smgl problem, and unfortunatly we cant just
> > > make the incompatibility disappear without having to rebuild a bunch of
> > > stuff that was broken by it.
> > Keeping the old libstdc++ and possibly other libraries around, ldd'ing
> > looking for dynamic links to it, collating by spell, and then recasting
> > could be done in g++/FINAL instead of using a trigger. Prompt in
> > configure with a default to no unless the new and old version have their
> > minor version "cut -d. -f2" not identical, delete the old libstdc++ now,
> > and call the problem fixed.
> Didnt know it worked like that...although I thought if you have spell X
> which calls libraries from spell Y, both C++, and Y was built with g++
> 3.3, X was built with 3.4, they wont be able to talk to one-another.
> Having libstd++ around would ensure that Z (built with 3.3, but has no
> c++ depends) would still work.
> Again, Im just speculating here, maybe all the ABI calls are redirected
> through the appropriate linker and it all works. Since we'll have a
> gcc-3.3 spell that installs to /opt/gcc-3.3, people could just put
> /opt/gcc-3.3/usr/lib at the end of their /etc/ld.so.conf.
Any library using the 3.3 libstdc++ will be unusable for a program
linked to the 3.4 libstdc++. Those ABI issues will eventually stop, as
the C++ ABI is a standard. The gcc people started following that
standard with 3.0, but it seems like it's not that easy to get it right.
I think a FAQ entry for this telling people to do a cleanse --fix after
upgrading g++ is the way to go here. Triggers should be reserved for
stuff that essentially breaks with every upgrade, like imagemagick
changing the library version number even on micro version updates.
Arwed v. Merkatz Source Mage GNU/Linux developer
More information about the SM-Discuss