[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Yet another stupid suggestion (Re: GCC 3.2 transition )



On Friday 16 August 2002 15:51, Matthew Wilcox wrote:
> ---------
>                       The Debian GCC 3.2 Transition Plan
>
> This is a proposal. You will be notified when this is a real plan
>

Nice plan all in all, although I am going to hate the new package names. Some 
people talked about avoiding breakage, but I think most developers will agree 
that changing the so-names is not the solution. Basically we now have this 
problem due to the ELF-format. It is unrealistic to change the loader format 
now, but it might be a good idea to ask the gnu-binutils people to invent a 
new loader/linker format, that can be made compiler-ABI aware, and perhaps 
even architecture-extention aware(MMX, SSE, Altivec).

But for the people lobbying for a solution that avoids breakage, I have a 
loose idea as well:
The gcc 3.2 is really an architecture change, but for C++ libraries only. On 
other operating systems when they deal with different architectures the norm 
is to use $LIBDIR/$ARCH. That way 64bit libraries in Solaris is placed under 
/usr/lib/sparcv9 and in HP-UX under pa20_64. 

My suggestion for consideration is then to force C++ libraries to enter 
subdirectories until they have a proven compatible ABI-standard. So the old 
libraries are placed under /usr/lib/g++2.95 and the new ones under 
/usr/lib/g++3.1. The defaults are symbolic linked from /usr/lib. We can 
either hack ld.so to search the correct path (using some g++ calling cards) 
or recompile all the old C++ packages with an new rpath or load them with a 
LD_LIBRARY_PATH= script. 
This way both old and new packages will work during the actual transition. We 
are also guarenteed complience with LSB packages because we have the defaults 
symbolic linked.

The problem is we will still have a transition to the new style, but at least 
we are prepared for the next C++ ABI breakage in g++ (likely in gcc 3.4). And 
in theory users can then compile packages with different C++ compilers. (e.g. 
kcc, icc)

So is this just another stupid suggestion or a good idea?
`Allan



Reply to: