On 2007-08-27 at 07:12:34 [+0200], Michael Lotz <mmlr@xxxxxxxx> wrote: > On Mon, 27 Aug 2007 01:06:55 +0200, kamikazow wrote > > Hm... what about placing GCC 2.9x ELF binaries in /boot/beos and GCC > > 4 non-ELF universal binaries in /boot/haiku? > > I don't see why we should have universal _binaries_ if all we need are > actually two versions of the libraries. The binary shouldn't really care, > the > loader just has to resolve the right symbols from the right libraries. So > we'd > rather go with universal _libraries_ here. > I don't know if it is technically possible, but would it be doable to > actually > link a library with objects from both GCC2 and GCC4? I mean the C functions > would collide, but they are compatible anyway. The C++ stuff wouldn't > collide > and both versions could exist side by side in a single library. The ELF > format > shouldn't care and the runtime_loader still just resolves the symbols > necessary, just that they are different for GCC2 and GCC4 apps. Crazy? > Probably it's too early in the morning for me to think... Doing that for C++ is definitely non-trivial. The C++ ABI changed significantly. The name mangling changed -- which is probably why you suggest there wouldn't be any collisions -- but I wouldn't rule out that individual symbol names could still be mangled the same way. Furthermore global stuff like initialization code and exception handling changed, too, so this would definitely need to be tinkered with. I've only relatively little knowledge about these things, but, I believe, enough to know that I wouldn't want to do that. At least, I think, it isn't really worth the hassle. When we build distribution supporting both compilers, it will very likely be heavily biased towards one compiler version, i.e. with only few exceptions everything will be compiled with the same one. I don't think we need to overly worry about replicants and mixing + matching add-ons. CU, Ingo