of lynx -dump below:
The Debian GCC 3.2 Transition Plan Version 2
Why do we need one?
Because GCC 3.2 changed the C++ ABI. You can't mix a C++ library
compiled with GCC 3.2 and a C++ application compiled with an earlier
version, or vice versa.
Transitions are painful
Hello,
I would like to make a proposal for one aspect of the
gcc 3.2 migration in sid. A critical part of this transition
will be the discovery of how many arches still require creation
of libgcc-compat code in glibc. Currently we are told by Jakub
Jelinek that i386 is fine. Franz Sirl has
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
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
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
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
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.
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
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
#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
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
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
#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
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
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
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
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
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
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++
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
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
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
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++
[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,
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
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
[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
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
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
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
[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.
(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,
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
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
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
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
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.
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
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
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
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.
--
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*
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.
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
[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
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
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
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.
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,
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
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.
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
* 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??
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
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
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.
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
[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
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
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,
76 matches
Mail list logo
