Report forwarded to Galen Hazelwood <galenh@micron.net>:
Bug#10112; Package gcc. Galen Hazelwood <galenh@micron.net> Sorry, this message was lost when this bug report was restored from a backup. Acknowledgement sent to Klee Dienes <klee@mit.edu>:
New bug report received and forwarded. Copy sent to Galen Hazelwood <galenh@micron.net>. Klee Dienes <klee@mit.edu> Sorry, this message was lost when this bug report was restored from a backup. Received: (at maintonly) by bugs.debian.org; 25 May 1997 17:05:26 +0000 Received: (qmail 6057 invoked from network); 25 May 1997 17:05:24 -0000 Received: from nhv-ct4-24.ix.netcom.com (HELO sauron.fashion-technology.com) (mail@205.184.152.152) by 206.190.143.161 with SMTP; 25 May 1997 17:05:24 -0000 Received: from klee by sauron.fashion-technology.com with local (Exim 1.62 #1) id 0wVgjN-0004rJ-00 (Debian); Sun, 25 May 1997 13:05:17 -0400 From: Klee Dienes Reply-To: Klee Dienes To: maintonly@bugs.debian.org Subject: gcc issues Message-Id: Sender: Klee Dienes Date: Sun, 25 May 1997 13:05:17 -0400 Package: gcc I don't have time to track this down before I leave, unfortunately, but: Using the latest version of gcc with libc5 causes it to build programs that dump core immediately, at least with c++. I like the fact that gcc doesn't depend on a particular libc-dev (sometimes one really does use a compiler without a libc, if rarely), but this is still a serious trap for the unwary. Perhaps gcc should be configured to recommend libc6-dev or maybe conflict with libc5-dev? Or at least a runtime check to prevent it from making bad binaries? In addition, it's easy to end up with a version of cpp that doesn't match the version of gcc, leading to a gcc that can't find 'stddef.h', among other things. This should probably be fixed by changing gcc to explicitly pass all directory arguments to cpp rather than have it know where gcc keeps its header files. Acknowledgement sent to Galen Hazelwood <galenh@micron.net>:
Extra info received and filed, but not forwarded.

You requested that the message be sent to the package maintainer(s) but either the bug report is not associated with any package (probably because of a missing Package psuedo-header field in the original bug report), or the package(s) specified do not have any maintainer(s).

Your message has *not* been sent to any package maintainers; it has merely been filed in the bug tracking system. If you require assistance please contact owner@bugs.debian.org quoting the bug number 10112.

Galen Hazelwood <galenh@micron.net> Sorry, this message was lost when this bug report was restored from a backup. Received: (at 10112-maintonly) by bugs.debian.org; 25 May 1997 23:14:45 +0000 Received: (qmail 1893 invoked from network); 25 May 1997 23:14:34 -0000 Received: from mailmx.micron.net (198.60.253.39) by 206.190.143.161 with SMTP; 25 May 1997 23:14:34 -0000 Received: from xerxes (cnam032p05.nam.micron.net [207.70.7.124]) by mailmx.micron.net (8.8.5/8.8.5) with ESMTP id RAA14231; Sun, 25 May 1997 17:14:15 -0600 (MDT) Sender: galen@micron.net Message-ID: <3388C774.56EBAA45@micron.net> Date: Sun, 25 May 1997 17:12:52 -0600 From: Galen Hazelwood X-Mailer: Mozilla 4.0b3C (X11; I; Linux 2.0.30 i586) MIME-Version: 1.0 To: Klee Dienes , 10112-maintonly@bugs.debian.org Subject: Re: Bug#10112: gcc issues X-Priority: 3 (Normal) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Klee Dienes wrote: > > Package: gcc > > I don't have time to track this down before I leave, unfortunately, > but: > > Using the latest version of gcc with libc5 causes it to build programs > that dump core immediately, at least with c++. Well, yes. Of course it does. The latest gcc (2.7.2.2-4) is libc6 only, and should _never_ be used with libc5. > I like the fact that > gcc doesn't depend on a particular libc-dev (sometimes one really does > use a compiler without a libc, if rarely), but this is still a serious > trap for the unwary. Perhaps gcc should be configured to recommend > libc6-dev or maybe conflict with libc5-dev? Or at least a runtime > check to prevent it from making bad binaries? This is a problem. Conflicts with old packages have to be left in there forever, and Debian is already full of such cruft. (Binutils still conflicts with and elf-binutils, even though both packages have been dead for a long time.) I hesitate to add more. > In addition, it's easy to end up with a version of cpp that doesn't > match the version of gcc, leading to a gcc that can't find 'stddef.h', > among other things. This should probably be fixed by changing gcc to > explicitly pass all directory arguments to cpp rather than have it > know where gcc keeps its header files. I was going to make gcc depend on a specific version of cpp, like g77 does. The dependency would read something like "cpp (>= 2.7.2.2-1), cpp (< 2.7.2.3)". Would such a dependency make it more difficult to upgrade? Moving from cpp/gcc 2.7.2.2 to 2.8, would dpkg require you to remove gcc before upgrading cpp? --Galen Reply sent to Galen Hazelwood <galenh@micron.net>:
You have taken responsibility. Galen Hazelwood <galenh@micron.net> Sorry, this message was lost when this bug report was restored from a backup. Done: Galen Hazelwood <galenh@micron.net>; Maintainer for gcc is Galen Hazelwood <galenh@micron.net>.

Message received at 10112-done@bugs.debian.org:

Sender: galen@micron.net
Message-ID: <33A99FBA.198ADC21@micron.net>
Date: Thu, 19 Jun 1997 15:08:10 -0600
From: Galen Hazelwood <galenh@micron.net>
MIME-Version: 1.0
To: 9954-done@bugs.debian.org, 10006-done@bugs.debian.org,
        10112-done@bugs.debian.org
Subject: Fixed in 2.7.2.2-5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Uploaded to master.

Notification sent to Klee Dienes <klee@mit.edu>:
Bug acknowledged by developer. Klee Dienes <klee@mit.edu> Sorry, this message was lost when this bug report was restored from a backup.