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
Re: Yet another stupid suggestion (Re: GCC 3.2 transition )
#include * Allan Sandfeld Jensen [Mon, Aug 19 2002, 02:58:06PM]: > 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 IMHO yes. I do not see why the usage of Rpath has reputation of beeing evil noadays, it should be the most reliable way to go in this phase, instead of hacking linkers and loaders. Once the transition is done and all libraries got appropriate package names, the rpath changes may be removed, but don't have to. Gruss/Regards, Eduard. -- Der Nachteil an Linux ist, dass man sich irgendwann nicht mehr an den Installationsvorgang erinnern kann.
Re: GCC 3.2 transition
On Saturday 17 August 2002 19:28, you wrote: > > I am currently doing this experiment on s390 without uploading of course. I > have grepped the build logs of about 4000 packages that I have access to > for g++|c++ and about 900 packages qualified. I am currently rebuilding > these packages with gcc-3.2 using a local wanna-build DB. This will take > some days. I will let you know the results. > I have put the preliminary data to http://people.debian.org/~gt/gcc-3.2_transition/ .The file Packages contains all files currently being rebuilt. The subdirectory failed contains the build logs of all failed packages, still a lot, mainly due to c++ default argument check changes since gcc 3.0. The subdirectory dep-wait contains the build logs of all packages that depend on another package being built with gcc 3.2. I have qualified the dependency with subdirectories if known. The subdirectory 1iteration contains the build logs of all packages that compiled successfully during the first iteration, i.e. only dependent on libstdc++. The subdirectory 2iteration will contain the build logs of all packages that will compile successfully during the second iteration and so on. I will update the data once a day. Currently about 300 packages have been touched. I hope the data helps with any transition plan. I think Matthew has presented a fine plan, but it is open how long the transition will take with this plan. Maybe a deadline will be helpful, after that source NMUs should be done. Doing binary NMUs for each platform as in my experiment would also work but needs a volunteer for each platform and a lot of bug reports for all the failed builds. Both approaches will duplicate the size of the affected packages in the archive of course. Gerhard
Bug#157292: g++: template function default arguments are not handled
Package: g++ Version: 2:2.95.4-14 Severity: normal g++ doesnt handle specifying a default argument to a specialized template function which is done like template void test(int j = 0); template <> void test<1>(int j); calling test<1>() should work, but instead g++ complains there is no matching template function. Handled correctly by gcc-3.0. Richard. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux mickey 2.4.19 #1 Sat Aug 3 13:55:48 CEST 2002 i686 Locale: [EMAIL PROTECTED], LC_CTYPE= Versions of packages g++ depends on: ii cpp 2:2.95.4-14 The GNU C preprocessor. ii g++-2.95 1:2.95.4-7 The GNU C++ compiler. ii gcc-2.95 1:2.95.4-7 The GNU C compiler.
Re: GCC 3.2 transition
On Friday 16 August 2002 21:47, Martin v. Loewis wrote: > Steve Langasek <[EMAIL PROTECTED]> writes: > > How would this work? Would those using gcc-2.95 software have to set an > > rpath or $LD_LIBRARY_PATH to take advantage of the compat libs? If so, > > it hardly seems worth the effort; manual intervention is still required > > to make legacy binaries work. > > Not necessarily: you can write wrapper scripts around the executable > which automatically set LD_LIBRARY_PATH, then invoke the original > binary. That has worked very well in the past. > While this hack would make it unnecessary, I consider it a lack in the linker. In my eyes, the program should ask the linker at startup to provide a specified set functions. For since C++ has bigger requirements that stem from function overloading and other stuff, the specification consists of the API (which is -oversimplified- the version of the header files) and the ABI (which must match the compiler the app was compiled with). I'm not totally aware of the way the dynamic linker works or how an ELF executable is structured, but I believe it would be possible to add a field in ELFs header that says which ABI to use and get the linker to parse it. Still, I have one question left: will C++ be the only language that profits from this, are there other languages that have different ABI by different compilers ? And would such a function be used again even for C++ ? (hint: multi-vendor ABI standard) At last a crazy idea: what happens if I link object files from two different compilers into one lib? I mean I compile foo.cpp once with compiler A and then again with compier B and create a lib from both of them. The only drawback I see at the moment is that the resulting lib would be approximately be twice the size and, even worse, global objects would be instantiated twice, bad if they acquire and lock some kind of resource . cheers Uli PS: is there any way to get the BTS to spew out a list of all bugs of packages that don't build with a more standard-conformant compiler (GCC3) ?
