Public SourceMage Discussion List

[Arwed von Merkatz <v.merkatz AT gmx.net>]

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
                                                    http://www.sourcemage.org