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 just
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
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
#include
* Allan Sandfeld Jensen [Mon, Aug 19 2002, 02:58:06PM]:
> libraries are placed under /usr/lib/g++2.95 and the new ones under
> /usr/lib/g++3.1. The defaults are symbolic linked from /usr/lib. We can
> either hack ld.so to search the correct path (using some g++ calling cards)
> or reco
>> 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 Ulr
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
peop
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_LIBRA
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 h
>> "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 pro
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,
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 SONAM
>> 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 SO
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 in
> "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-
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
#include
* 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
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.
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 *libra
> "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 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 m
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 libr
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 a
>> 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
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++
> wi
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 ex
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 b
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 wh
(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, wil
>> [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 unstab
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++ package
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 biase
>> 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 the
[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 pr
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 whic
t
> 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
ch
[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 tr
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 libst
>> 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
>> 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 p
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/libd
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
> mentio
> "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'
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,
> 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'
[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, theref
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
> "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 no
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
>
> 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 a
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 e
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 p
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 e
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 provi
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 $L
>
> 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 t
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
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
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:
> 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
>
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 agai
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
>
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
"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.
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 w
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 differen
> * 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??
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.s
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 broke
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.
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,
> >
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.
Wicher
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
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 choos
[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
>
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
invo
75 matches
Mail list logo
