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
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 av
#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
[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 issu
> 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'
>
> 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:
> 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 entirely fallible and I don
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
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
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
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.so,
with lo
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,
> >
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
[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
>
23 matches
Mail list logo
