Bug#177674: Minor problem...
Joel Baker writes: > reopen 177674 > retitle 177674 Missing Build-Depends on autotools-dev > severity 177674 minor > > Packages which directly access the scripts from autotools-dev (such as > the cp -p command placed into GCC in the last version) need to declare a > Build-Depend on the autotools-dev package. why? automake depends on autotools-dev.
Bug#178325: LIBC_DEV value for libc12
Package: gcc-3.2 Version: 3.2.2ds5 Severity: wishlist Tags: patch The current rules.defs file does not detect a NetBSD system, and as such, fails to pass a sane value to the m4 call when building the debian/control file. A patch that adjusts this is included. -- Joel Baker <[EMAIL PROTECTED]> --- debian/rules.conf.orig 2003-01-21 20:06:04.0 + +++ debian/rules.conf 2003-01-22 16:06:16.0 + @@ -90,11 +90,15 @@ ifeq ($(DEB_HOST_GNU_SYSTEM),freebsd) ctrl_flags += -DLIBC_DEV=libc1-dev else - ctrl_flags += -DLIBC_DEV="libc6-dev (>= $(libc_ver))" + ifeq ($(DEB_HOST_ARCH), $(findstring $(DEB_HOST_ARCH),netbsd-i386)) +ctrl_flags += -DLIBC_DEV="libc12-dev" + else +ctrl_flags += -DLIBC_DEV="libc6-dev (>= $(libc_ver))" + endif endif endif endif -ctrl_flags += -DLIBC_BUILD_DEP="libc6.1-dev (>= $(libc_ver)) | libc6-dev (>= $(libc_ver)) | libc0.3-dev | libc1-dev" +ctrl_flags += -DLIBC_BUILD_DEP="libc6.1-dev (>= $(libc_ver)) | libc6-dev (>= $(libc_ver)) | libc0.3-dev | libc1-dev | libc12-dev" ifneq ($(GCC_TARGET),) ctrl_flags += \
Bug#178328: NetBSD support patches
Package: gcc-3.2
Version: 3.2.2ds5
Severity: wishlist
Tags: patch
The following patches address two significant issues with
NetBSD-on-Debian builds:
1) netbsd-gcc-config moves the NetBSD portion of src/gcc/gcc.config above
the GNU (Hurd) portion, to prevent problems with misdetecting NetBSD as
GNU (due to the triplet i386-unknown-netbsdelf-gnu matching the pattern
*-*-gnu). I'm not sure what the best answer upstream is, but this solves it
well enough to get by, and is crucial for working builds on NetBSD.
2) netbsd-dynlinker, which changes the default dynamic linker location
from /usr/libexec/ld.elf_so to /lib/ld.elf_so; this makes it target the
default location of the dynamic linker provided by the libc12 package (this
was moved for FHS compliance, and links in /usr/libexec and /libexec are
provided for compatibility, but should not be used by natively compiled
Debian applications). This patch is NOT suitable for upstream, unless they
want to figure out how to make it apply only to netbsd(elf|)-gnu systems
and not netbsd(elf) systems.
Included are both patches, and a patch to debian/rules.patch to invoke
them.
--
Joel Baker <[EMAIL PROTECTED]>
#! /bin/sh -e
# JB: config.gcc patches for netbsd.
dir=
if [ $# -eq 3 -a "$2" = '-d' ]; then
pdir="-d $3"
dir="$3/"
elif [ $# -ne 1 ]; then
echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
exit 1
fi
case "$1" in
-patch)
patch $pdir -f --no-backup-if-mismatch -p1 < $0
;;
-unpatch)
patch $pdir -f --no-backup-if-mismatch -R -p1 < $0
;;
*)
echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
exit 1
esac
exit 0
diff -ur src.orig/gcc/config.gcc src/gcc/config.gcc
--- src.orig/gcc/config.gcc 2002-10-23 19:58:44.0 +
+++ src/gcc/config.gcc 2003-01-21 19:49:04.0 +
@@ -376,6 +376,12 @@
;;
esac
;;
+*-*-netbsd*)
+ tmake_file="t-slibgcc-elf-ver t-libc-ok t-netbsd"
+ xm_defines=POSIX
+ gas=yes
+ gnu_ld=yes
+ ;;
*-*-gnu*)
# On the Hurd, the setup is just about the same on
# each different CPU. The specific machines that we
@@ -406,12 +412,6 @@
tmake_file="${tmake_file} t-openbsd-thread"
fi
;;
-*-*-netbsd*)
- tmake_file="t-slibgcc-elf-ver t-libc-ok t-netbsd"
- xm_defines=POSIX
- gas=yes
- gnu_ld=yes
- ;;
*-*-freebsd[12] | *-*-freebsd[12].* | *-*-freebsd*aout*)
# This is the place-holder for the generic a.out configuration
# of FreeBSD. No actual configuration resides here since
#! /bin/sh -e
# JB: Dynamic linker patches for netbsd.
dir=
if [ $# -eq 3 -a "$2" = '-d' ]; then
pdir="-d $3"
dir="$3/"
elif [ $# -ne 1 ]; then
echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
exit 1
fi
case "$1" in
-patch)
patch $pdir -f --no-backup-if-mismatch -p1 < $0
;;
-unpatch)
patch $pdir -f --no-backup-if-mismatch -R -p1 < $0
;;
*)
echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
exit 1
esac
exit 0
diff -ur src.orig/gcc/config/i386/netbsd-elf.h src/gcc/config/i386/netbsd-elf.h
--- src.orig/gcc/config/i386/netbsd-elf.h 2002-03-01 23:38:15.0
+
+++ src/gcc/config/i386/netbsd-elf.h2003-01-21 19:44:46.0 +
@@ -35,7 +35,7 @@
%{!e*:-e __start}}} \
%{!static: \
%{rdynamic:-export-dynamic} \
- %{!dynamic-linker:-dynamic-linker /usr/libexec/ld.elf_so}} \
+ %{!dynamic-linker:-dynamic-linker /lib/ld.elf_so}} \
%{static:-static}}"
/* Names to predefine in the preprocessor for this target machine. */
diff -ur src.orig/gcc/config/netbsd-elf.h src/gcc/config/netbsd-elf.h
--- src.orig/gcc/config/netbsd-elf.h2002-01-22 04:23:02.0 +
+++ src/gcc/config/netbsd-elf.h 2003-01-21 19:44:27.0 +
@@ -72,5 +72,5 @@
%{!e*:-e __start}}}\
%{!static:
\
%{rdynamic:-export-dynamic} \
- %{!dynamic-linker:-dynamic-linker /usr/libexec/ld.elf_so}} \
+ %{!dynamic-linker:-dynamic-linker /lib/ld.elf_so}} \
%{static:-static}}"
--- debian/rules.patch.orig 2003-01-22 20:59:26.0 +
+++ debian/rules.patch 2003-01-22 21:00:15.0 +
@@ -13,6 +13,7 @@
debian_patches = gcc-names gcc-version fastjar-doc \
libstdc++-incdir libstdc++-codecvt libstdc++-pic libstdc++-doclink
+
ifeq ($(with_java),yes)
debian_patches += gcj-debian-policy gcj-names gcj-without-rpath \
gcj-manpage gij-classpath backport-java-6865
@@ -82,6 +83,10 @@
deb
Bug#178326: Problems with __cxa_atexit conditionals
Package: gcc-3.2 Version: 3.2.2ds5 Severity: minor Tags: patch The detection arrangement for disabling __cxa_atexit appears to be failing for reasons that are not entirely apparent; however, this patch brings the setup more into line with the rest of the rules.defs architecture handling, and fixes the problem. -- Joel Baker <[EMAIL PROTECTED]> --- debian/rules.defs.orig 2003-01-22 16:31:22.0 + +++ debian/rules.defs 2003-01-22 16:34:02.0 + @@ -114,9 +114,11 @@ # __cxa_atexit - -# The __cxa_atexit API does not exist in some libc version (NetBSD) +# The __cxa_atexit API does not exist in some libc versions (NetBSD) with_cxa_atexit := yes -ifeq ($(DEB_HOST_ARCH), $(findstring $(DEB_HOST_ARCH),netbsd)) + +no_cxa_archs := netbsd-i386 +ifeq ($(DEB_HOST_ARCH), $(findstring $(DEB_HOST_ARCH),$(no_cxa_archs))) with_cxa_atexit := disabled for architecture $(DEB_HOST_ARCH) endif pgpCi1n9s15X1.pgp Description: PGP signature
Bug#178327: GNU locale workaround is overly aggressive
Package: gcc-3.2 Version: 3.2.2ds5 Severity: minor Tags: patch The workaround for GNU locale problems is overly aggressive, and breaks on systems that really don't have GNU locales (such as libc12 based systems). The following patch adds a check for known architectures that need to disable the workaround. -- Joel Baker <[EMAIL PROTECTED]> diff -ur debian.orig/control.m4 debian/control.m4 --- debian.orig/control.m4 2003-01-25 00:17:14.0 + +++ debian/control.m4 2003-01-25 00:22:46.0 + @@ -33,7 +33,7 @@ Maintainer: MAINTAINER Uploaders: Christopher C. Chimelis <[EMAIL PROTECTED]>, Matthias Klose <[EMAIL PROTECTED]> Standards-Version: 3.5.6 -Build-Depends: LIBC_BUILD_DEP, m4, autoconf2.13, automake1.4, libtool, gawk, dejagnu (>= 1.4), expect (>= 5.38.0), bzip2, binutils (>= BINUTILSV) [!s390], binutils (>= 2.13.90.0.4) [s390], debhelper (>= 3.0.25), gperf (>= 2.7-3), bison-1.35, flex, gettext, texinfo, zlib1g-dev, libgc6-dev [libgc6_no_archs], xlibs-dev, gnat-3.2 [ada_no_archs] | gnat (>= 3.14p-3) [i386 powerpc sparc], libncurses5-dev, libgmp3-dev, libc6-dev-s390x [s390], tetex-bin, locales, gcc-2.95 [m68k] +Build-Depends: LIBC_BUILD_DEP, m4, autoconf2.13, automake1.4, libtool, gawk, dejagnu (>= 1.4), expect (>= 5.38.0), bzip2, binutils (>= BINUTILSV) [!s390], binutils (>= 2.13.90.0.4) [s390], debhelper (>= 3.0.25), gperf (>= 2.7-3), bison-1.35, flex, gettext, texinfo, zlib1g-dev, libgc6-dev [libgc6_no_archs], xlibs-dev, gnat-3.2 [ada_no_archs] | gnat (>= 3.14p-3) [i386 powerpc sparc], libncurses5-dev, libgmp3-dev, libc6-dev-s390x [s390], tetex-bin, locales [locale_no_archs], gcc-2.95 [m68k] Build-Depends-Indep: doxygen, sharutils ifdef(`TARGET', `', ` diff -ur debian.orig/rules.conf debian/rules.conf --- debian.orig/rules.conf 2003-01-25 00:17:14.0 + +++ debian/rules.conf 2003-01-25 00:21:57.0 + @@ -131,7 +131,8 @@ -Denabled_languages="$(enabled_languages) $$addons" \ -Dada_no_archs="$(foreach arch,$(ada_no_archs),!$(arch))" \ -Dlibgc6_no_archs="$(foreach arch,$(libgc6_no_archs),!$(arch))" \ - debian/control.m4 > debian/control.tmp2 + -Dlocale_no_archs="$(foreach arch,$(locale_no_archs),!$(arch))" \ + debian/control.m4 > debian/control.tmp2 \ uniq debian/control.tmp2 > debian/control.tmp rm -f debian/control.tmp2 [ -e debian/control ] \ diff -ur debian.orig/rules.defs debian/rules.defs --- debian.orig/rules.defs 2003-01-25 00:17:14.0 + +++ debian/rules.defs 2003-01-25 00:23:22.0 + @@ -295,6 +295,13 @@ biarch := yes endif +# GNU locales +force_gnu_locales := yes +locale_no_archs := netbsd-i386 +ifeq ($(DEB_HOST_ARCH), $(findstring $(DEB_HOST_ARCH),$(locale_no_archs))) + force_gnu_locales := disabled for $(DEB_HOST_ARCH) +endif + unpack_stamp := $(stampdir)/01-unpack-stamp patch_stamp:= $(stampdir)/02-patch-stamp control_stamp := $(stampdir)/03-control-stamp Only in debian: rules.defs.orig diff -ur debian.orig/rules2 debian/rules2 --- debian.orig/rules2 2003-01-25 00:17:14.0 + +++ debian/rules2 2003-01-25 00:23:41.0 + @@ -81,7 +81,9 @@ endif ifeq ($(with_cxx),yes) - CONFARGS += --enable-clocale=gnu + ifeq ($(force_gnu_locales),yes) +CONFARGS += --enable-clocale=gnu + endif endif ifeq ($(with_java),yes) pgpIiEY9zkg6U.pgp Description: PGP signature
Bug#178325: LIBC_DEV value for libc12
Joel Baker writes: > Package: gcc-3.2 > Version: 3.2.2ds5 > Severity: wishlist > Tags: patch > > The current rules.defs file does not detect a NetBSD system, and as such, > fails to pass a sane value to the m4 call when building the debian/control > file. A patch that adjusts this is included. > -ctrl_flags += -DLIBC_BUILD_DEP="libc6.1-dev (>= $(libc_ver)) | libc6-dev (>= > $(libc_ver)) | libc0.3-dev | libc1-dev" > +ctrl_flags += -DLIBC_BUILD_DEP="libc6.1-dev (>= $(libc_ver)) | libc6-dev (>= > $(libc_ver)) | libc0.3-dev | libc1-dev | libc12-dev" - so what is libc1-dev for? not sure who sent me this patch, but it was from some bsd porters. - are the freebsd lines still needed in the config files?
Bug#177674: Minor problem...
On Sat, Jan 25, 2003 at 08:29:23AM +0100, Matthias Klose wrote: > Joel Baker writes: > > reopen 177674 > > retitle 177674 Missing Build-Depends on autotools-dev > > severity 177674 minor > > > > Packages which directly access the scripts from autotools-dev (such as > > the cp -p command placed into GCC in the last version) need to declare a > > Build-Depend on the autotools-dev package. > > why? automake depends on autotools-dev. Formality/completeness; since gcc-3.2 is using the scripts directly, rather than via automake, it should have a direct dependancy listed (since, technically, automake could drop it's dependancy somehow, even if this is never likely to actually happen). It is a relatively minor thing, though I believe required by Policy (it's too late for me to try to look up chapter & verse, if you want them I can look tomorrow); mostly, though, it's good form to be explicit about anything you're using directly, even if it's pulled in by something else. -- Joel Baker <[EMAIL PROTECTED]> pgpPwhyIWgo4m.pgp Description: PGP signature
gcc-3.2_3.2.2ds5-0pre6_hppa.changes ACCEPTED
Accepted: cpp-3.2_3.2.2-0pre6_hppa.deb to pool/main/g/gcc-3.2/cpp-3.2_3.2.2-0pre6_hppa.deb fastjar_3.2.2-0pre6_hppa.deb to pool/main/g/gcc-3.2/fastjar_3.2.2-0pre6_hppa.deb fixincludes_3.2.2-0pre6_hppa.deb to pool/main/g/gcc-3.2/fixincludes_3.2.2-0pre6_hppa.deb g++-3.2_3.2.2-0pre6_hppa.deb to pool/main/g/gcc-3.2/g++-3.2_3.2.2-0pre6_hppa.deb g77-3.2_3.2.2-0pre6_hppa.deb to pool/main/g/gcc-3.2/g77-3.2_3.2.2-0pre6_hppa.deb gcc-3.2-base_3.2.2-0pre6_hppa.deb to pool/main/g/gcc-3.2/gcc-3.2-base_3.2.2-0pre6_hppa.deb gcc-3.2_3.2.2-0pre6_hppa.deb to pool/main/g/gcc-3.2/gcc-3.2_3.2.2-0pre6_hppa.deb gnat-3.2_3.2.2-0pre6_hppa.deb to pool/main/g/gcc-3.2/gnat-3.2_3.2.2-0pre6_hppa.deb gobjc-3.2_3.2.2-0pre6_hppa.deb to pool/main/g/gcc-3.2/gobjc-3.2_3.2.2-0pre6_hppa.deb gpc-2.1-3.2_3.2.2.20021128-0pre6_hppa.deb to pool/main/g/gcc-3.2/gpc-2.1-3.2_3.2.2.20021128-0pre6_hppa.deb libg2c0_3.2.2-0pre6_hppa.deb to pool/main/g/gcc-3.2/libg2c0_3.2.2-0pre6_hppa.deb libgcc1_3.2.2-0pre6_hppa.deb to pool/main/g/gcc-3.2/libgcc1_3.2.2-0pre6_hppa.deb libgnat3.15a_3.2.2-0pre6_hppa.deb to pool/main/g/gcc-3.2/libgnat3.15a_3.2.2-0pre6_hppa.deb libobjc1_3.2.2-0pre6_hppa.deb to pool/main/g/gcc-3.2/libobjc1_3.2.2-0pre6_hppa.deb libstdc++5-dbg_3.2.2-0pre6_hppa.deb to pool/main/g/gcc-3.2/libstdc++5-dbg_3.2.2-0pre6_hppa.deb libstdc++5-dev_3.2.2-0pre6_hppa.deb to pool/main/g/gcc-3.2/libstdc++5-dev_3.2.2-0pre6_hppa.deb libstdc++5-pic_3.2.2-0pre6_hppa.deb to pool/main/g/gcc-3.2/libstdc++5-pic_3.2.2-0pre6_hppa.deb libstdc++5_3.2.2-0pre6_hppa.deb to pool/main/g/gcc-3.2/libstdc++5_3.2.2-0pre6_hppa.deb protoize_3.2.2-0pre6_hppa.deb to pool/main/g/gcc-3.2/protoize_3.2.2-0pre6_hppa.deb Thank you for your contribution to Debian.
Bug#178325: LIBC_DEV value for libc12
On Sat, Jan 25, 2003 at 10:01:58AM +0100, Matthias Klose wrote: > Joel Baker writes: > > Package: gcc-3.2 > > Version: 3.2.2ds5 > > Severity: wishlist > > Tags: patch > > > > The current rules.defs file does not detect a NetBSD system, and as such, > > fails to pass a sane value to the m4 call when building the debian/control > > file. A patch that adjusts this is included. > > > -ctrl_flags += -DLIBC_BUILD_DEP="libc6.1-dev (>= $(libc_ver)) | libc6-dev > > (>= $(libc_ver)) | libc0.3-dev | libc1-dev" > > +ctrl_flags += -DLIBC_BUILD_DEP="libc6.1-dev (>= $(libc_ver)) | libc6-dev > > (>= $(libc_ver)) | libc0.3-dev | libc1-dev | libc12-dev" > > - so what is libc1-dev for? not sure who sent me this patch, but it was > from some bsd porters. I believe that libc1 is the FreeBSD GNU libc port (as opposed to libc4, which would be the native FreeBSD version, but the last I'd heard they weren't using that). > - are the freebsd lines still needed in the config files? I would assume so; freebsd-i386 and netbsd-i386 are separate ports. -- Joel Baker <[EMAIL PROTECTED]> pgpFmWzAJKGgD.pgp Description: PGP signature
Bug#178386: gcc-3.2: Warns wrong about unreachable code
Package: gcc-3.2
Version: 1:3.2.1-0pre3
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
gcc-3.2 -Wall -pedantic -ansi -Werror -march=i486 -mcpu=i486 -Os\
-Wunreachable-code -g -o salt-generator salt-generator.c
cc1: warnings being treated as errors
salt-generator.c: In function `main':
salt-generator.c:47: warning: will never be executed
make: *** [salt-generator] Error 1
Line 47 is the "do {" line below. Lines around it are:
for (x = 0; x < SALT_SIZE; ++x) {
do {
errno = 0;
read_cnt = read(rand, &buf, 1);
} while (read_cnt == -1 && (errno == EINTR || errno ==
EAGAIN));
SALT_SIZE is 16.
Fully pre-processed source comming up as soon as I get the bug number to
mail it to.
[EMAIL PROTECTED]:salt-generator$ gcc-3.2 -v
Reading specs from /usr/lib/gcc-lib/i386-linux/3.2.1/specs
Configured with: /mnt/data/gcc-3.1/gcc-3.2-3.2.1ds2/src/configure -v
--enable-languages=c,c++,java,f77,proto,objc,ada --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared --with-system-zlib
--enable-nls --without-included-gettext --enable-java-gc=boehm --enable-objc-gc
i386-linux
Thread model: posix
gcc version 3.2.1 20020924 (Debian prerelease)
- -- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux bohr 2.4.16 #2 SMP Wed Nov 28 05:25:00 EST 2001 i686
Locale: LANG=en_US, LC_CTYPE=en_US
Versions of packages gcc-3.2 depends on:
ii binutils 2.13.90.0.10-1 The GNU assembler, linker and bina
ii cpp-3.2 1:3.2.1-0pre3 The GNU C preprocessor.
ii gcc-3.2-base 1:3.2.1-0pre3 The GNU Compiler Collection (base
ii libc6 2.2.5-14.3 GNU C Library: Shared libraries an
ii libgcc1 1:3.2.1-0pre3 GCC support library.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE+MvPI+z+IwlXqWf4RAibVAJ90cvYkQXB/M+DB+Ox83IQ0YAO/MwCeMUJk
WFz1DX16nbCTXu8SbFI3KUI=
=RGjZ
-END PGP SIGNATURE-
Bug#178386: Preprocessed source code
salt-generator-pp.c.bz2 Description: Binary data
Re: Bug#175526: Bug #175526
On Fri, Jan 24, 2003 at 02:28:31PM -0800, Jeff Bailey wrote: > I don't know if it's significant, but upstream announced .18 today with > the following changelog: > > Changes from binutils 2.13.90.0.16: > > ... > 5. Fix an ELF/m68k bug. important but probably not the solution for this problem. I will try bootstrapping an unpatched 3.2 release in my environment. Richard
Re: Gcc 3.x seems to create incorrect code
In message <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Martin v. Löwis) wrote: > Miah Gregory <[EMAIL PROTECTED]> writes: > > As such, I've come here in the hope that someone can suggest how I might > > find out the exact cause of the problem, as I've never had to try and > > track down potential compiler bugs before. Turns out that it's not a compiler bug, but a workaround in the kernel for a compiler bug.. :-) See "include/linux/spinlock.h", and search for gcc_is_buggy. What was happening, is that the extra field caused the structure to be larger. The kernel was compiled with 2.95.4, and therefore had this field in place. The module, being compiled with 3.2.2, didn't have the field, and consequently was reading from the wrong place in the structure. > We are certainly interested to eliminate all compiler bugs that cause > kernel miscompilation. Please understand, though, that you don't > *necessarily* have encountered a compiler bug: It may be that you rely > on undefined or unspecified behaviour in your code, and that gcc 3.2 > choses to interpret your code differently than 2.95. In this case, you > need to correct your code, to only use well-defined constructs. Absolutely, that's why I used the term 'possible compiler bug'. No-one's perfect, least of all myself. :-) Thanks for the prompt response. -- Miah Gregory
