On 2009-11-05 at 23:42:40 [+0100], Jorge G. Mare <koki@xxxxxxxxxxxxx> wrote: > On Thu, 2009-11-05 at 21:38 +0100, PulkoMandy wrote: > > > Because that will become "inconsistent" as soon as gcc4 becomes the > > > official > > > choice, after R1. It would be better, in my view, to have gcc4 go to lib > > > and > > > gcc2 go to lib/gcc2. That just swaps the problem without solving it. A consistent solution would be to always put libraries into gcc2 and gcc4 subdirectories regardless of whether they match the main ABI of a hybrid. This in turn will complicate things for porters, though. > > This would break anything packaged for old BeOS... It wouldn't. The libraries would be misplaced, but since there's no gcc 4 version competing with it and shared objects using these libraries would have been built with gcc 2 anyway, that doesn't matter. The runtime loader would pick them up, since for the non-main ABI it falls back to the main ABI library search paths, when it couldn't find anything in the search paths for the matching ABI. > I can't help but think that this whole business of GCC2 backwards > compatibility is making the already thinly spread developer base bend > over backwards too much. > > Is it really worth the effort to support closed-source, unmaintained > binaries that are nothing but a dead end in the long run? So far maintaining gcc 2 binary compatibility support hasn't been that big a task. When the costs increase significantly, we'll certainly drop it. CU, Ingo