Re: [alpha, amd64, hppa, i386] GCC-4.3 as the default compilers for lenny?
On Sat, Apr 05, 2008 at 08:04:15PM +0300, Riku Voipio wrote: > On Sun, Mar 23, 2008 at 08:30:54PM +0100, Pierre Habouzit wrote: > > Sigh, could we avoid the same discussion over and over, people are not > > supposed (we never asked it in the past, and I see no valid reason to do > > so) to update to the last stable point release before upgrading to > > stable+1. > Dist-upgrade will not fail due to people still having this bug in their > kernels, so there is no need for users to upgrade kernel _before_ > upgrading to lenny. After upgrade reboot to the new lenny kernel is > normal procedure. And? I think sarge needed a new apt to perform the upgrade. In this case there may be a handfull of packages which does not work and even less which fails during upgrade. > > THe _BEST_ example of that are buildd's that for now run etch (even > > some sarge not so long time ago) and have a sid chroot to build. Not > > keeping the CLD patch means that we break our own buildd infrastructure. I doubt that they do. Sarge had 2.4.18 for most arches and lenny will not even think about working on them. > This is making a mountain of a molehill. We have one amd64 and one i386 > buildd. Certainly installing a (security!) kernel update on two buildd's > is a better solution than having old version of gcc on the two most > used archs we have.. The updates needs to be installed anyway. It will be included in r4 and after that in every security update. Bastian -- "We have the right to survive!" "Not by killing others." -- Deela and Kirk, "Wink of An Eye", stardate 5710.5 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#472854: gnat-4.3 needs a manual build for mips and mipsel
On Tue, Apr 01, 2008 at 10:44:33PM +0200, Ludovic Brenta wrote: > Aurelien Jarno writes: > > I have just checked-in a patch in the SVN to fix this problem. > > Thanks a lot! I'll upload it as part of 4.3.0-3 immediately after > gcc-4.3 4.3.0-3. > > > BTW is there any reason to keep the MIPS support as a Debian patch > > instead of forwarding it upstream? This problem would probably have > > been avoided. > > Yes, there is a reason but it's a very bad one: lack of time to engage > into the copyright-assignment procedure. The author of the mips > support, Xavier Grave, is an occasional contributor to the Debian > packages and has never contributed to GCC yet (CCing him). > > As a first step, since he now has a little time available, I've asked > him to separate the mips support into a patch independent of ada-sjlj. > That should make future submission to upstream easier. I have seen this is now done, and I have made a few more changes to get the MIPS support fully working. I have copyright-assignements for GCC, we can probably submit this patch with both our names if you agree. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#472854: gnat-4.3 needs a manual build for mips and mipsel
> On Tue, Apr 01, 2008 at 10:44:33PM +0200, Ludovic Brenta wrote: >> Aurelien Jarno writes: >> > I have just checked-in a patch in the SVN to fix this problem. >> >> Thanks a lot! I'll upload it as part of 4.3.0-3 immediately after >> gcc-4.3 4.3.0-3. >> >> > BTW is there any reason to keep the MIPS support as a Debian patch >> > instead of forwarding it upstream? This problem would probably have >> > been avoided. >> >> Yes, there is a reason but it's a very bad one: lack of time to engage >> into the copyright-assignment procedure. The author of the mips >> support, Xavier Grave, is an occasional contributor to the Debian >> packages and has never contributed to GCC yet (CCing him). >> >> As a first step, since he now has a little time available, I've asked >> him to separate the mips support into a patch independent of ada-sjlj. >> That should make future submission to upstream easier. > > I have seen this is now done, and I have made a few more changes to get > the MIPS support fully working. In order to improve my knowledge about porting gnat to new architecture can you describe what you have modified please ? > I have copyright-assignements for GCC, we can probably submit this patch > with both our names if you agree. OK for me. xavier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#438641: /usr/bin/ld: cannot find -lgcc_s
Processing commands for [EMAIL PROTECTED]: > tag 438641 - moreinfo Bug#438641: gcc does not permit mixing -shared and -static objects when linking (or: please pass -static-libgcc automatically) Tags were: moreinfo Tags removed: moreinfo > stop Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#438641: /usr/bin/ld: cannot find -lgcc_s
tag 438641 - moreinfo stop On Wed, Jan 23, 2008, Matthias Klose wrote: > tag 438641 + moreinfo > please recheck with gcc-4.3 and provide a use case for the request > (using libtool and explicitely specifying -lgcc? why?) It's reproducible with gcc-4.3. The use case is to provide a lib with minimal external deps, for example you want to build a lib which depends on some libs present on most systems, but not on libs which could be different on different systems. I didn't understand your question about libtool and -lgcc. Bye, -- Loïc Minier
Bug#474644: libffi4-dev Provides: libffi-dev, but does not appear to actually be compatible
Package: libffi4-dev Version: 4.1.2-6 Severity: normal I have python-gobject-dev installed; python-gobject-dev Depends: on libffi-dev. On my system, this dependency was satisfied by libffi4-dev, because libffi4-dev Provides: libffi-dev. However, this leaves me with a broken python-gobject-dev package, because at least some operations seem to actually need libffi-dev; libffi4-dev doesn't work: # With libffi4-dev installed: $ pkg-config --libs --cflags pygobject-2.0 Package libffi was not found in the pkg-config search path. Perhaps you should add the directory containing `libffi.pc' to the PKG_CONFIG_PATH environment variable Package 'libffi', required by 'PyGObject', not found # With libffi-dev installed instead: $ pkg-config --libs --cflags pygobject-2.0 -I/usr/include/pygtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -lgobject-2.0 -lglib-2.0 (I'm not entirely sure whether this should be considered a bug in libffi or python-gobject; this is just my best guess.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
