Public SourceMage Discussion List

[Andrew <afrayedknot AT thefrayedknot.armory.com>]

On Fri, Feb 25, 2005 at 10:42:40AM -0800, Eric Sandall wrote:
> Quoting Flavien Bridault <f.bridault AT fra.net>:
> > Well my box is still compiling... 12 hours now... All qt-related spells 
> > were
> > broken for instance... I don't have the exact number but dozens of spells 
> > are
> > broken (xorg for example...). But you're right, I could boot however... 
> > ;-)
> >
> > So it seems you don't want to warn the user and anyway this is not the 
> > way it
> > should be done ihmo. WHY g++ didn't triggered a check_self() on all these
> > spells ?? I know this is not done in all c++ spells and that it would be a
> > hard work, but finally would'nt it be the real solution ? We do it for 
> > other
> > spells why not here ? Or did I forgot something ??
> 
> Bugs should probably be filed for packages that need to check themselves 
> when
> gcc/g++ are updated, but then all packages should check themselves after 
> any of
> their dynamically linked libraries are changed (and cast themselves on
> statically linked).
> 
> How should this be handled, massive TRIGGERS for every library that a 
> package
> depends on, some Sorcery functionality that'll automatically recompile
> dependees if their libraries change, or just tell users to use `cleanse 
> --fix`?
> 

It would be hard to have TRIGGERS for all the C++ spells, but
certainly do-able. On the other hand, not every gcc re-cast includes a
binary incompatibility. Im pretty sure cleanse --fix is part of a system
update too so it would/should catch these issues, although the sys-update
would take a fairly significant amount of time.

I dont want to sound negative but binary incompatibility is not a
pretty thing...I think that too little attention is paid to having
backwards compatibility in the C++ ABI, maybe thats a hard problem or
something, or the last attempt was too restrictive or C++ is just too
big of a language to get it right on the first try, I dont pay attention
much to C++, Im just guessing.

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.

Also, I thought it was generally common practice to sorcery rebuild
after a gcc update to take advantage of better code optimization in
the new compiler (and to just get everything uniformly built from the
same compiler). Maybe its less of an issue than it was in the 2.95 ->
3.0 phase of gcc, but I thought thats just what people did when they
updated their compiler...

-Andrew