Re: GCC 3.2 transition
Panu A Kalliokoski [EMAIL PROTECTED] writes: Richard Kettlewell wrote: I think you've answered your own question; it _can_ known which soname to use, and to discover it, it should check the version of the compiler. I'm not sure whether you're actually proposing changing the SONAMEs so that the library will compile itself with different SONAME depending on the compiler, Yes, that sounds exactly like what I'm saying. but let me say some more problems with using SONAME for the transition (even if upstream could be convinced to do this, which in practice most certainly is the biggest problem): Let's say libfoo version 17.1.6 will be the first libfoo to compile itself under libfoo.so.8 if gcc 2 is being used, libfoo.so.9 if gcc 3 is being used. You're right, this seems sensible because the libraries do have incompatible ABI's. Further releases will retain this separation. But what will happen when the library's *own* ABI (the thing SONAMEs are really meant for) changes? Will libfoo 18.0.1 install itself under libfoo.so.10 if gcc 2 is being used, libfoo.so.11 if gcc 3? That seems a reasonable approach for as long as both ABIs need to be supported. What's the problem with that? Or is support for gcc 2 to be dropped from these releases? Why should it be a library's business at all to provide information about what compiler the user programs should use, and to dictate when they cannot use compiler X anymore? This happens already; for instance, the kernel has a preferred gcc versions required to build it, and this changes from time to time. With C++ at the moment we'll probably see more of that rather than less: the older compilers don't even implement the full language correctly. So I suspect the fear of having to support multiple compiler ABIs for many years hence is unfounded in practice. The basic problem here is that SONAMEs contain insufficient information, which for example in the case of libc transition was too weak to express which other libraries the library is linked against, and now is (and should IMO not be made otherwise) too weak to tell which compiler was used to compile the library. Another variant that I think would work but haven't tried, would be to have the information encoded in the name part of the soname rather than the number, thus somewhat breaking the relationship between the name that you link against at compile time and the soname. I've never actually tried this but I believe it would work. But you can pack lots and lots of information into an integer. I think the choice of approach can be left to upstream, as long as they do _something_ to signal the ABI change. Not changing sonames[1] when the ABI changes would also be incredibly painful; bits of software that people use and depend on would start crashing. Well, it is sufficient that the linker gets the additional information from somewhere. Of the two ways (hacking the linker to use different versions depending on the ABI, or having two dynamic linkers) the latter is IMO cleaner, but neither will break anything. I'm not yet convinced that the hack the linker approach actually works properly; it requires Debian to move one set of libraries (say, those with the older ABI) to a new path. It can and may do this for libraries in Debian packages, but cannot and must not for libraries installed into /usr/local. -- http://www.greenend.org.uk/rjk/
Re: GCC 3.2 transition
On Mon, Aug 19, 2002 at 11:32:24AM +0100, Richard Kettlewell wrote: Panu A Kalliokoski [EMAIL PROTECTED] writes: Well, it is sufficient that the linker gets the additional information from somewhere. Of the two ways (hacking the linker to use different versions depending on the ABI, or having two dynamic linkers) the latter is IMO cleaner, but neither will break anything. I'm not yet convinced that the hack the linker approach actually works properly; it requires Debian to move one set of libraries (say, those with the older ABI) to a new path. It can and may do this for libraries in Debian packages, but cannot and must not for libraries installed into /usr/local. That problem shouldn't arise if the hack is done the other way round: new libraries go to /usr/lib/gcc3.2, say, in cases where the ABI differs. It does mean we can never get rid of it, but if the C++ ABI changes in later versions of G++ then we may have to repeat this transition in future anyway. -- Colin Watson [EMAIL PROTECTED]
Re: GCC 3.2 transition
Marcelo E. Magallon [EMAIL PROTECTED] writes: I was toying with that idea in my head. There's no need for a special C++ compiler, is there? linker I meant, obviously. Just the normal linker with a different set of default paths. This is like using an -rpath. The problem with -rpath is that it has precedence over LD_LIBRARY_PATH. So, the simplest solution is for g++-3.2 to indicate a different dynamic linker when linking programs. The problem with this solution is that it's not particularly backwards compatible. Systems without this special linker won't be able to run the binaries, which is a *big* problem. Fiddling arround the ld.so sources to understand how if finds the libraries it wants to use, I noticed it looks for two tags in the ELF object: DT_RPATH and DT_RUNPATH. RUNPATH has two nice poperties: it's looked at *after* LD_LIBRARY_PATH and it doesn't contaminate other ELF objects, that is, it affects *only* the lookup process for the current ELF object (that's the documented behaviour at least, I have yet to check that ld.so does indeed behave like this). I've managed to place such a tag on an excecutable, with the annoying side-effect that RPATH also gets set. I haven't found a way to store only DT_RUNPATH on the ELF object. In order to achive this you have to pass the --enable-new-dtags and -rpath options to the linker. This seems to be ok, since the precense of RUNPATH overrides RPATH (again, this is the documented behaviour). The end effect of this is that a) binaries still work on other systems (with no larger breakage than what we see even today -- unresolved symbols and so on) b) doesn't touch the dynamic linker c) gives us what we want using a very well contained change (modifying the G++ frontend) and recompiling. Does this have drawbacks? -- Marcelo | Bishops move diagonally. That's why they often turn up [EMAIL PROTECTED] | where the kings don't expect them to be. | -- (Terry Pratchett, Small Gods)
Re: GCC 3.2 transition
Colin Watson [EMAIL PROTECTED] writes: That problem shouldn't arise if the hack is done the other way round: new libraries go to /usr/lib/gcc3.2, say, in cases where the ABI differs. It does mean we can never get rid of it, but if the C++ ABI changes in later versions of G++ then we may have to repeat this transition in future anyway. The sad fact is, this may actually turn out to be the most sensible solution, given that, like any standard, there are grey areas, and the day before 3.2's release, the gcc team found just such a grey area where gcc's implementation differed from Intel's, although it agreed with HP's. Mike.
Re: GCC 3.2 transition
On Mon, Aug 19, 2002 at 02:41:44PM +0200, Marcelo E. Magallon wrote: Marcelo E. Magallon [EMAIL PROTECTED] writes: Just the normal linker with a different set of default paths. This is like using an -rpath. The problem with -rpath is that it has precedence over LD_LIBRARY_PATH. So, the simplest solution is for g++-3.2 to indicate a different dynamic linker when linking programs. The problem with this solution is that it's not particularly backwards compatible. Systems without this special linker won't be able to run the binaries, which is a *big* problem. Yes ... Fiddling arround the ld.so sources to understand how if finds the libraries it wants to use, I noticed it looks for two tags in the ELF object: DT_RPATH and DT_RUNPATH. RUNPATH has two nice poperties: it's looked at *after* LD_LIBRARY_PATH and it doesn't contaminate other ELF objects, that is, it affects *only* the lookup process for the current ELF object (that's the documented behaviour at least, I have yet to check that ld.so does indeed behave like this). That could be interesting. How far back is RUNPATH supported? (I seem to recall that it's a relatively new introduction to ELF, but if it's in stable then that's good enough for me.) -- Colin Watson [EMAIL PROTECTED]
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: GCC 3.2 transition
Colin Watson [EMAIL PROTECTED] writes: That could be interesting. How far back is RUNPATH supported? (I seem to recall that it's a relatively new introduction to ELF, but if it's in stable then that's good enough for me.) Good question. Looking at the changelogs: 1999-07-24 Ulrich Drepper [EMAIL PROTECTED] [...] * elf/link.h (struct link_map): Add l_runpath_dirs. * elf/dl-load.c: Pretty print. (decompose_rpath): Take new parameter with info from where the path comes. Pass it the fillin_rpath. (_dl_init_paths): Initialize l_runpath_dirs. (_dl_map_object): Don't search using RPATHs if object has RUNPATH. Search using RUNPATH after LD_LIBRARY_PATH. and later: 1999-11-13 Roland McGrath [EMAIL PROTECTED] * Versions.def (libc): Add GLIBC_2.1.3. Roland's changelog doesn't mention a release and the NEWS file doesn't mention dates. 2.1.3 was released with potato, the first release entered the archive arround Feb 2000. So, we have RUNTIME support all the way to potato. -- Marcelo | This signature was automatically generated with [EMAIL PROTECTED] | Signify v1.07. For this and other cool products, | check out http://www.debian.org/
Re: Yet another stupid suggestion (Re: GCC 3.2 transition )
#include hallo.h * 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
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) ?
Re: GCC 3.2 transition
#include hallo.h * Matthew Wilcox [Fri, Aug 16 2002, 02:51:34PM]: Because upstream chooses the soname to match their API. If we change Do we know this? the soname then we render ourselves binary-incompatible with other distros and vendor-supplied binaries. This is important because the And do we know this? Why not trying to talk with other distributors to try to coordinate our efforts. When they are too arogant and continue doing cludges, then we can put this in the Debian-FAQ as their fault. Gruss/Regards, Eduard. -- * jbf hat da gleich mal eine verstaendnisfrage *fg* wenn ich die tastatu auf us umstelle soll das ja bekanntlich besser zum programmieren sein ... aber habe ich dann auf meinen umlaut tasten eigentlich auch meine umlaute wqie auf einer deutschen tastatur ?? weil sonst gibt es die dummen tasten ja gar nicht .. obwohl wenn ich es richtig bedenke hat sich die frage schon beantwortet *g* NEIN! (; -- #debian.de
Re: GCC 3.2 transition
Panu Kalliokoski [EMAIL PROTECTED] writes: Steve Langasek wrote: [...compiler ABI is part of library ABI...] You're right; I'm just more worried about the more practical point that if a library, when being built, cannot know which SONAME it should install itself under (it would involve checking the version of compiler used, right?), I think you've answered your own question; it _can_ known which soname to use, and to discover it, it should check the version of the compiler. It might help if gcc had a --abi option which output an ABI version, so that it wasn't necessary for every library to know all about different gcc versions, but that would be a convenience, rather than a necessity. (I believe it's also necessary to incorporate information about the sonames - i.e. ABIs - of libraries that this library depends on it, into its soname too.) changing SONAMES will be a real pain. Another possibility that didn't occur to me was having gcc somehow set the SONAME itself - but this seems to me somehow very ugly. Not changing sonames[1] when the ABI changes would also be incredibly painful; bits of software that people use and depend on would start crashing. [1] or implementing linker magic to create multiple soname spaces and using different search paths for each -- http://www.greenend.org.uk/rjk/
Re: GCC 3.2 transition
Eduard == Eduard Bloch [EMAIL PROTECTED] writes: Eduard And do we know this? Why not trying to talk with other Eduard distributors to try to coordinate our efforts. When they are too Eduard arogant and continue doing cludges, then we can put this in the Eduard Debian-FAQ as their fault. They won't give a damn on this. Most distributions actually cannot be upgraded. When you use Redhat 7.2, you are stuck to the libraries of 7.2. When you use Redhat 7.3, you replace every programs, libraries, etc. to the new version. There is nothing as a halfly 7.2 and halfly 7.3 system. In other words, other distributions won't have any incentive to find a scheme to encode their so names in a strange new format that nobody used before. Good luck to everybody trying to convince them adding a -3.2 into the soname. Regards, Isaac.
Re: GCC 3.2 transition
On Sun, Aug 18, 2002 at 01:03:38PM +0100, Richard Kettlewell wrote: Panu Kalliokoski [EMAIL PROTECTED] writes: You're right; I'm just more worried about the more practical point that if a library, when being built, cannot know which SONAME it should install itself under (it would involve checking the version of compiler used, right?), I think you've answered your own question; it _can_ known which soname to use, and to discover it, it should check the version of the compiler. I'm not sure whether you're actually proposing changing the SONAMEs so that the library will compile itself with different SONAME depending on the compiler, but let me say some more problems with using SONAME for the transition (even if upstream could be convinced to do this, which in practice most certainly is the biggest problem): Let's say libfoo version 17.1.6 will be the first libfoo to compile itself under libfoo.so.8 if gcc 2 is being used, libfoo.so.9 if gcc 3 is being used. You're right, this seems sensible because the libraries do have incompatible ABI's. Further releases will retain this separation. But what will happen when the library's *own* ABI (the thing SONAMEs are really meant for) changes? Will libfoo 18.0.1 install itself under libfoo.so.10 if gcc 2 is being used, libfoo.so.11 if gcc 3? Or is support for gcc 2 to be dropped from these releases? Why should it be a library's business at all to provide information about what compiler the user programs should use, and to dictate when they cannot use compiler X anymore? The basic problem here is that SONAMEs contain insufficient information, which for example in the case of libc transition was too weak to express which other libraries the library is linked against, and now is (and should IMO not be made otherwise) too weak to tell which compiler was used to compile the library. It would be very nice to have a standardised way for a library to export all information that will be necessary for the linker to find just the library that will not break anything. But such a standard should be treated as a standard, maybe an extension to ELF, and be subject to much discussion before being taken in use. Then maybe, if debian is lucky, the other distros will deem it worthwhile to be binary-compatible with the new standard. In practice, this kind of situation (ABI's being dictated by factors that are orthogonal to each other) hasn't occurred too much in practice yet, and the nice workaround that will not make unnecessary conflicts is to have different SONAME namespaces. One way to achieve this could be gcc 3.2 automatically linking against a different dynamic linker. (Basically, if the dynamic linker was written in C++ (which it isn't), this would be the only option anyway.) Does gcc's upstream have any views on this? (I believe it's also necessary to incorporate information about the sonames - i.e. ABIs - of libraries that this library depends on it, into its soname too.) I think the information should be incorporated _somewhere_. But as I said above, this should be a matter of common standardisation. Not changing sonames[1] when the ABI changes would also be incredibly painful; bits of software that people use and depend on would start crashing. Well, it is sufficient that the linker gets the additional information from somewhere. Of the two ways (hacking the linker to use different versions depending on the ABI, or having two dynamic linkers) the latter is IMO cleaner, but neither will break anything. Panu
Re: GCC 3.2 transition
Panu A Kalliokoski [EMAIL PROTECTED] writes: In practice, this kind of situation (ABI's being dictated by factors that are orthogonal to each other) hasn't occurred too much in practice yet, and the nice workaround that will not make unnecessary conflicts is to have different SONAME namespaces. One way to achieve this could be gcc 3.2 automatically linking against a different dynamic linker. (Basically, if the dynamic linker was written in C++ (which it isn't), this would be the only option anyway.) Does gcc's upstream have any views on this? I was toying with that idea in my head. There's no need for a special C++ compiler, is there? Just the normal linker with a different set of default paths. This is like using an -rpath. The problem with -rpath is that it has precedence over LD_LIBRARY_PATH. So, the simplest solution is for g++-3.2 to indicate a different dynamic linker when linking programs. -- Marcelo | Item 4: Prefer C++-style comments [EMAIL PROTECTED] | -- Scott Meyers, Effective C++
Re: GCC 3.2 transition
Joseph == Joseph Carter [EMAIL PROTECTED] writes: Joseph Sun's JDK. I know for a fact there's no use of dynamic C++ libraries in any JDK prior to 1.4.1 and I just check the latest 1.4.1 beta find no mention of libstdc++ in any of the executables. If there's C++ code in there, it's statically linked. -- Stephen You will be a large breasted porno star in your next life - Chinese Fortune Cookie
Re: GCC 3.2 transition
On Fri, Aug 16, 2002 at 11:49:03PM -0700, Stephen Zander wrote: Joseph == Joseph Carter [EMAIL PROTECTED] writes: Joseph Sun's JDK. I know for a fact there's no use of dynamic C++ libraries in any JDK prior to 1.4.1 and I just check the latest 1.4.1 beta find no mention of libstdc++ in any of the executables. If there's C++ code in there, it's statically linked. Nowhere eh? [EMAIL PROTECTED]:/usr/local/j2sdk1.4.0_01/jre/plugin/i386/ns610$ ldd libjavaplugin_oji.so libXt.so.6 = /usr/X11R6/lib/libXt.so.6 (0x40044000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x4008e000) libdl.so.2 = /lib/libdl.so.2 (0x40168000) libstdc++-libc6.1-1.so.2 = /usr/lib/libstdc++-libc6.1-1.so.2 (0x4016b000) libm.so.6 = /lib/libm.so.6 (0x401ad000) libc.so.6 = /lib/libc.so.6 (0x401cf000) libSM.so.6 = /usr/X11R6/lib/libSM.so.6 (0x402eb000) libICE.so.6 = /usr/X11R6/lib/libICE.so.6 (0x402f3000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) That's one hell of a figment of my imagination. Although, it does seem the plugin is the only thing which uses libstdc++. -- Joseph Carter [EMAIL PROTECTED] Hey, that's MY freak show! dark Yes, your honour, I have RSA encryption code tattood on my penis. Shall I show the jury? pgpxRbUwdJ5c6.pgp Description: PGP signature
Re: GCC 3.2 transition
This one time, at band camp, Joseph Carter wrote: [EMAIL PROTECTED]:/usr/local/j2sdk1.4.0_01/jre/plugin/i386/ns610$ ldd libjavaplugin_oji.so libXt.so.6 = /usr/X11R6/lib/libXt.so.6 (0x40044000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x4008e000) libdl.so.2 = /lib/libdl.so.2 (0x40168000) libstdc++-libc6.1-1.so.2 = /usr/lib/libstdc++-libc6.1-1.so.2 (0x4016b000) libm.so.6 = /lib/libm.so.6 (0x401ad000) libc.so.6 = /lib/libc.so.6 (0x401cf000) libSM.so.6 = /usr/X11R6/lib/libSM.so.6 (0x402eb000) libICE.so.6 = /usr/X11R6/lib/libICE.so.6 (0x402f3000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) That's one hell of a figment of my imagination. Although, it does seem the plugin is the only thing which uses libstdc++. ldd will traverse the library dependencies tree for all libraries, so it's possible that the libstdc++ requirement is caused by any of the other libraries in that list. What does objdump -p libjavaplugin_oji.so tell you? -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg
Re: GCC 3.2 transition
Sean 'Shaleh' Perry [EMAIL PROTECTED] writes: or do a staging in experimental or somewhere else. Upload everything there, let people look at it for a day or two then move it over. That's the way I interpreted this, too. It's insane to try to NMU 1000 packages in one day. My one problem with this solution is that it will break people's system is a very visible way. For example, at the group were I work, 90% of our development is done in C++. Once this plan is carried out, an upgrade would break almost all our binaries in one fell sweep. Keeping the old libraries in a special directory would alleviate the problem for us. After some grep-dctrl hackery it looks like we have something like 250 *library* packages which are affected (this number is probably upwards biased). This would represent a 2% increase in the number of packages (1 GB increase in the archive size? 400 kB average size for a library package? Sounds ok, we have some pretty large library packages, but it's probably less). But the non-transparency of that solution makes it unattractive. Hacking the dynamic linker isn't sexy, but sounds doable. Besides the ugliness factor, is there anything that speaks against this? Is there an alternative that *doesn't* involve local recompiles? -- Marcelo | The duke had a mind that ticked like a clock and, like [EMAIL PROTECTED] | a clock, it regularly went cuckoo. | -- (Terry Pratchett, Wyrd Sisters)
Re: GCC 3.2 transition
Gerhard Tonn [EMAIL PROTECTED] writes: The disadvantage is that we must know all C++ packages in advance. A large majority of C++ packages depend on libstdc++*; the ones that doesn't are probably libraries which have been linked using cc instead of c++. For example libsigc++-1.1-5 and libgtkmm1.3-14 would pass unnoticed even if they are both C++ libraries. This *might be* symptomatic of libtool libraries, counterexamples appreciated. In this case you'd have to look for typical C++ symbols in the output of, say, objdump -T, e.g. __pure_virtual, __dynamic_cast. In general you'd have to look for traces of C++ mangling. -- Marcelo | Idiot I may be, but tied up I ain't. [EMAIL PROTECTED] | -- Gaspode the wonder dog |(Terry Pratchett, Moving Pictures)
Re: GCC 3.2 transition
On Sat, Aug 17, 2002 at 06:11:10PM +1000, Jamie Wilkinson wrote: That's one hell of a figment of my imagination. Although, it does seem the plugin is the only thing which uses libstdc++. ldd will traverse the library dependencies tree for all libraries, so it's possible that the libstdc++ requirement is caused by any of the other libraries in that list. What does objdump -p libjavaplugin_oji.so tell you? Dynamic Section: NEEDED libXt.so.6 NEEDED libX11.so.6 NEEDED libdl.so.2 NEEDED libstdc++-libc6.1-1.so.2 : I know it doesn't work because I didn't have the thing when I first tried to set up the JDK. I'll be needing it for school, so I'm watching the discussion of a free JDK environment setup package thingy kinda closely. I'm not a fan of things which might have bugs I can't identify and report. -- Joseph Carter [EMAIL PROTECTED]Sanity is counterproductive LordHavoc my Amiga 3000 has way more registers than x86 zinx the local 7/11 has more registers than x86 pgpo9Bp7MyOqO.pgp Description: PGP signature
Re: GCC 3.2 transition
[EMAIL PROTECTED] (Martin v. Loewis) writes: Steve Langasek [EMAIL PROTECTED] writes: My concern is that locally compiled apps built against C++ libraries other than libstdc++ will silently stop working on upgrade. This is certainly not the most important issue facing us in the transition, but so far it seems to me that people are regarding it as so *un*important that it's not worth discussing at all. The breakage will not be silent: On startup of the application, they will give an error message indicating the problem. I think that problem is best solved by educating the users that such problems might happen. This is not how Debian has done similar transitions in the past: libc4 to libc5, and libc5 to libc6, did not cause this breakage in Debian. Old programs continued to work without user or operator intervention (in fact libc4 binaries still work _today_ on some Debian systems.) If you change the ABI, you change the soname. That's what it's _for_. -- http://www.greenend.org.uk/rjk/
Re: GCC 3.2 transition
On Sat, Aug 17, 2002 at 13:27:24 +0100, Richard Kettlewell wrote: This is not how Debian has done similar transitions in the past: libc4 to libc5, and libc5 to libc6, did not cause this breakage in Debian. Old programs continued to work without user or operator intervention (in fact libc4 binaries still work _today_ on some Debian systems.) In some sense, the problem with the gcc 3.2 transition is that is is not radical enough a change; thus the breakage it can cause is rather subtle. libc4 - libc5 was much more than a simple ABI change: it involved both API changes (dropping/deprecating support for a lot of non-portable constructs then in common use requiring e.g. compiling -DDIRENT_ILLEGAL_ACCESS) and a a change of executable format (a.out - ELF; big changes in how shared libraries were built etc.). Ray -- We do not worry about Microsoft developing Open Source applications. Their revenue stream is based on a heroin addiction of selling ever more software. Red Hat's Bob Young quoted in http://www.theregister.co.uk/content/1/11321.html
Re: GCC 3.2 transition
On Sat, Aug 17, 2002 at 10:49:21AM +0200, Marcelo E. Magallon wrote: Gerhard Tonn [EMAIL PROTECTED] writes: The disadvantage is that we must know all C++ packages in advance. A large majority of C++ packages depend on libstdc++*; the ones that doesn't are probably libraries which have been linked using cc instead of c++. For example libsigc++-1.1-5 and libgtkmm1.3-14 would pass unnoticed even if they are both C++ libraries. This *might be* symptomatic of libtool libraries, counterexamples appreciated. In this case you'd have to look for typical C++ symbols in the output of, say, objdump -T, e.g. __pure_virtual, __dynamic_cast. In general you'd have to look for traces of C++ mangling. It should be easy enough to find all the C++ libraries that need to be recompiled. First, find all the packages that depend on some version of libstdc++, and try to recompile them, libraries first. Then, out of the failed packages that have previously built successfully on our gcc-3.0 archs, grab out all library packages from the dependencies; sift and rebuild; lather, rinse, repeat. Anything that's missed by this process is either a package that requires manual intervention to get it working with gcc 3.x, or a package that has no dependencies on any other C++ packages. Steve Langasek postmodern programmer pgpnSqiwpUmnp.pgp Description: PGP signature
Re: GCC 3.2 transition
[Matthew Wilcox] I got sick of listening to people discuss the gcc 3.2 transition in an uninformed manner. So I've whipped up a transition plan which will hopefully get us from A to B without causing too much pain. Haha. I'm entirely fallible and I don't pretend to understand all the issues involved with doing the transition. But by writing down a plan at least it can be updated and fixed before we have to start _doing_ the transition. Comments and corrections welcomed. When this was discussed in June, one of the suggestions was to include the ABI format (compiler name/version) in the library package name and soname. Did you consider it when you wrote your transition plan? Check the debian-devel thread C++ library packaging starting 2002-06-27, URL:http://lists.debian.org/debian-devel/2002/debian-devel-200206/msg01814.html.
Re: GCC 3.2 transition
Steve Langasek [EMAIL PROTECTED] writes: A large majority of C++ packages depend on libstdc++*; the ones that doesn't are probably libraries which have been linked using cc instead of c++. For example libsigc++-1.1-5 and libgtkmm1.3-14 would pass unnoticed even if they are both C++ libraries. This *might be* symptomatic of libtool libraries, counterexamples appreciated. In this case you'd have to look for typical C++ symbols in the output of, say, objdump -T, e.g. __pure_virtual, __dynamic_cast. In general you'd have to look for traces of C++ mangling. It should be easy enough to find all the C++ libraries that need to be recompiled. Sure. I was talking about the libraries that /don't/ have dependencies on libstdc++. libsigc++-1.1-5 and libgtkmm1.3-14 in my example both use libstdc++ but they don't have a dependency on it. The only reason why this has gone unnoticed is because you need to use a specific version of the c++ in order to be able to use these libraries. Anything that's missed by this process is either a package that requires manual intervention to get it working with gcc 3.x, or a package that has no dependencies on any other C++ packages. That's my point. You can't use the binaries for the libraries I mentioned with any other version of c++ than the one used to compile those binaries, yet there's no information in the library that suggest it is actually a C++ library. Look: $ readelf -d /usr/lib/libgtkmm-1.3.so.14 | grep NEEDED | tr -s ' ' 0x0001 (NEEDED) Shared library: [libsigc-1.1.so.5] 0x0001 (NEEDED) Shared library: [libgtk-x11-2.0.so.0] 0x0001 (NEEDED) Shared library: [libgdk-x11-2.0.so.0] 0x0001 (NEEDED) Shared library: [libatk-1.0.so.0] 0x0001 (NEEDED) Shared library: [libgdk_pixbuf-2.0.so.0] 0x0001 (NEEDED) Shared library: [libm.so.6] 0x0001 (NEEDED) Shared library: [libpangoxft-1.0.so.0] 0x0001 (NEEDED) Shared library: [libpangox-1.0.so.0] 0x0001 (NEEDED) Shared library: [libpango-1.0.so.0] 0x0001 (NEEDED) Shared library: [libgobject-2.0.so.0] 0x0001 (NEEDED) Shared library: [libgmodule-2.0.so.0] 0x0001 (NEEDED) Shared library: [libdl.so.2] 0x0001 (NEEDED) Shared library: [libglib-2.0.so.0] 0x0001 (NEEDED) Shared library: [libc.so.6] -- Marcelo | They stared at them. Staring is one of the few things [EMAIL PROTECTED] | frogs are good at. Thinking isn't. | -- (Terry Pratchett, Wings)
Re: GCC 3.2 transition
On Sat, Aug 17, 2002 at 10:34:24AM +0200, Marcelo E. Magallon wrote: Sean 'Shaleh' Perry [EMAIL PROTECTED] writes: or do a staging in experimental or somewhere else. Upload everything there, let people look at it for a day or two then move it over. is probably upwards biased). This would represent a 2% increase in the number of packages (1 GB increase in the archive size? 400 kB average size for a library package? Sounds ok, we have some pretty large 1 GB*12 active archs in unstable == 12GB. Doesn't sound OK to take the debian mirror from ~60GB to ~72GB. Unless you are volunteering to buy 4 terabytes of disk space for our mirrors... Now, if we just did a subset of libraries that we have actual examples of being needed, that might be something to consider. We probably won't know what these libraries are until they stop working for people in sarge, however... -- Ryan Murray, Debian Developer ([EMAIL PROTECTED], [EMAIL PROTECTED]) The opinions expressed here are my own. pgpYD1T5kK641.pgp Description: PGP signature
Re: GCC 3.2 transition
On Sat, Aug 17, 2002 at 10:13:17AM -0500, Steve Langasek wrote: On Sat, Aug 17, 2002 at 10:49:21AM +0200, Marcelo E. Magallon wrote: Gerhard Tonn [EMAIL PROTECTED] writes: The disadvantage is that we must know all C++ packages in advance. A large majority of C++ packages depend on libstdc++*; the ones that doesn't are probably libraries which have been linked using cc instead of c++. For example libsigc++-1.1-5 and libgtkmm1.3-14 would pass unnoticed even if they are both C++ libraries. This *might be* symptomatic of libtool libraries, counterexamples appreciated. In this case you'd have to look for typical C++ symbols in the output of, say, objdump -T, e.g. __pure_virtual, __dynamic_cast. In general you'd have to look for traces of C++ mangling. It should be easy enough to find all the C++ libraries that need to be recompiled. First, find all the packages that depend on some version of There's also the case that with gcc-2.95, you could cheat and write C++ without using the standard lib, and not have to link it. This ability is gone with 3.0 and higher. (note that telnet depends on libstdc++ on hppa -- but not any other arch). -- Ryan Murray, Debian Developer ([EMAIL PROTECTED], [EMAIL PROTECTED]) The opinions expressed here are my own. pgpmvnGHAdRYT.pgp Description: PGP signature
Re: GCC 3.2 transition
[EMAIL PROTECTED] writes: is probably upwards biased). This would represent a 2% increase in the number of packages (1 GB increase in the archive size? 400 kB average size for a library package? Sounds ok, we have some pretty large 1 GB*12 active archs in unstable == 12GB. Doesn't sound OK to take the debian mirror from ~60GB to ~72GB. Unless you are volunteering to buy 4 terabytes of disk space for our mirrors... Uhm... 2% * 55 GB is what gave me that 1 GB figure. I thought that should have been obvious, sorry. It's 1 GB total, not 1 GB per architecture. Now, if we just did a subset of libraries that we have actual examples of being needed, that might be something to consider. We probably won't know what these libraries are until they stop working for people in sarge, however... I don't think I understand what you mean in that last sentence. -- Marcelo | One of the universal rules of happiness is: always [EMAIL PROTECTED] | be wary of any helpful item that weighs less than its | operating manual. | -- (Terry Pratchett, Jingo)
Re: GCC 3.2 transition
(first-time poster, beware of possible stupidity) I'll throw in my views on the subject: (1) If I understand correctly, SONAMEs are not meant to provide any other metadata than a reference to the *library's* ABI. Using SONAMEs for anything else, like which compiler the library was built with, will most probably result in very broken behavior, because the upstream authors have little way to ensure that their library with SONAME n will always be built with compiler x but their library with SONAME m will always be built with compiler y. (2) If (binary) programs from outside the distribution are to work with debian's libraries at all, the metadata about the compiler has to go somewhere. I'm not worried about the transition within debian (which can be some pain, too) but numerous third-party binaries that will probably break even though compatibility for them could have been retained. This rules out just replacing the old libraries with new ones compiled with the new compiler. (3) The easiest way to have metadata about the compiler version is using a separate directory. (4) If the libraries are linked against by their SONAMEs (making them indistinguishable), but the compiler version used in compiling the program is deducible, hacking the linker seems a plausible solution (akin to having two linkers in libc transition). Just my twopenny Panu
Re: GCC 3.2 transition
On 17 Aug 2002 17:47:17 +0200 Petter Reinholdtsen [EMAIL PROTECTED] wrote: Comments and corrections welcomed. When this was discussed in June, one of the suggestions was to include the ABI format (compiler name/version) in the library package name and soname. Did you consider it when you wrote your transition plan? Check the debian-devel thread C++ library packaging starting 2002-06-27, URL:http://lists.debian.org/debian-devel/2002/debian-devel-200206/msg01814.html. That involves fighting with upstream, and really unnecessary iff C++ interface was stabilized. Requiring compiler name and version is not something that is inherent in C++, just signifies that implementation of g++ has been unstable. Not that it shouldn't be done, but pointing out that the idea is rather too optimistic, and possibly restricted to gcc. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer
Re: GCC 3.2 transition
On Friday 16 August 2002 20:26, you wrote: On Friday 16 August 2002 15:51, Matthew Wilcox wrote: If it is done by the platform porters a special build server has to be setup for each platform recompiling all packages depending on c++. A wanna build feature creating packages for NMUs can be used. 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. Gerhard
Re: GCC 3.2 transition
On Sat, Aug 17, 2002 at 05:59:42PM +0200, Marcelo E. Magallon wrote: Steve Langasek [EMAIL PROTECTED] writes: A large majority of C++ packages depend on libstdc++*; the ones that doesn't are probably libraries which have been linked using cc instead of c++. For example libsigc++-1.1-5 and libgtkmm1.3-14 would pass unnoticed even if they are both C++ libraries. This *might be* symptomatic of libtool libraries, counterexamples appreciated. In this case you'd have to look for typical C++ symbols in the output of, say, objdump -T, e.g. __pure_virtual, __dynamic_cast. In general you'd have to look for traces of C++ mangling. It should be easy enough to find all the C++ libraries that need to be recompiled. Sure. I was talking about the libraries that /don't/ have dependencies on libstdc++. libsigc++-1.1-5 and libgtkmm1.3-14 in my example both use libstdc++ but they don't have a dependency on it. The only reason why this has gone unnoticed is because you need to use a specific version of the c++ in order to be able to use these libraries. Are these libraries used by programs in our archive? Then most of those programs that depend on libsigc++ and libgtkmm will also depend on libstdc++; so when you go to recompile the programs with gcc 3.2, you'll find that the build fails because ld can't resolve (differently-mangled) symbol names in the libsigc++ and libgtkmm libraries. If there are no programs that use these libraries, or there are no programs that link against both these libraries and libstdc++, then these libraries do not have to be transitioned at the same time as the rest of the C++-using apps. The transition still has to be handled, it just isn't critical that it happen all at once. Steve Langasek postmodern programmer pgpHg3mTvh4XF.pgp Description: PGP signature
Re: GCC 3.2 transition
On Sat, Aug 17, 2002 at 09:24:34AM -0700, [EMAIL PROTECTED] wrote: It should be easy enough to find all the C++ libraries that need to be recompiled. First, find all the packages that depend on some version of There's also the case that with gcc-2.95, you could cheat and write C++ without using the standard lib, and not have to link it. This ability is gone with 3.0 and higher. (note that telnet depends on libstdc++ on hppa -- but not any other arch). But if it's not linked with anything, then, well, it's not linked with anything -- it has no dependencies on any of the affected packages, and is out of scope of this transition. Nothing needs to be coordinated to recompile a program that doesn't use libraries. Steve Langasek postmodern programmer pgp0zvPOui7Nj.pgp Description: PGP signature
Re: GCC 3.2 transition
Steve Langasek [EMAIL PROTECTED] writes: so when you go to recompile the programs with gcc 3.2, you'll find that the build fails because ld can't resolve (differently-mangled) symbol names in the libsigc++ and libgtkmm libraries. Oh, I see what you meant before. Yeah, that sounds right. -- Marcelo | There are *no* inconsistencies in the Discworld books; [EMAIL PROTECTED] | ocassionally, however, there are alternate pasts. | -- (Terry Pratchett, alt.fan.pratchett)
Re: GCC 3.2 transition
On Sat, Aug 17, 2002 at 09:24:34AM -0700, [EMAIL PROTECTED] wrote: On Sat, Aug 17, 2002 at 10:13:17AM -0500, Steve Langasek wrote: It should be easy enough to find all the C++ libraries that need to be recompiled. First, find all the packages that depend on some version of There's also the case that with gcc-2.95, you could cheat and write C++ without using the standard lib, and not have to link it. In fact, given the mess that the STL has been across various Unix systems, including GNU, until arguably very recently, you could hardly blame commercial developers for doing exactly this ... -- Colin Watson [EMAIL PROTECTED]
Re: GCC 3.2 transition
On Sat, Aug 17, 2002 at 08:00:02PM +0300, Panu Kalliokoski wrote: I'll throw in my views on the subject: (1) If I understand correctly, SONAMEs are not meant to provide any other metadata than a reference to the *library's* ABI. Using SONAMEs for anything else, like which compiler the library was built with, will most probably result in very broken behavior, because the upstream authors have little way to ensure that their library with SONAME n will always be built with compiler x but their library with SONAME m will always be built with compiler y. But in a very real sense, the compiler used *IS* part of the library's ABI; if you recompile a C++ library with gcc 3.2 instead of gcc 2.95, the name of pratically *every* *single* *symbol* will change. That rather soundly eliminates any question of compatible ABIs between the two libraries. Of course, you may still be right that it's better to code this information somewhere other than in the soname itself. The problem is that currently, the transition plan doesn't allow for it to be stored anywhere other than in the package system. Steve Langasek postmodern programmer pgpgPnVtIEaTi.pgp Description: PGP signature
Re: GCC 3.2 transition
On Sat, Aug 17, 2002 at 09:24:34AM -0700, [EMAIL PROTECTED] wrote: On Sat, Aug 17, 2002 at 10:13:17AM -0500, Steve Langasek wrote: On Sat, Aug 17, 2002 at 10:49:21AM +0200, Marcelo E. Magallon wrote: Gerhard Tonn [EMAIL PROTECTED] writes: The disadvantage is that we must know all C++ packages in advance. A large majority of C++ packages depend on libstdc++*; the ones that doesn't are probably libraries which have been linked using cc instead of c++. For example libsigc++-1.1-5 and libgtkmm1.3-14 would pass unnoticed even if they are both C++ libraries. This *might be* symptomatic of libtool libraries, counterexamples appreciated. In this case you'd have to look for typical C++ symbols in the output of, say, objdump -T, e.g. __pure_virtual, __dynamic_cast. In general you'd have to look for traces of C++ mangling. It should be easy enough to find all the C++ libraries that need to be recompiled. First, find all the packages that depend on some version of There's also the case that with gcc-2.95, you could cheat and write C++ without using the standard lib, and not have to link it. This ability is gone with 3.0 and higher. (note that telnet depends on libstdc++ on hppa -- but not any other arch). Eh? You should be able to link in just -lsupc++ and get everything necessary. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: GCC 3.2 transition
Joseph == Joseph Carter [EMAIL PROTECTED] writes: Joseph That's one hell of a figment of my imagination. Although, Joseph it does seem the plugin is the only thing which uses Joseph libstdc++. And I asked originally were you refering to plugin code or a JDK. plugin != JDK. -- Stephen You will be a large breasted porno star in your next life - Chinese Fortune Cookie
Re: GCC 3.2 transition
On Sat, Aug 17, 2002 at 01:38:42PM -0500, Steve Langasek wrote: On Sat, Aug 17, 2002 at 08:00:02PM +0300, Panu Kalliokoski wrote: I'll throw in my views on the subject: (1) If I understand correctly, SONAMEs are not meant to provide any other metadata than a reference to the *library's* ABI. Using SONAMEs for anything else, like which compiler the library was built with, will most probably result in very broken behavior, because the upstream authors have little way to ensure that their library with SONAME n will always be built with compiler x but their library with SONAME m will always be built with compiler y. But in a very real sense, the compiler used *IS* part of the library's ABI; if you recompile a C++ library with gcc 3.2 instead of gcc 2.95, the name of pratically *every* *single* *symbol* will change. That rather soundly eliminates any question of compatible ABIs between the two libraries. You're right; I'm just more worried about the more practical point that if a library, when being built, cannot know which SONAME it should install itself under (it would involve checking the version of compiler used, right?), changing SONAMES will be a real pain. Another possibility that didn't occur to me was having gcc somehow set the SONAME itself - but this seems to me somehow very ugly. Of course, you may still be right that it's better to code this information somewhere other than in the soname itself. The problem is that currently, the transition plan doesn't allow for it to be stored anywhere other than in the package system. I, at least, hope that the ...c versions can coëxist with the old versions. (i.e. not the packages, nor the libraries, should conflict in any way.) Panu
Re: GCC 3.2 transition
On Sat, Aug 17, 2002 at 12:05:59PM -0700, Stephen Zander wrote: Joseph That's one hell of a figment of my imagination. Although, Joseph it does seem the plugin is the only thing which uses Joseph libstdc++. And I asked originally were you refering to plugin code or a JDK. plugin != JDK. I downloaded JDK, I got a plugin. JDK includes plugin, therefore JDK has dependencies on old libstdc++. -- Joseph Carter [EMAIL PROTECTED]What're you looking at? I'm starting to think the gene pool could use a little chlorine. pgpilrA8WhUcP.pgp Description: PGP signature
Re: GCC 3.2 transition
[for debian-gcc people: please Cc: to me because I am not subscribed] On Fri, 16 Aug 2002 14:51:34 +0100, Matthew Wilcox [EMAIL PROTECTED] wrote: * If your package contains no C++, do nothing. One fine day, gcc-defaults will be changed to gcc-3.2 and you'll start using GCC 3.2 with no work by yourself. 1. Does a C (not C++) library compiled with gcc 2.95 work with a C++ program compiled with gcc 3.2? 2. Does this mean I must not use gcc 3.2 before it becomes gcc-defaults? There may be a case where gcc 3.2 offers better optimization. * If you maintain a library written in C++, add a `c' to the end of the name of your .deb, eg libdb4.0++.deb - libdb4.0++c.deb. This is similar in spirit to the glibc transition adding `g' to the end of libraries. What does this c mean? -- Oohara Yuuma [EMAIL PROTECTED] Debian developer PGP key (key ID F464A695) http://www.interq.or.jp/libra/oohara/pub-key.txt Key fingerprint = 6142 8D07 9C5B 159B C170 1F4A 40D6 F42E F464 A695 Better just encrypt it all in your head :-). --- Derrick 'dman' Hudson, about encryption without any physical medium
Re: GCC 3.2 transition
Matthew Wilcox [EMAIL PROTECTED] writes: * Add a Conflict with the non-`c' version of the package. So it will be impossible to have both the old and new library packages on the system simultaneously. That's broken. Why don't we just change the sonames? Because upstream chooses the soname to match their API. If we change Sonames define ABIs not APIs. the soname then we render ourselves binary-incompatible with other distros and vendor-supplied binaries. This is important because the LSB intend to standardise the GCC 3.2 ABI; for Debian to become binary-incompatible at this point would be the height of perversity. You have to change the soname for this kind of transition to work properly and (obviously) this must be coordinated with upstream. -- http://www.greenend.org.uk/rjk/
Re: GCC 3.2 transition
On Fri, Aug 16, 2002 at 02:51:34PM +0100, Matthew Wilcox wrote: This is a proposal. You will be notified when this is a real plan Why don't we just change the sonames? Because upstream chooses the soname to match their API. If we change the soname then we render ourselves binary-incompatible with other distros and vendor-supplied binaries. This is important because the LSB intend to standardise the GCC 3.2 ABI; for Debian to become binary-incompatible at this point would be the height of perversity. No, not at all. The soname is an assurance that the library's *ABI* is constant. An ABI can change with no changes to the API, and when it does, the soname must be changed. This is why we have at least 5 versions of libstdc++ in the archive right now (4 in woody alone). I sincerely hope that g++ 3.2 applications will be allowed to coexist on the system with g++ 2.95.x applications. And really, there is no reason to not allow this: because of the nature of the ABI breakage, you will never be able to accidentally mix-and-match g++ 3.2 binaries with g++ 2.95.x binaries, because they will not be able to resolve each other's symbols at the linker level. It is precisely because the symbol name mangling has changed with each revision of gcc that we need to worry about this transition in the first place. If other distributions are planning to move from 2.95.x to 3.2 without changing sonames, then we need to start talking to them /now/, and make sure we aren't all stuck with this terrible mistake. Steve Langasek postmodern programmer pgpzw1d4LEFlt.pgp Description: PGP signature
Re: GCC 3.2 transition
Previously Oohara Yuuma wrote: 1. Does a C (not C++) library compiled with gcc 2.95 work with a C++ program compiled with gcc 3.2? Yes 2. Does this mean I must not use gcc 3.2 before it becomes gcc-defaults? There may be a case where gcc 3.2 offers better optimization. Yes. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.wiggy.net/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: GCC 3.2 transition
On Fri, Aug 16, 2002 at 11:47:07PM +0900, Oohara Yuuma wrote: [for debian-gcc people: please Cc: to me because I am not subscribed] On Fri, 16 Aug 2002 14:51:34 +0100, Matthew Wilcox [EMAIL PROTECTED] wrote: * If your package contains no C++, do nothing. One fine day, gcc-defaults will be changed to gcc-3.2 and you'll start using GCC 3.2 with no work by yourself. 1. Does a C (not C++) library compiled with gcc 2.95 work with a C++ program compiled with gcc 3.2? If the library does not use exceptions in any way then yes, almost certainly. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: GCC 3.2 transition
On Fri, 16 Aug 2002, Oohara Yuuma wrote: * If you maintain a library written in C++, add a `c' to the end of the name of your .deb, eg libdb4.0++.deb - libdb4.0++c.deb. This is similar in spirit to the glibc transition adding `g' to the end of libraries. What does this c mean? c++ - ++c
Re: GCC 3.2 transition
On Fri, Aug 16, 2002 at 04:06:56PM +0100, Richard Kettlewell wrote: Matthew Wilcox [EMAIL PROTECTED] writes: * Add a Conflict with the non-`c' version of the package. So it will be impossible to have both the old and new library packages on the system simultaneously. That's broken. Why don't we just change the sonames? Because upstream chooses the soname to match their API. If we change Sonames define ABIs not APIs. the soname then we render ourselves binary-incompatible with other distros and vendor-supplied binaries. This is important because the LSB intend to standardise the GCC 3.2 ABI; for Debian to become binary-incompatible at this point would be the height of perversity. You have to change the soname for this kind of transition to work properly and (obviously) this must be coordinated with upstream. From the heated discussion I've just had on IRC, I've gathered the following: * It is assumed that for the vast majority of C++ libs we ship, upstream has already transitioned to using the GCC 3.2 ABI, therefore our current packages are already binary-incompatible with the rest of the world. (ok) * In these cases, having a package whose soname is compatible with the rest of the world is considered more important than providing compatibility for binaries locally compiled by our users against the old, broken ABI. (ok) * For any remaining libraries, there are many in Debian who don't give a damn about getting it right, to the point that they don't want maintainers to get any grandiose ideas about discussing this issue with upstream and possibly hammering out a sane, cross-platform transitioning plan for the library in question that actually manages to NOT break anything. (not ok) But, I seem to be strongly outvoted on the last point. shrug Steve Langasek postmodern programmer pgpEVGsRcAkyi.pgp Description: PGP signature
Re: GCC 3.2 transition
Steve, There shouldn't be huge issues in the gcc 2.95.4 to gcc 3.2 transition. Currently the only two major ones I know if are... 1) Rebuilding glibc with gcc 3.2 *may* require an arch to add a libgcc-compat section to provide libgcc symbols, now .hidden in gcc 3.2's libgcc_s.so, with local copies that are resolvable at runtime. Currently ia64 and ppc has such code available. This is to prevent breaking old binaries when a gcc 3.2 built glibc is installed. 2) Using something like a gcc 2.95.4 built jdk javaplugin (written in c++) with a gcc 3.2 built mozilla won't currently work although workarounds are said to exist. Since Blackdown JDK 1.4 development is underway a gcc 3.2 build JDK won't be far off. Jack
RE: GCC 3.2 transition
* Add a Conflict with the non-`c' version of the package. why can't we have both installed, just like the libfoo6 and libfoo6g situation??
Re: GCC 3.2 transition
On Fri, Aug 16, 2002 at 09:59:28AM -0700, Sean 'Shaleh' Perry wrote: * Add a Conflict with the non-`c' version of the package. why can't we have both installed, just like the libfoo6 and libfoo6g situation?? i explained this elsewhere... Why don't we put the libs in a different directory? Basically, it's too complex. For the glibc transition, we could do this because they used different dynamic linkers. Or can you think of a good way of having them both install without having conflicting files? -- Revolutions do not require corporate support.
Re: GCC 3.2 transition
On Fri, Aug 16, 2002 at 09:59:28AM -0700, Sean 'Shaleh' Perry wrote: * Add a Conflict with the non-`c' version of the package. why can't we have both installed, just like the libfoo6 and libfoo6g situation?? Because doing so would require changing the soname. Which is possible, but would mean inventing a new soname that's not used anywhere else. If upstream then reuse the soname we make up for something different we end up with continuing problems. As far as non-Debian apps go, it seems likely, especially with the LSB looking to standardise C++ on gcc 3.2 soon (in theory in the next couple of months, in practice maybe longer) that people will expect the current sonames to use the gcc 3.2 C++ ABI. Other options are: * encourage upstream to bump their soname themselves, and wait for them to do that. so libfoo.so.2 is the old C++ ABI, and libfoo.so.3 is the new one, eg. * encourage upstream to encode the C++ ABI in the soname, as apt does, ending up with something like libapt-pkg-libc6.2-3-2.so.3.2. (I have no idea how this is worked out) If upstream aren't inclined to change their Linux soname for the new gcc, though, not changing our soname but doing the upgrade anyway seems the best option. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgpZKJKTaOyWo.pgp Description: PGP signature
Re: GCC 3.2 transition
Sean 'Shaleh' Perry [EMAIL PROTECTED] writes: * Add a Conflict with the non-`c' version of the package. why can't we have both installed, just like the libfoo6 and libfoo6g situation?? Err, weren't we able to do that because we moved all the libc5 libs to another directory? Mike.
Re: GCC 3.2 transition
Steve Langasek writes: * It is assumed that for the vast majority of C++ libs we ship, upstream has already transitioned to using the GCC 3.2 ABI, therefore our current packages are already binary-incompatible with the rest of the world. (ok) right. One reason for the 3.2 release was a common base for Linux distributions. * In these cases, having a package whose soname is compatible with the rest of the world is considered more important than providing compatibility for binaries locally compiled by our users against the old, broken ABI. (ok) Jeff Bailey planned to put these libraries in /usr/lib/gcc-2.95 (like in the libc5/6 transition) and rename the packages containing the 2.95 libraries. * For any remaining libraries, there are many in Debian who don't give a damn about getting it right, to the point that they don't want maintainers to get any grandiose ideas about discussing this issue with upstream and possibly hammering out a sane, cross-platform transitioning plan for the library in question that actually manages to NOT break anything. (not ok) cross platform == cross architecture: yes. Jeff is working on a plan to NMU libstdc++ dependent packages. But, I seem to be strongly outvoted on the last point. shrug maybe we break some things in unstable for some days, but how do we call this distro? Matthias
Re: GCC 3.2 transition
On Fri, Aug 16, 2002 at 02:51:34PM +0100, Matthew Wilcox wrote: * If you maintain a library written in C++, add a `c' to the end of the name of your .deb, eg libdb4.0++.deb - libdb4.0++c.deb. This is similar in spirit to the glibc transition adding `g' to the end of libraries. * You should not add a `c' to your -dev package. * The exact placement of the `c' can be tricky. It's not terribly important; the important thing is that the new package conflicts with the old and has a different name. Stylistically, we prefer to keep the `c' adjacent to the soname number, eg libqt3c-mt-odbc, but if your package ends in a ++, put the `c' after that. * Add a Conflict with the non-`c' version of the package. * Ensure that you're using g++-3.2 to build your library (setting CXX in the environment will normally do the trick). * Add a build-dependency on g++-3.2 in your control file (this can be removed after gcc-defaults is changed). * Wait until all your dependencies have been uploaded in `c' versions. What should maintainers of ordinary non-library packages written in C++ do? Presumably it will be possible to upload with a build-dep on g++-3.2 pretty much as soon as a transition plan is finalized, provided there are no library dependencies beyond libstdc++. (Yes, there's a certain amount of pride here in trying to save work for whoever ends up mass-NMUing ...) -- Colin Watson [EMAIL PROTECTED]
Re: GCC 3.2 transition
On Fri, Aug 16, 2002 at 08:03:48PM +0200, Matthias Klose wrote: Steve Langasek writes: * In these cases, having a package whose soname is compatible with the rest of the world is considered more important than providing compatibility for binaries locally compiled by our users against the old, broken ABI. (ok) Jeff Bailey planned to put these libraries in /usr/lib/gcc-2.95 (like in the libc5/6 transition) and rename the packages containing the 2.95 libraries. 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. * For any remaining libraries, there are many in Debian who don't give a damn about getting it right, to the point that they don't want maintainers to get any grandiose ideas about discussing this issue with upstream and possibly hammering out a sane, cross-platform transitioning plan for the library in question that actually manages to NOT break anything. (not ok) cross platform == cross architecture: yes. Jeff is working on a plan to NMU libstdc++ dependent packages. But, I seem to be strongly outvoted on the last point. shrug maybe we break some things in unstable for some days, but how do we call this distro? My concern is that locally compiled apps built against C++ libraries other than libstdc++ will silently stop working on upgrade. This is certainly not the most important issue facing us in the transition, but so far it seems to me that people are regarding it as so *un*important that it's not worth discussing at all. Steve Langasek postmodern programmer pgpb2XvWyMZSM.pgp Description: PGP signature
Re: GCC 3.2 transition
Matthew Wilcox [EMAIL PROTECTED] writes: This is a proposal. You will be notified when this is a real plan I think Jeff Bailey's plan is entirely different, and I like his plan more. Here are the differences. * If you maintain a library written in C++, add a `c' to the end of the name of your .deb, eg libdb4.0++.deb - libdb4.0++c.deb. This is similar in spirit to the glibc transition adding `g' to the end of libraries. In Jeff's plan: do nothing. At some point in the future, we will change gcc-defaults to make gcc-3.2 the default on all architectures. At that time, you should remove the setting of CXX and the explicit dependency on g++-3.2. You should not rename your package to remove the `c' suffix until upstream change their soname. In Jeff's plan: All C++ packages will be uploaded via NMUs. The package maintainer can upload their packages afterwards if they have to make other corrections. Why don't we just change the sonames? Because it is easiest to have just two binary-incompatible libraries. They can't coexist, and they don't need to, most of the time. When they do, the old versions can be put in a separate directory. Why don't we put the libs in a different directory? Basically, it's too complex. For the glibc transition, we could do this because they used different dynamic linkers. For C++, we can do this because we have the source of nearly all packages, and can recompile them. There won't be much C++ libraries that are needed by packages for which we don't have the source to. Regards, Martin
Re: GCC 3.2 transition
Steve Langasek [EMAIL PROTECTED] writes: I sincerely hope that g++ 3.2 applications will be allowed to coexist on the system with g++ 2.95.x applications. I don't think this will happen, atleast not for shared libraries. Any scheme that tries to solve this problem will be horribly complex, require manual interaction with the build process, and produce binaries that are incompatible with anybody else's binaries. And really, there is no reason to not allow this: because of the nature of the ABI breakage, you will never be able to accidentally mix-and-match g++ 3.2 binaries with g++ 2.95.x binaries, because they will not be able to resolve each other's symbols at the linker level. Indeed. So there is no accidental linkage of the wrong library. If something breaks, it will be visible right when it starts, and the solution is clear: recompile the package that uses the old ABI. It is precisely because the symbol name mangling has changed with each revision of gcc that we need to worry about this transition in the first place. The ABI deals with way more aspects than name mangling, but - yes. If other distributions are planning to move from 2.95.x to 3.2 without changing sonames, then we need to start talking to them /now/, and make sure we aren't all stuck with this terrible mistake. It is not a terrible mistake, it is the only solution that can work at all. *If* sonames are changed, we will get a terrible mess. If we use the sonames defined by the upstream maintainers, everything will work out nicely, as everybody uses the same sonames for the same libraries. Other distributions *will* build the packages from source as-is, and thus *will not* change the sonames of the library: they can rebuild the entire distribution from source, so there simply is no need to keep the old shared libraries. Regards, Martin
Re: GCC 3.2 transition
Matthew Wilcox [EMAIL PROTECTED] writes: All of them? I sw someone do a count and there were around 1000 packages currently in the archive. 10%. Per architecture. Is Jeff really going to bNMU all of these packages on the same day for all architectures? I think this is the plan. You'll have to ask him for specifics; I think the plan incorporates doing one architecture at a time. What will that do to auric's disc space and our network traffic? This doesn't sound like a plan, it sounds like the absence of a plan. It is a strategy that requires a minimum of manual intervention, so I think it is a good strategy - much better than requiring every single maintainer of each of the 1000 packages to act in a coordinated way, and ending up with an infrastructure that is incompatible to anybody else's gcc 3.2 applications. If temporary breakage of some applications is acceptable, you can spread this over a couple of days, by tsorting the 1000 packages. Regards, Martin
Re: GCC 3.2 transition
On Fri, Aug 16, 2002 at 09:47:25PM +0200, Martin v. Loewis wrote: 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. If you mean that the manual intervention is need by package maintainers: indeed they'd need to act. So this would be restricted to packages for which no source code is available. The majority of such packages links to libstdc++ only, so there may be no need for action at all. Do we have non-free C++ packages that we have to worry about? My comments were more directed at unpackaged software that users may be running on their Debian systems. In those cases, providing a way to get their binaries working again /after/ we break them is only a little bit better than forcing them to recompile. My concern is that locally compiled apps built against C++ libraries other than libstdc++ will silently stop working on upgrade. This is certainly not the most important issue facing us in the transition, but so far it seems to me that people are regarding it as so *un*important that it's not worth discussing at all. The breakage will not be silent: On startup of the application, they will give an error message indicating the problem. I think that problem is best solved by educating the users that such problems might happen. It is silent in the sense that the package management system will give no indication that the new libfoo++.so.n is not compatible with the old libfoo++.so.n; only locally compiled, /packaged/ apps will be tipped off to the problem. Steve Langasek postmodern programmer pgpwIB15ehwxQ.pgp Description: PGP signature
Re: GCC 3.2 transition
If upstream aren't inclined to change their Linux soname for the new gcc, though, not changing our soname but doing the upgrade anyway seems the best option. even if some are willing not all will be. Then we have to worry about dead upstreams too. It seems like changing the sonames to solve this simply won't work. I had forgotten we solved the libc5 issue by moving the libs to a new directory and making ld.so look there. Been a while (-:
Re: GCC 3.2 transition
Steve Langasek [EMAIL PROTECTED] writes: Jeff Bailey planned to put these libraries in /usr/lib/gcc-2.95 (like in the libc5/6 transition) and rename the packages containing the 2.95 libraries. 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. If you mean that the manual intervention is need by package maintainers: indeed they'd need to act. So this would be restricted to packages for which no source code is available. The majority of such packages links to libstdc++ only, so there may be no need for action at all. My concern is that locally compiled apps built against C++ libraries other than libstdc++ will silently stop working on upgrade. This is certainly not the most important issue facing us in the transition, but so far it seems to me that people are regarding it as so *un*important that it's not worth discussing at all. The breakage will not be silent: On startup of the application, they will give an error message indicating the problem. I think that problem is best solved by educating the users that such problems might happen. With a little effort, it would be possible to produce a list of shared libraries that will break; perhaps while constructing the NMUs, and maintaining that list as a package. It would then be possible to even write a skript that checks one or many binaries (apps and libs) whether they are linked against one of these libraries, and warn users that those programs will stop working after the update. The time to maintain this database would IMO be better spent than the time needed to really solve the problem (which is an effort with uncertain outcome, too). Regards, Martin
Re: GCC 3.2 transition
On Fri, Aug 16, 2002 at 01:27:37PM -0500, Steve Langasek wrote: On Fri, Aug 16, 2002 at 08:03:48PM +0200, Matthias Klose wrote: Steve Langasek writes: * In these cases, having a package whose soname is compatible with the rest of the world is considered more important than providing compatibility for binaries locally compiled by our users against the old, broken ABI. (ok) Jeff Bailey planned to put these libraries in /usr/lib/gcc-2.95 (like in the libc5/6 transition) and rename the packages containing the 2.95 libraries. 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. My concern is that locally compiled apps built against C++ libraries other than libstdc++ will silently stop working on upgrade. This is certainly not the most important issue facing us in the transition, but so far it seems to me that people are regarding it as so *un*important that it's not worth discussing at all. One possible way of allowing both 2.95 libs and 3.2 libs to coincide is to hack ld.so to look in additional search paths if a binary is linked with specific library. For example, in this case, if ld.so sees that local-qt-based-app is linked with libstdc++-libc6.2-2.so.3, it adds /usr/lib/libstdc++-libc6.2-2.so.3 to the library search path, and then preferentially load /usr/lib/libstdc++-libc6.2-2.so.3/libqt.so.2 to satisfy the libqt.so.2 dependency. Naturally, we'd need a transition plan to get those libs out of /usr/lib and into /usr/lib/libstdc++-libc6.2-2.so.3. But we could do that at the same time as putting new, gcc-3.2-compiled libraries in /usr/lib/libstdc++-libc6.2-2.so.5/. When /usr/lib is empty of so.3-dependent libs, we can start moving so.5-dependent libs into /usr/lib. This only covers a clean unstable transition. I'm not familiar with release-to-release transitions. Given that same-soname library transitioning occurs too much (i.e., more than never), it might be time to have a fix, even if the fix is detestable. dave...
Re: GCC 3.2 transition
On Friday 16 August 2002 15:51, Matthew Wilcox wrote: I got sick of listening to people discuss the gcc 3.2 transition in an uninformed manner. So I've whipped up a transition plan which will hopefully get us from A to B without causing too much pain. Haha. I'm entirely fallible and I don't pretend to understand all the issues involved with doing the transition. But by writing down a plan at least it can be updated and fixed before we have to start _doing_ the transition. Comments and corrections welcomed. I think, the question is, whether the transition should be done by the package maintainers or by the platform porters. If it is done by the platform porters a special build server has to be setup for each platform recompiling all packages depending on c++. A wanna build feature creating packages for NMUs can be used. The packages that have been built successfully can then be uploaded to a local archive or to auric which will probably break some other packages. The packages that haven't been built successfully have to be rebuilt. This is basically the approach used to build packages for a new architecture. The advantage is that the transition takes probably only one week on most architectures. The disadvantage is that we must know all C++ packages in advance. Gerhard
Re: GCC 3.2 transition
On Fri, Aug 16, 2002 at 08:38:53PM +0200, Martin v. Loewis wrote: In Jeff's plan: All C++ packages will be uploaded via NMUs. The package maintainer can upload their packages afterwards if they have to make other corrections. All of them? I sw someone do a count and there were around 1000 packages currently in the archive. 10%. Per architecture. Is Jeff really going to bNMU all of these packages on the same day for all architectures? What will that do to auric's disc space and our network traffic? This doesn't sound like a plan, it sounds like the absence of a plan. -- Revolutions do not require corporate support.
Re: GCC 3.2 transition
On Fri, Aug 16, 2002 at 08:38:53PM +0200, Martin v. Loewis wrote: Matthew Wilcox [EMAIL PROTECTED] writes: At some point in the future, we will change gcc-defaults to make gcc-3.2 the default on all architectures. At that time, you should remove the setting of CXX and the explicit dependency on g++-3.2. You should not rename your package to remove the `c' suffix until upstream change their soname. In Jeff's plan: All C++ packages will be uploaded via NMUs. The package maintainer can upload their packages afterwards if they have to make other corrections. Indeed, this is the entire reason apt-rdepends exists. I looked really hard to see if anything else does what apt-rdepends did. Alas, no. I am looking to integrate this functionality into apt-cache, ASAP. Simon
Re: GCC 3.2 transition
If temporary breakage of some applications is acceptable, you can spread this over a couple of days, by tsorting the 1000 packages. or do a staging in experimental or somewhere else. Upload everything there, let people look at it for a day or two then move it over. This staging could also take away the need to finish in one day. All C++ package maintainers could upload to the staging area. Anyone who has not uploaded in a certain time (a week or less sounds right) will hae an NMU done for them.
Re: GCC 3.2 transition
On Fri, Aug 16, 2002 at 02:53:22PM -0500, Steve Langasek wrote: The majority of such packages links to libstdc++ only, so there may be no need for action at all. Do we have non-free C++ packages that we have to worry about? My comments were more directed at unpackaged software that users may be running on their Debian systems. In those cases, providing a way to get their binaries working again /after/ we break them is only a little bit better than forcing them to recompile. Well there's the proprietary JDK, but it already uses a -compat package library. *shrug* -- Joseph Carter [EMAIL PROTECTED]Don't feed the sigs Overfiend xhost +localhost should only be done by people who would paint their hostname and root password on an interstate overpass. pgpVkJEjPhr4Q.pgp Description: PGP signature
Re: GCC 3.2 transition
Joseph == Joseph Carter [EMAIL PROTECTED] writes: Joseph Well there's the proprietary JDK, but it already uses a Joseph -compat package library. Eh? Are you refering to java plugins for mozilla et al, or any actual JDK? -- Stephen To Republicans, limited government means not assisting people they would sooner see shoveled into mass graves. -- Kenneth R. Kahn
Re: GCC 3.2 transition
On Fri, Aug 16, 2002 at 02:54:03PM -0700, Stephen Zander wrote: Joseph == Joseph Carter [EMAIL PROTECTED] writes: Joseph Well there's the proprietary JDK, but it already uses a Joseph -compat package library. Eh? Are you refering to java plugins for mozilla et al, or any actual JDK? Sun's JDK. -- Joseph Carter [EMAIL PROTECTED] You expected a coherent reply? aj Knghtbrd the increase in tension worldwide (as evidenced by crime ajand whatnot) over that time period looks a lot like Linux ajgrowth since 1993 aj ``Linux linked to worldwide crime epidemic!!'' pgp0JuuUuDprS.pgp Description: PGP signature
Re: GCC 3.2 transition
[EMAIL PROTECTED] (Steve Langasek) wrote on 16.08.02 in [EMAIL PROTECTED]: From the heated discussion I've just had on IRC, I've gathered the following: * It is assumed that for the vast majority of C++ libs we ship, upstream has already transitioned to using the GCC 3.2 ABI, therefore our current packages are already binary-incompatible with the rest of the world. (ok) Is this maybe will already have ... when we release? Because otherwise, this is obvious nonsense. 3.2 was released *yesterday*. I am pretty certain 99% of all upstreams haven't even realized yet that 3.2 exists. *No* distribution currently ships with 3.2.[1] Our current packages may or may not be incompatible, but not for this reason. [1] From the gcc list, IIRC several distributions were planning on shipping with 3.2 end of August or September. That was one of the arguments for creating 3.2. MfG Kai
Re: GCC 3.2 transition
My concern is that locally compiled apps built against C++ libraries other than libstdc++ will silently stop working on upgrade. This is certainly not the most important issue facing us in the transition, but so far it seems to me that people are regarding it as so *un*important that it's not worth discussing at all. Having been surprised by 64-bit stuff ceasing to work on sparc after the libc6 security upgrade, and then the additional amusement of no longer being able to compile anything 64-bit, I imagine the C++ breakage would be a whole lot less painless.
Re: GCC 3.2 transition
On Fri, Aug 16, 2002 at 11:34:00PM +0200, Kai Henningsen wrote: [EMAIL PROTECTED] (Steve Langasek) wrote on 16.08.02 in [EMAIL PROTECTED]: From the heated discussion I've just had on IRC, I've gathered the following: * It is assumed that for the vast majority of C++ libs we ship, upstream has already transitioned to using the GCC 3.2 ABI, therefore our current packages are already binary-incompatible with the rest of the world. (ok) Is this maybe will already have ... when we release? Because otherwise, this is obvious nonsense. 3.2 was released *yesterday*. I am pretty certain 99% of all upstreams haven't even realized yet that 3.2 exists. *No* distribution currently ships with 3.2.[1] Our current packages may or may not be incompatible, but not for this reason. The claim was, that it's already too late to prevent binary incompatibility for some libraries. Whether this is because some distros have already shipped with a post-2.95.x ABI, or whether this is because it's too late to stop certain distros from shipping with the 3.2 ABI, I don't know. Steve Langasek postmodern programmer pgpvWnr0Yf6Gj.pgp Description: PGP signature
