Bug#107610: cc1: /tmp/ccoDern9.i: Invalid argument
Package: gcc Version: Version: 2:2.95.4-5 Hello, ... i just finished a new unstable install, and got the following error as i wanted to build a package : [EMAIL PROTECTED]:~/debian/ocaml/ocaml-3.02$ gcc -o /tmp/gcc /tmp/gcc.c cc1: /tmp/ccoDern9.i: Invalid argument /tmp/gcc.c is just a plain empty file (well with a empty main function in it). Friendly, Sven Luther
Bug#107610: acknowledged by developer (closing unreproducible report)
> more information was requested on Sat, 4 Aug 2001, but was not sent. Sorry, i had mail problems, and probably the request for more info was lost during ths time. Anyway, this problem seems to be gone, but i have no idea what happened since then. Since you apparently did not have other reports about similar problems, it must have been a problem with my install, or something i did badly, or my harddisk causing problems, maybe bad permission on /tmp ? Friendly, Sven Luther
Bug#845690: gcc-6: gcc creates unbootable kernel on x86-64
Control: reassign -1 binutils 2.27.51.20161124-1 Control: retitle -1 binutils: creates unbootable kernel on x86-64 Control: severity -1 grave On 2016-11-26 15:13 +0100, Damien Wyart wrote: > After running further tests today, I think this is in fact *not* > related to gcc but to the kernel itself. > > I tested all 6.2.1-X versions as well as gcc-5 (5.4.1-3) and all the > kernels fail to boot (balck screen just after grub and nothing in the > logs). Same here, downgrading binutils to 2.27.51.20161118-2 helped. I'm reassigning the bug and bumping the severity, since several people have observed the problem. Cheers, Sven
Bug#867425: gcc-defaults: /usr/share/doc/gcc symlink recreated on every package upgrade
Source: gcc-defaults Version: 1.168d1 Severity: minor Tags: patch The gcc preinst script removes the /usr/share/doc/gcc symlink (it tests whether /usr/share/doc/gcc is a directory, but this test also succeeds for a symlink to a directory), apparently as part of a directory -> symlink conversion that happened over 16 years ago: , | gcc-defaults (0.4) unstable; urgency=low | | * Link /usr/share/doc/gcc to cpp doc directory (#80990). | | -- Matthias Klose Mon, 1 Jan 2001 18:27:27 +0100 ` It seems that the preinst script and the part of the postinst script that also deals with this conversion can be safely removed, see the attached patch. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 4.12.0-nouveau (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) diff -Nru gcc-defaults-1.168d1/debian/gcc.postinst.in gcc-defaults-1.168d1local1/debian/gcc.postinst.in --- gcc-defaults-1.168d1/debian/gcc.postinst.in 2013-06-12 23:03:20.0 +0200 +++ gcc-defaults-1.168d1local1/debian/gcc.postinst.in 2017-07-06 10:00:09.0 +0200 @@ -1,12 +1,5 @@ #! /bin/sh -e -# remove the doc dir, if it's still a directory and replace with a symlink -pkg=`basename $0 .postinst` -if [ ! -L /usr/share/doc/$pkg ]; then -rm -rf /usr/share/doc/$pkg -ln -s cpp /usr/share/doc/$pkg -fi - update-alternatives --quiet \ --install /usr/bin/cc cc /usr/bin/gcc 20 \ @GFDL@--slave /usr/share/man/man1/cc.1.gz cc.1.gz /usr/share/man/man1/gcc.1.gz diff -Nru gcc-defaults-1.168d1/debian/gcc.preinst gcc-defaults-1.168d1local1/debian/gcc.preinst --- gcc-defaults-1.168d1/debian/gcc.preinst 2015-07-18 20:30:28.0 +0200 +++ gcc-defaults-1.168d1local1/debian/gcc.preinst 1970-01-01 01:00:00.0 +0100 @@ -1,10 +0,0 @@ -#! /bin/sh -e - -if [ -d /usr/share/doc/gcc ]; then -echo "Removing old gcc doc directory." -rm -rf /usr/share/doc/gcc -fi - -#DEBHELPER# - -exit 0
Bug#942049: libobjc-9-dev: broken symlink /usr/lib/gcc/*/gnu/9/libobjc_gc.so
Package: libobjc-9-dev Version: 9.2.1-8 Your package includes a dangling symlink: , | $ file /usr/lib/gcc/x86_64-linux-gnu/9/libobjc_gc.so | /usr/lib/gcc/x86_64-linux-gnu/9/libobjc_gc.so: broken symbolic link to ../../../x86_64-linux-gnu/libobjc_gc.so.4 ` According to apt-file there is no libobjc_gc.so.4 anywhere in the archive. A similar broken symlink is shipped in libobjc-8-dev and apparently also in libobjc-7-dev (don't have libobjc-7-dev installed now). -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.5-nouveau (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libobjc-9-dev depends on: ii gcc-9-base9.2.1-8 ii libgcc-9-dev 9.2.1-8 ii libobjc4 9.2.1-8 libobjc-9-dev recommends no packages. libobjc-9-dev suggests no packages. -- no debconf information
Bug#869090: gcc-6: Address sanitizer: Shadow memory range interleaves
On Montag, 24. Juli 2017 16:34:34 CEST Ben Hutchings wrote: [...] > > Downgrading the kernel from linux-image-4.11.0-2-amd64 (4.11.11-1+b1) to > > linux-image-4.11.0-1-amd64 (4.11.6-1) fixed this. I wonder if the stack > > clash fix has broken ASan. > > The address space change that went into 4.11.11-1 and might have > triggered this is "binfmt_elf: use ELF_ET_DYN_BASE only for PIE" (CVE- > 2017-1000370, CVE-2017-1000371). This moved PIEs to lower addresses on > x86 (starting at 0x40 on i386 and 0x1 on amd4) while > keeping the dynamic linker in the mmap area. It seems like the behavior will be reverted [1] in the kernel and no change in GCC is necessary at the moment. Kind regards, Sven [1] https://lkml.kernel.org/r/20170807201542.GA21271@beast signature.asc Description: This is a digitally signed message part.
Bug#950624: libgcc-s1: libgcc_s.so.1 can be missing after upgrade on usrmerge systems
Package: libgcc-s1 Version: 10-20200202-1 Severity: serious On systems where /lib is a symlink to /usr/lib (which is the case for every new buster installation, for instance), it can easily happen that /usr/lib/$DEB_HOST_MUTIARCH/libgcc_s.so.1 disappears on upgrades. This happens whenever libgcc-s1 is unpacked before the new libgcc1, because the old libgcc1 package ships /lib/$DEB_HOST_MUTIARCH/libgcc_s.so.1 which is in the same place, but unfortunately dpkg does not detect that this means there is a file conflict. This actually happened to me in a usrmerge chroot, here is the relevant excerpt from dpkg.log: , | # grep libgcc.*1: /var/log/dpkg.log | 2020-02-04 10:02:17 install libgcc-s1:amd64 10-20200202-1 | 2020-02-04 10:02:17 status half-installed libgcc-s1:amd64 10-20200202-1 | 2020-02-04 10:02:17 status unpacked libgcc-s1:amd64 10-20200202-1 | 2020-02-04 10:02:17 configure libgcc-s1:amd64 10-20200202-1 | 2020-02-04 10:02:17 status unpacked libgcc-s1:amd64 10-20200202-1 | 2020-02-04 10:02:17 status half-configured libgcc-s1:amd64 10-20200202-1 | 2020-02-04 10:02:17 status installed libgcc-s1:amd64 10-20200202-1 | 2020-02-04 10:02:17 upgrade libgcc1:amd64 1:9.2.1-1 1:10-20200202-1 | 2020-02-04 10:02:17 status half-configured libgcc1:amd64 1:9.2.1-1 | 2020-02-04 10:02:17 status unpacked libgcc1:amd64 1:9.2.1-1 | 2020-02-04 10:02:17 status half-installed libgcc1:amd64 1:9.2.1-1 | 2020-02-04 10:02:17 status unpacked libgcc1:amd64 1:10-20200202-1 | 2020-02-04 10:02:17 configure libgcc1:amd64 1:10-20200202-1 | 2020-02-04 10:02:17 status unpacked libgcc1:amd64 1:10-20200202-1 | 2020-02-04 10:02:17 status half-configured libgcc1:amd64 1:10-20200202-1 | 2020-02-04 10:02:17 status installed libgcc1:amd64 1:10-20200202-1 ` Fortunately "apt reinstall libgcc-s1" remedies the situation, but if the system is rebooted before that, the effects could be more drastic (see #950254 and #950551). -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.1-nouveau (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#954826: libgcc-8-dev: depends on unavailable version of libgcc-s1
Package: libgcc-8-dev Version: 8.4.0-2 Severity: grave The latest version of gcc-8 is not installable because libgcc-8-dev depends on libgcc-s1 (>= 1:8.4.0-2), but the version of libgcc-s1 in the archive does not have an epoch and is therefore too low to fulfill this requirement. The same holds for libgcc-7-dev 7.5.0-6.
Re: Processed: raising severity of GCC-13 ftbfs issues, preparing for the GCC defaults change
On Wednesday, 5 July 2023 14:59:14 CEST Debian Bug Tracking System wrote: > Processing commands for cont...@bugs.debian.org: [...] > > severity 1037638 important > Bug #1037638 [src:ecdsautils] ecdsautils: ftbfs with GCC-13 > Severity set to 'important' from 'normal' [...] > Please contact me if you need assistance. Yes, this bug is unreproducible as said in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037638#10 I only didn't close it because I was waiting for a reply and it was mentioned in the initial mail not to close it until a follow-up test rebuild. I must now assume that this was never done and I should actually close the ticket as unreproducible. Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#995002: libffi-dev: doc-base file references non-existing files
Package: libffi-dev Version: 3.4.2-2 Tags: patch The libffi-dev.doc-base file references files which no longer exist. This leads to complaints from install-docs as well as lintian errors. The following patch takes care of that and also ensures that the doc-base file does not need to be updated again on the next soname change. diff -Nru libffi-3.4.2/debian/libffi-dev.doc-base libffi-3.4.2/debian/libffi-dev.doc-base --- libffi-3.4.2/debian/libffi-dev.doc-base 2017-05-12 22:24:12.0 +0200 +++ libffi-3.4.2/debian/libffi-dev.doc-base 2021-09-24 17:11:36.0 +0200 @@ -14,5 +14,5 @@ Section: Programming Format: HTML -Index: /usr/share/doc/libffi7/html/index.html -Files: /usr/share/doc/libffi7/html/*.html +Index: /usr/share/doc/libffi-dev/html/index.html +Files: /usr/share/doc/libffi-dev/html/*.html
Re: Bug#1075573: tightvnc: ftbfs with GCC-14
Hello debian-gcc team, On Fri, 2024-07-05 at 23:48 +0200, Sven Geuer wrote: > On Wed, 2024-07-03 at 12:46 +, Matthias Klose wrote: > > > Package: src:tightvnc > > Version: 1:1.3.10-8 > > [...] > > Please keep the issue open until the package can be built in > > a follow-up test rebuild. I wonder when this test rebuild will happen. > > > > The package fails to build in a test rebuild on at least amd64 with > > gcc-14/g++-14, but succeeds to build with gcc-13/g++-13. > > [...] > > tightvnc 1:1.3.10-9 fixes the issue according to my tests. > > As requested above, I keep the bug open. As a reminder, tightvnc 1:1.3.10-9 fixes the issue. Best, Sven -- GPG Fingerprint 3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585 signature.asc Description: This is a digitally signed message part
a problem with building ocaml on sparc with gcc 3.2 ...
Hello, ... I encounter this problem when building ocaml with gcc 3.2 on sparc : boot/ocamlrun boot/ocamlc -nostdlib -I boot -linkall -o ocaml.tmp toplevel/toplevellib.cma toplevel/topstart.cmo make[1]: *** [ocaml] Bus error make[1]: Leaving directory `/home/luther/ocaml-3.06' make: *** [build-stamp] Error 2 Well, you may say that this is an ocaml problem and has nothing to do with gcc, but with gcc 2.95, it works fine, and the boot/ocamlrun and boot/ocamlc executables are the first ones, built with gcc from c sources. I contacted upstream about it, but got no reply so far, and well, since gcc 3.2 is now our official gcc, i think it is important that this is solved. I know nothing about sparcs, nor the gcc internals, but in order to investigate this more deeply, could someone give me a hint of what is causing this Bus error (well, not what is causing the problem in this precise case, altough that would be fine too, but what is causing it in general) so i know what i am looking for in the source code. Notice, that ocamlc builds fine with gcc 3.2 on all the other arches, if i am not wrong. Thanks in advance for any help you may give me. Friendly, Sven Luther
Bug#180837: undefined symbol: _ZTVN10__cxxabiv120__si_class_type_infoE on the autobuilders.
Package: libstdc++5-dev Version: 1:3.2.2-1 Hello, ... I am not really sure if this is a problem with this package or a problem with the autobuilders, but in doubt, i fill a bug report. I have a package, lablgl, for which you can find the build log here : http://buildd.debian.org/fetch.php?&pkg=lablgl&ver=0.99-4&arch=powerpc&stamp=1045119454&file=log&as=raw or http://buildd.debian.org/build.php?pkg=lablgl This package is just a set of opengl and GLU bindings for the ocaml language, and it fails to load on the autobuilders (all 10 of them) with : ocamlmktop -I . -I +labltk -o lablgltop \ labltk.cma lablgl.cma togl.cma Error on dynamically loaded library: ./dlllablgl.so: undefined symbol: _ZTVN10__cxxabiv120__si_class_type_infoE It seems that _ZTVN10__cxxabiv120__si_class_type_infoE is a C++ symbol, provided by libstdc++5-dev, and it is pulled in by xlibmesa-glu-dev, which i build depend upon. Now the strange thing, and the one which has me completely bewildered is that if i build on my home box, or if i build on voltaire (ppc box running sid), then it works flawlessly. I guess it is a problem with the autobuilders not being uptodate or something such, but i don't think it is a problem with my build dependencies, since as said libstdc++5-dev is pulled in by xlibmesa-glu-dev. Friendly, Sven Luther
Bug#473366: libstdc++5: Depends on unavailable version of gcc-3.3-base
Package: libstdc++5 Version: 1:3.3.6-16 Severity: grave libstdc++5 is not installable, as it depends on gcc-3.3-base (>= 1:3.3.6-16) which has not been built, according to http://packages.qa.debian.org/g/gcc-3.3/news/20080329T183205Z.html. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#508324: ftp.debian.org: gcc-4.2-base is not really required
Package: ftp.debian.org Severity: serious The priority of gcc-4.2-base should be downgraded to optional from required, because the only reason that it was ever required in the first place is that libgcc1 used to depend on it; and that package is now built from the gcc-4.3 source package. Severity set to serious because gcc-4.2-base is currently installed for no reason on every freshly installed system, and that should be fixed for Lenny. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 2.6.27.8-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#532871: g++-4.4: No warning about value-altering conversion inspite of -Wconversion and -Wsign-conversion
Package: g++-4.4
Version: 4.4.0-5
Severity: normal
The following program compiles cleanly using the given command line:
#include
using namespace std;
int main()
{
unsigned int j = 5;
double t;
t = -j;
cout << t << endl;
}
Command line:
g++-4.4 -g -Wall -Wextra -Wconversion -Wsign-conversion test.cc -o test
The output of the program is
4.29497e+09
which is what is expected. But I would also expect some kind of
warning.
The same behaviour exists for gcc-4.3, g++-4.3 and gcc-4.4 (and
probably any other gcc version).
Cheers,
Sven
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.29-1-686-bigmem (SMP w/2 CPU cores)
Locale: LANG=C, lc_ctype=de...@euro (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash
Versions of packages g++-4.4 depends on:
ii gcc-4.4 4.4.0-5 The GNU C compiler
ii gcc-4.4-base4.4.0-5 The GNU Compiler Collection (base
ii libc6 2.9-12 GNU C Library: Shared libraries
ii libcloog-ppl0 0.15-1 the Chunky Loop Generator (runtime
ii libgmp3c2 2:4.2.4+dfsg-8.1 Multiprecision arithmetic library
ii libgmpxx4ldbl 2:4.2.4+dfsg-8.1 Multiprecision arithmetic library
ii libmpfr1ldbl2.4.1-2 multiple precision floating-point
ii libppl-c2 0.10.2-2 Parma Polyhedra Library (C interfa
ii libppl7 0.10.2-2 Parma Polyhedra Library (runtime l
ii libstdc++6-4.4-dev 4.4.0-5 The GNU Standard C++ Library v3 (d
g++-4.4 recommends no packages.
Versions of packages g++-4.4 suggests:
pn g++-4.4-multilib (no description available)
pn gcc-4.4-doc(no description available)
pn libstdc++6-4.4-dbg (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: freeze exception for gcc-4.5 (i386, amd64 only)
On 2010-08-18 19:49 +0200, Julien Cristau wrote: > On Wed, Aug 18, 2010 at 19:12:37 +0200, Ludovic Brenta wrote: > >> Personally, I'd be comfortable with gcc-4.5 in Squeeze except for this >> part: >> >> > - the upload will build several runtime libraries from the 4.5 >> > sources. Regression tests did pass for the runtime libs built >> > from the 4.5 sources and for 4.4 using the runtime libs from >> > 4.5. >> >> This really gives me the creeps. >> >> I would propose that gcc-4.5 be allowed in testing, with priority extra, >> but not that the "several runtime libraries" (which ones are they?) be >> built from the gcc-4.5 sources. >> >> Would that be acceptable to everyone? >> > I assume gcc-4.5 needs libgcc1 from gcc-4.5. As well as libgomp1, and g++-4.5 needs libstdc++6 from gcc-4.5. Sven -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aaojiyqs@turtle.gmx.de
Bug#564500: ftp.debian.org: override: gcc-4.3-base:libs/optional
Package: ftp.debian.org Severity: normal X-Debbugs-CC: Debian GCC Maintainers Please downgrade the priority of gcc-4.3-base to optional, now that libgcc is built from the gcc-4.4 sources. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#361024: note on "2.4 is deprecated"
On Thu, Apr 13, 2006 at 03:26:10PM -0700, Steve Langasek wrote: > Rather, I think it would mean people would be upset about 2.4 being dropped > with little official notice -- but yes, this should be announced sooner > rather than later. The announcement of the obscolecence of the 2.4 kernels by the kernel team a few weeks ago is already a good step into this direction. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384278: gcc: postinst installs dangling symlink for manpage
Package: gcc Version: 4:4.1.1-6 Severity: normal Today I got mail from the mandb cron script: mandb: warning: /usr/share/man/man1/cc.1.gz is a dangling symlink mandb: warning: /usr/share/man/man1/c++.1.gz is a dangling symlink This is because the gcc postinst installs the following alternative: , | update-alternatives --quiet \ | --install /usr/bin/cc cc /usr/bin/gcc 20 \ | --slave /usr/share/man/man1/cc.1.gz cc.1.gz /usr/share/man/man1/gcc.1.gz ` But /usr/share/man/man1/gcc.1.gz does not exist. Note that the g++ package suffers from the same problem. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17.9 Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages gcc depends on: ii cpp 4:4.1.1-6 The GNU C preprocessor (cpp) ii gcc-4.1 4.1.1-11 The GNU C compiler Versions of packages gcc recommends: ii libc6-dev [libc-dev] 2.3.6.ds1-2 GNU C Library: Development Librari -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384278: gcc: postinst installs dangling symlink for manpage
reassign 383755 gcc-defaults merge 383755 384278 thanks Sorry for the duplicate report. I didn't notice #383755 because it was filed against the wrong package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#385733: gcc-4.1-base: copyright file still contains GFDL text
Package: gcc-4.1-base Version: 4.1.1-13 Severity: normal Since the documentation has been removed :-(, there is no need to mention its license in debian/copyright any more. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17.11 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#385732: gcc-defaults: Non-free files in source package
Package: gcc-defaults Version: 1.42 Severity: serious The source package still contains the non-free files fsf-funding.7, gfdl.7 and gpl.7, apparently for no good reason since they aren't installed. Please remove them. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17.11 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#385732: gcc-defaults: Non-free files in source package
Matthias Klose wrote: The source package still contains the non-free files fsf-funding.7, ok. gfdl.7 and gpl.7, apparently for no good reason since they aren't installed. Please remove them. no, license texts can be included. there's no reason to remove them. But the GFDL is not the license for any package built from gcc-defaults, so why should it be in the source package? Having the GPL text is ok, but it is a bit odd that it's a man page rather than plain text. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#390093: gcc-4.1-doc: Overwrites copyright and Debian changelog of gcc-4.1-base
Package: gcc-4.1-doc-non-dfsg Version: 4.1.1-nf1 Severity: serious In previous versions of gcc-4.1-doc (up to 4.1.1-10), /usr/share/doc/gcc-4.1-doc was a symlink to gcc-4.1-base. Because dpkg follows the symlink when upgrading the package, your files end up in /usr/share/doc/gcc-4.1-base, overwriting the files there (dpkg does not detect that clash, unfortunately). To resolve this issue, I suggest you create a prescript which tests if usr/share/doc/gcc-4.1-doc is a symlink and, if this is the case, removes it. Note that you must take care to delete spurious files from previous versions of the gcc-4.1-doc package in usr/share/doc/gcc-4.1-base as well. Since the other packages built from the same source probably have the same problem :-(, I've assigned this bug to the source package. Good luck in resolving this mess and thanks for packaging the GCC documentation. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#637174: gcc-4.6-multilib: dangling symlink /usr/lib/i386-linux-gnu/gcc/i486-linux-gnu/4.6/64/libquadmath.so
Package: gcc-4.6-multilib Version: 4.6.1-6 , | $ file /usr/lib/i386-linux-gnu/gcc/i486-linux-gnu/4.6/64/libquadmath.so | /usr/lib/i386-linux-gnu/gcc/i486-linux-gnu/4.6/64/libquadmath.so: broken symbolic link to `../../../../../../lib64/libquadmath.so.0' ` Looks like gcc-4.6-multilib ought to depend on lib64quadmath0. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.0.1-nouveau (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gcc-4.6-multilib depends on: ii gcc-4.6 4.6.1-6GNU C compiler ii gcc-4.6-base 4.6.1-6GCC, the GNU Compiler Collection ( ii lib64gcc1 1:4.6.1-6 GCC support library (64bit) ii lib64gomp14.6.1-6GCC OpenMP (GOMP) support library ii libc6-dev-amd64 2.13-14Embedded GNU C Library: 64bit Deve gcc-4.6-multilib recommends no packages. Versions of packages gcc-4.6-multilib suggests: pn lib64mudflap0 (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vcu76q4j@turtle.gmx.de
Bug#638418: gcc-multilib: needs to ensure that /usr/include/asm is a symlink
Package: gcc-multilib Version: 4:4.6.1-2 Severity: serious I've been tearing my hair out WTF this suddenly happened: , | $ echo '#include ' > junk.c | $ gcc -m64 -c junk.c | In file included from /usr/include/bits/errno.h:25:0, | from /usr/include/errno.h:36, | from junk.c:1: | /usr/include/linux/errno.h:4:23: fatal error: asm/errno.h: No such file or directory ` It turns out that /usr/include/asm is an empty directory and not a symlink to i386-linux-gnu/asm as shipped in the package. And linux-libc-dev has only recently switched to multiarch paths and dropped the /usr/include/asm directory: , | linux-2.6 (3.0.0-2) unstable; urgency=high | [...] | [ Ben Hutchings ] | * linux-libc-dev: Install include/asm under arch-specific directory | (thanks to Aurelien for correcting the directory); mark package as | multi-arch-coinstallable (Multi-Arch: same) ` Possible solution: depend on linux-libc-dev (>= 3.0.0-2) on Linux architectures and ship a postinst that converts /usr/include/asm into a symlink if it's still a directory. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.0.3-nouveau (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gcc-multilib depends on: ii cpp 4:4.6.1-2 GNU C preprocessor (cpp) ii gcc 4:4.6.1-2 GNU C compiler ii gcc-4.6-multilib 4.6.1-7GNU C compiler (multilib files) gcc-multilib recommends no packages. gcc-multilib suggests no packages. -- no debconf information -- debsums errors found: debsums: no md5sums for gcc-multilib -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwkxyf1y@turtle.gmx.de
Re: Bug#638867: linux-libc-dev: errno.h includes non-existent asm/errno.h for -m32
reassign 638867 gcc-multilib forcemerge 638418 638867 thanks On 2011-08-22 17:55 +0200, François Revol wrote: > Le 22/08/2011 17:48, Sven Joachim a écrit : >> On 2011-08-22 17:07 +0200, François Revol wrote: >> >>> Package: linux-libc-dev >>> Version: 3.0.0-2 >>> Severity: important >>> >>> Last update seems to break compiling some Haiku build tools which currently >>> require -m32. Build log below. >>> >> I bet /usr/include/asm is an empty directory on your system while it's >> supposed to be a symlink to x86_64-linux-gnu/asm. See >> http://bugs.debian.org/638418 for details. >> > > Indeed it's an empty folder here. Remove it and either create the symlink yourself or reinstall the gcc-multilib package. > Seems to be the same cause then, I first thought it was again a bug in > libc6-dev-i386 until I apt-file searched, and now you tell me it's in > gcc-multilib :P I'm reassigning and merging it. Cheers, Sven -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aab1fmw1@turtle.gmx.de
Bug#321591: gcc-4.0: gcc does not print messages in German
Package: gcc-4.0 Version: 4.0.1-3 Severity: normal Tags: l10n Gcc always prints its messages in English, rather than my preferred German. Running "strace gcc-4.0 -v" shows that gcc tries to read the german messages from the file /usr/share/locale/de/LC_MESSAGES/gcc.mo, which does not exist. It had better read /usr/share/locale/de/LC_MESSAGES/gcc-4.0.mo, which is there. And indeed, running "ln -s gcc-4.0.mo /usr/share/locale/de/LC_MESSAGES/gcc.mo" works around the problem. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.31 Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages gcc-4.0 depends on: ii binutils2.16.1-2 The GNU assembler, linker and bina ii cpp-4.0 4.0.1-3 The GNU C preprocessor ii gcc-4.0-base4.0.1-3 The GNU Compiler Collection (base ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libgcc1 1:4.0.1-3GCC support library Versions of packages gcc-4.0 recommends: ii libc6-dev 2.3.2.ds1-22 GNU C Library: Development Librari ii libmudflap0-dev 4.0.1-3 GCC mudflap support libraries (dev -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#321591: gcc-4.0: gcc does not print messages in German
From my original report: Package: gcc-4.0 Version: 4.0.1-3 Severity: normal Tags: l10n Gcc always prints its messages in English, rather than my preferred German. Running "strace gcc-4.0 -v" shows that gcc tries to read the german messages from the file /usr/share/locale/de/LC_MESSAGES/gcc.mo, which does not exist. It had better read /usr/share/locale/de/LC_MESSAGES/gcc-4.0.mo, which is there. I just installed version 4.0.1-5 of gcc-4.0 and the corresponding locales package, and now the problem is reversed: gcc tries to read /usr/share/locale/de/LC_MESSAGES/gcc-4.0.mo, but all there is is /usr/share/locale/de/LC_MESSAGES/gcc.mo :-( , so I still get English messages. It seems you have to reopen the bug. Regards, Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#321591: gcc-4.0: gcc does not print messages in German
reopen 321591 reassign 321591 gcc-4.0-locales stop I have reassigned the bug to the gcc-4.0-locales package, because the problem is now there: As of version 4.0.1-5, the package contains files /usr/share/locale/*/LC_MESSAGES/gcc.mo, which should be named /usr/share/locale/*/LC_MESSAGES/gcc-4.0.mo instead. -- Sven Joachim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#336167: gcc-4.0: breaks kernel builds in random ways.
Package: gcc-4.0
Version: 4.0.2-3
Severity: grave
Justification: renders package unusable
Well, i confirm that this problem is also present on powerpc, using
gcc-4.0 4.0.2-3 makes the kernel build fail, while using -2 seems to be
ok. I have heard people mentioning two other arches where this is the
case (m68k and mips i think) on irc (on #debian-release i think even,
not sure), but no bug has been filed so i do it now.
My powerpc builds failed with :
08:22 < svenl> kernel/spinlock.c:72:61: error: macro
"_spin_lock_irqsave" requires 2 arguments, but only 1 given
08:22 < svenl> kernel/spinlock.c:99:59: error: macro
"_read_lock_irqsave" requires 2 arguments, but only 1 given
08:22 < svenl> kernel/spinlock.c:126:60: error: macro
"_write_lock_irqsave" requires 2 arguments, but only 1 given
08:22 < svenl> /bin/sh: line 1: 7269 Done(1) gcc -m32
-E -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
-fno-common
-ffreestanding -O2 -fomit-frame-pointer -Iarch/ppc
-msoft-float -pipe -ffixed-r2 -mmultiple -mstring -Wa,-maltivec
-Wdeclaration-after-statement -Wno-pointer-sign
-D__GENKSYMS__ -Wp,-MD,kernel/.spinlock.o.d -nostdinc -isystem
/usr/lib/gcc/powerpc-linux-gnu/4.0.3/include -D__KERNEL__
-Iinclude -Iarch/ppc -Iarch/ppc/include -Wall -Wundef
-Wstrict-prototypes
-Wno-trigraphs -fno-strict-aliasing -fno-common
-ffreestanding -O2 -fomit-frame-pointer -Iarch/ppc -msoft-float -pipe
-ffixed-r2 -mmultiple
-mstring -Wa,-maltivec -Wdeclaration-after-statement
-Wno-pointer-sign -DKBUILD_BASENAME=spinlock -DKBUILD_MODNAME=spinlock
kernel/spinlock.c
And then later :
08:42 < svenl> fs/ext2/acl.c:483: error: called object '0u' is not a
function
08:42 < svenl> {standard input}: Assembler messages:
08:42 < svenl> {standard input}:39: Error: symbol `error' is already
defined
08:42 < svenl> {standard input}:57: Error: symbol `retval' is already
defined
08:42 < svenl> {standard input}:72: Error: symbol `name_index' is
already defined
08:42 < svenl> {standard input}:77: Error: symbol `value' is already
defined
While a 4.0.2-2 build passed fine.
Friendly,
Sven Luther
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: powerpc (ppc)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-rc5-powerpc
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages gcc-4.0 depends on:
ii binutils 2.16.1cvs20050902-1 The GNU assembler, linker and bina
ii cpp-4.0 4.0.2-3 The GNU C preprocessor
ii gcc-4.0-base 4.0.2-3 The GNU Compiler Collection (base
ii libc62.3.5-7 GNU C Library: Shared libraries an
ii libgcc1 1:4.0.2-3 GCC support library
Versions of packages gcc-4.0 recommends:
ii libc6-dev 2.3.5-7GNU C Library: Development Librari
pn libmudflap0-dev(no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#336167: gcc-4.0: breaks kernel builds in random ways.
On Tue, Nov 01, 2005 at 01:33:35PM +0100, Thiemo Seufer wrote: > Thiemo Seufer wrote: > > Sven Luther wrote: > > > Package: gcc-4.0 > > > Version: 4.0.2-3 > > > Severity: grave > > > Justification: renders package unusable > > > > > > > > > Well, i confirm that this problem is also present on powerpc, using > > > gcc-4.0 4.0.2-3 makes the kernel build fail, while using -2 seems to be > > > ok. I have heard people mentioning two other arches where this is the > > > case (m68k and mips i think) on irc (on #debian-release i think even, > > > not sure), but no bug has been filed so i do it now. > > > > > > My powerpc builds failed with : > > > > For mips 2.6.12, which built fine with gcc 4.0.2-2: > > > > CC [M] fs/reiserfs/tail_conversion.o > > fs/reiserfs/tail_conversion.c: In function 'direct2indirect': > > fs/reiserfs/tail_conversion.c:138: internal compiler error: > > Floating point exception > > Please submit a full bug report, > > with preprocessed source if appropriate. > > See http://gcc.gnu.org/bugs.html> for instructions. > > For Debian GNU/Linux specific bug reporting instructions, > > see . > > make[5]: *** [fs/reiserfs/tail_conversion.o] Error 1 > > make[4]: *** [fs/reiserfs] Error 2 > > > > Sorry, no testcase yet. > > The attached testcase triggers this bug on mips-linux when compiled > with "gcc -O2 -mabi=64 -c" > > The appended patch reverts a single line of the diff between 4.0.2-2 > and 4.0.2-3 and lets the testcase succeed. I don't know that part of > gcc enough to judge if it is a valid fix for the problem. > > Sven, could you test if this fixes also the problem you see? Ok, i will, altough i would need to rebuild gcc, so it will not be before tomorrow that i can test it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#336167: gcc-4.0: breaks kernel builds in random ways.
On Thu, Nov 03, 2005 at 01:28:57PM +0100, Thiemo Seufer wrote: > tags 336167 +patch > thanks > > Sven Luther wrote: > [snip] > > > The appended patch reverts a single line of the diff between 4.0.2-2 > > > and 4.0.2-3 and lets the testcase succeed. I don't know that part of > > > gcc enough to judge if it is a valid fix for the problem. > > > > > > Sven, could you test if this fixes also the problem you see? > > > > Ok, i will, altough i would need to rebuild gcc, so it will not be before > > tomorrow that i can test it. > > The appended patch fixes the problems for mips-linux, tested with a > kernel build and builds of ncpfs and mypasswordsafe. > > Sven, can you test this patch? Do i need to apply the above mentioned patch too or just this one ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#336167: gcc-4.0: breaks kernel builds in random ways.
On Thu, Nov 03, 2005 at 02:01:18PM +0100, Thiemo Seufer wrote: > Sven Luther wrote: > > On Thu, Nov 03, 2005 at 01:28:57PM +0100, Thiemo Seufer wrote: > > > tags 336167 +patch > > > thanks > > > > > > Sven Luther wrote: > > > [snip] > > > > > The appended patch reverts a single line of the diff between 4.0.2-2 > > > > > and 4.0.2-3 and lets the testcase succeed. I don't know that part of > > > > > gcc enough to judge if it is a valid fix for the problem. > > > > > > > > > > Sven, could you test if this fixes also the problem you see? > > > > > > > > Ok, i will, altough i would need to rebuild gcc, so it will not be > > > > before > > > > tomorrow that i can test it. > > > > > > The appended patch fixes the problems for mips-linux, tested with a > > > kernel build and builds of ncpfs and mypasswordsafe. > > > > > > Sven, can you test this patch? > > > > Do i need to apply the above mentioned patch too or just this one ? > > Only this one (it is already in upstream, btw.), the previous one was wrong. Ok, will do, but don't expect result soon, i think my box uses days to run all the gcc test cases (failing over all the ppc64 ones obviously). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#335578: ocamlopt.opt segfaults on Alpha
On Mon, Nov 07, 2005 at 05:16:53PM +0100, Julien Cristau wrote: > Hi, > > Starting from ocaml version 3.08.3-8, ocamlopt.opt doesn't work at all > on alpha. Since 3.08.3-7 built fine, I think this is a toolchain issue. > > 3.08.3-7 was built with gcc-4.0 4.0.1-4, binutils 2.16.1-2 and > libc6.1-dev 2.3.5-3, while 3.08.3-8 was built with gcc-4.0 4.0.1-6, > binutils 2.16.1cvs20050902-1 and libc6.1-dev 2.3.5-5. binutils is the likely culprit, i would say, especially given the way ocamlopt fails, and the fact that it was a cvs snapshot only augments that fear. Julien, could you maybe try downgrading to the older binutils version, and seeing what went wrong ? As said on irc, the likely solution here would be to disable the alpha native compilers until the solution is found. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355439: gcc-4.0-base: Debian changelog and copyright lost after upgrade
Package: gcc-4.0-base
Version: 4.0.2-10
Severity: serious
It looks as if bug #346171 has raised its ugly head again, since somehow the
files /usr/share/doc/gcc-4.0-base{copyright, changelog.Debian.gz} disappeared
after the upgrade from 4.0.2-9 to 4.0.2-10:
$ ls /usr/share/doc/gcc-4.0-base
Ada NEWS.gz README.Debian.gz cpp.html gcc.html
C++ NEWS.htmlTODO.Debian cppinternals.html gccint.html
FAQ.gz README.Bugs changelog.gz gcctest-summary.gz
One of the maintainer scripts must be faulty, but I don't know which. Anyway,
here is the list of packages from the gcc-4.0 source which I have installed:
ii cpp-4.0 4.0.2-10The GNU C preprocessor
ii cpp-4.0-doc 4.0.2-10Documentation for the GNU C preprocessor
(cpp)
ii g++-4.0 4.0.2-10The GNU C++ compiler
ii gcc-4.0 4.0.2-10The GNU C compiler
ii gcc-4.0-base4.0.2-10The GNU Compiler Collection (base package)
ii gcc-4.0-doc 4.0.2-10Documentation for the GNU compilers (gcc,
gobj
ii gcc-4.0-locales 4.0.2-10The GNU C compiler (native language support
fi
ii gnat-4.04.0.2-10The GNU Ada compiler
ii lib64gcc1 4.0.2-10GCC support library (64bit)
ii libgcc1 4.0.2-10GCC support library
ii libgnat-4.0 4.0.2-10Runtime library for GNU Ada applications
ii libmudflap0 4.0.2-10GCC mudflap shared support libraries
ii libmudflap0-dev 4.0.2-10GCC mudflap support libraries (development
fil
ii libstdc++6 4.0.2-10The GNU Standard C++ Library v3
ii libstdc++6-4.0- 4.0.2-10The GNU Standard C++ Library v3
(development f
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.4.32
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355439: gcc-4.0-base: Debian changelog and copyright lost after upgrade
Matthias Klose wrote:
Sven Joachim writes:
Package: gcc-4.0-base
Version: 4.0.2-10
Severity: serious
It looks as if bug #346171 has raised its ugly head again, since somehow the
files /usr/share/doc/gcc-4.0-base{copyright, changelog.Debian.gz} disappeared
after the upgrade from 4.0.2-9 to 4.0.2-10:
oops, found it, still a libstdc++6-4.0-dev.preinst
No, there is nothing wrong with this preinst. It looks as follows:
,
| #! /bin/sh -e
|
| case "$1" in
| upgrade)
| # upgrading from older experimental gcc-4.0 package
| if [ -d /usr/include/c++/4.0 ] && [ ! -h /usr/include/c++/4.0 ]; then
| mv /usr/include/c++/4.0 /usr/include/c++/4.0.0
| ln -s 4.0.0 /usr/include/c++/4.0
| fi
| esac
|
`
This does nothing in /usr/share/doc. Actually, there is nothing wrong with
any maintainer script in version 4.0.2-10. The problem was that the scripts
in the _previous_ version were bad. Explanation:
After some investigation I found out the reason for the lost changelog and
copyright files. The problem lies actually in the previous (4.0.2-9) versions
of lib64gcc1 and libgcc1. These packages contain the files
/usr/share/doc/lib{,64}gcc1/{changelog.Debian.gz,copyright}. But the preinst
scripts inadvertedly changed the directories to symlinks when upgrading from
an older version:
,
| #! /bin/sh -e
|
| case "$1" in
| upgrade)
| docdir=/usr/share/doc/libgcc1
| if [ -d $docdir ] && [ ! -h $docdir ]; then
| rm -rf $docdir
| ln -s gcc-4.0-base $docdir
| fi
| esac
|
`
is the libgcc1 preinst, for instance. So /usr/share/doc/libgcc1 became a
symlink to /usr/share/doc/gcc-base-4.0, but /var/lib/dpkg/info/libgcc1.list
still contains the lines
/usr/share/doc/libgcc1/copyright
/usr/share/doc/libgcc1/changelog.Debian.gz
, with /usr/share/doc/libgcc1 being the same place as
/usr/share/doc/gcc-4.0-base. You see the problem? Upgrading to libgcc1
4.0.2-10, dpkg will remove these two files, since they are not in the new
package. Thus, if the libgcc1 package is unpacked _after_ gcc-4.0-base, the
copyright and Debian changelog are lost, and exactly that happened to me as I
could tell from dpkg's log, an excerpt containing only the affected packages
follows:
2006-03-05 16:27:06 upgrade lib64gcc1 1:4.0.2-9 1:4.0.2-10
2006-03-05 16:27:06 status half-configured lib64gcc1 1:4.0.2-9
2006-03-05 16:27:06 status unpacked lib64gcc1 1:4.0.2-9
2006-03-05 16:27:06 status half-installed lib64gcc1 1:4.0.2-9
2006-03-05 16:27:06 status half-installed lib64gcc1 1:4.0.2-9
2006-03-05 16:27:06 status unpacked lib64gcc1 1:4.0.2-10
2006-03-05 16:27:06 status unpacked lib64gcc1 1:4.0.2-10
2006-03-05 16:27:16 upgrade gcc-4.0-base 4.0.2-9 4.0.2-10
2006-03-05 16:27:16 status half-configured gcc-4.0-base 4.0.2-9
2006-03-05 16:27:16 status unpacked gcc-4.0-base 4.0.2-9
2006-03-05 16:27:16 status half-installed gcc-4.0-base 4.0.2-9
2006-03-05 16:27:16 status half-installed gcc-4.0-base 4.0.2-9
2006-03-05 16:27:16 status unpacked gcc-4.0-base 4.0.2-10
2006-03-05 16:27:16 status unpacked gcc-4.0-base 4.0.2-10
2006-03-05 16:27:16 upgrade libgcc1 1:4.0.2-9 1:4.0.2-10
2006-03-05 16:27:16 status half-configured libgcc1 1:4.0.2-9
2006-03-05 16:27:16 status unpacked libgcc1 1:4.0.2-9
2006-03-05 16:27:16 status half-installed libgcc1 1:4.0.2-9
2006-03-05 16:27:16 status half-installed libgcc1 1:4.0.2-9
2006-03-05 16:27:16 status unpacked libgcc1 1:4.0.2-10
2006-03-05 16:27:16 status unpacked libgcc1 1:4.0.2-10
2006-03-05 16:27:17 status unpacked gcc-4.0-base 4.0.2-10
2006-03-05 16:27:17 status half-configured gcc-4.0-base 4.0.2-10
2006-03-05 16:27:17 status installed gcc-4.0-base 4.0.2-10
2006-03-05 16:27:17 status unpacked libgcc1 1:4.0.2-10
2006-03-05 16:27:17 status half-configured libgcc1 1:4.0.2-10
2006-03-05 16:27:24 status installed libgcc1 1:4.0.2-10
2006-03-05 16:27:35 status unpacked lib64gcc1 1:4.0.2-10
2006-03-05 16:27:35 status half-configured lib64gcc1 1:4.0.2-10
2006-03-05 16:27:35 status installed lib64gcc1 1:4.0.2-10
So the explanation is found. How to get out of this mess and ensure proper
upgrading of the gcc-4.0 packages is another matter, which is left as an
exercise for you. ;-)
Arguably, it might be a bug in dpkg that it even installed the 4.0.2-9
versions of the packages, since /usr/share/doc/libgcc1/copyright and
/usr/share/doc/gcc-4.0-base/copyright were the same file in these versions and
dpkg should have detected that during unpacking. I will check the long list
of dpkg bugs to see whether such an issue has already been reported.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355439: gcc-4.0-base: Debian changelog and copyright lost after upgrade
reassign 355439 libgcc1 thanks Reassigning this to libgcc1, since I found out this package (and lib64gcc1) at fault (see my previous message). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355439: gcc-4.0-base: Debian changelog and copyright lost after upgrade
Matthias Klose wrote:
reassign 355439 gcc-4.0-base
thanks
Sven Joachim writes:
reassign 355439 libgcc1
thanks
Reassigning this to libgcc1, since I found out this package
(and lib64gcc1) at fault (see my previous message).
no, the file is missing in gcc-4.0-base.
Huh? The gcc-4.0-base package _does_ contain the files, they only
got deleted by the unlucky upgrade process of the lib{,64}gcc1
packages, as I had tried to explain.
it will be fixed when gcc-4.1
is uploaded to unstable.
At the moment I don't see how you're going to accomplish that,
since there is the danger that upgrading from version 4.0.2-9
will delete the copyright/changelog files (then living in
/usr/share/doc/gcc-4.1-base !) the same way as they did it for me.
But maybe some magic in the preinst scripts can avoid that.
Regards,
Sven
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355439: gcc-4.0-base: Debian changelog and copyright lost after upgrade
Matthias Klose wrote: But maybe some magic in the preinst scripts can avoid that. Please check the packages at deb http://people.debian.org/~doko/gcc-4.0 ./ Inside a chroot, I upgraded the packages: 4.0.2-6 -> 4.0.2-9 -> 4.0.2-11, but, alas, the copyright and changelog were still lost afterwards. :-( Here is the dpkg log: 2006-03-10 09:23:07 upgrade libstdc++6-4.0-dev 4.0.2-6 4.0.2-9 2006-03-10 09:23:07 status half-configured libstdc++6-4.0-dev 4.0.2-6 2006-03-10 09:23:07 status unpacked libstdc++6-4.0-dev 4.0.2-6 2006-03-10 09:23:07 status half-installed libstdc++6-4.0-dev 4.0.2-6 2006-03-10 09:23:08 status half-installed libstdc++6-4.0-dev 4.0.2-6 2006-03-10 09:23:08 status unpacked libstdc++6-4.0-dev 4.0.2-9 2006-03-10 09:23:08 status unpacked libstdc++6-4.0-dev 4.0.2-9 2006-03-10 09:23:09 upgrade g++-4.0 4.0.2-6 4.0.2-9 2006-03-10 09:23:09 status half-configured g++-4.0 4.0.2-6 2006-03-10 09:23:09 status unpacked g++-4.0 4.0.2-6 2006-03-10 09:23:09 status half-installed g++-4.0 4.0.2-6 2006-03-10 09:23:09 status half-installed g++-4.0 4.0.2-6 2006-03-10 09:23:09 status unpacked g++-4.0 4.0.2-9 2006-03-10 09:23:09 status unpacked g++-4.0 4.0.2-9 2006-03-10 09:23:09 upgrade gcc-4.0 4.0.2-6 4.0.2-9 2006-03-10 09:23:09 status half-configured gcc-4.0 4.0.2-6 2006-03-10 09:23:09 status unpacked gcc-4.0 4.0.2-6 2006-03-10 09:23:09 status half-installed gcc-4.0 4.0.2-6 2006-03-10 09:23:09 status half-installed gcc-4.0 4.0.2-6 2006-03-10 09:23:09 status unpacked gcc-4.0 4.0.2-9 2006-03-10 09:23:10 status unpacked gcc-4.0 4.0.2-9 2006-03-10 09:23:10 upgrade cpp-4.0 4.0.2-6 4.0.2-9 2006-03-10 09:23:10 status half-configured cpp-4.0 4.0.2-6 2006-03-10 09:23:10 status unpacked cpp-4.0 4.0.2-6 2006-03-10 09:23:10 status half-installed cpp-4.0 4.0.2-6 2006-03-10 09:23:10 status half-installed cpp-4.0 4.0.2-6 2006-03-10 09:23:10 status unpacked cpp-4.0 4.0.2-9 2006-03-10 09:23:10 status unpacked cpp-4.0 4.0.2-9 2006-03-10 09:23:10 upgrade libstdc++6 4.0.2-6 4.0.2-9 2006-03-10 09:23:10 status half-configured libstdc++6 4.0.2-6 2006-03-10 09:23:10 status unpacked libstdc++6 4.0.2-6 2006-03-10 09:23:10 status half-installed libstdc++6 4.0.2-6 2006-03-10 09:23:10 status half-installed libstdc++6 4.0.2-6 2006-03-10 09:23:10 status unpacked libstdc++6 4.0.2-9 2006-03-10 09:23:10 status unpacked libstdc++6 4.0.2-9 2006-03-10 09:23:10 upgrade libmudflap0 4.0.2-6 4.0.2-9 2006-03-10 09:23:10 status half-configured libmudflap0 4.0.2-6 2006-03-10 09:23:10 status unpacked libmudflap0 4.0.2-6 2006-03-10 09:23:10 status half-installed libmudflap0 4.0.2-6 2006-03-10 09:23:10 status half-installed libmudflap0 4.0.2-6 2006-03-10 09:23:10 status unpacked libmudflap0 4.0.2-9 2006-03-10 09:23:10 status unpacked libmudflap0 4.0.2-9 2006-03-10 09:23:10 upgrade libmudflap0-dev 4.0.2-6 4.0.2-9 2006-03-10 09:23:10 status half-configured libmudflap0-dev 4.0.2-6 2006-03-10 09:23:10 status unpacked libmudflap0-dev 4.0.2-6 2006-03-10 09:23:10 status half-installed libmudflap0-dev 4.0.2-6 2006-03-10 09:23:10 status half-installed libmudflap0-dev 4.0.2-6 2006-03-10 09:23:11 status unpacked libmudflap0-dev 4.0.2-9 2006-03-10 09:23:11 status unpacked libmudflap0-dev 4.0.2-9 2006-03-10 09:23:11 upgrade lib64gcc1 1:4.0.2-6 1:4.0.2-9 2006-03-10 09:23:11 status half-configured lib64gcc1 1:4.0.2-6 2006-03-10 09:23:11 status unpacked lib64gcc1 1:4.0.2-6 2006-03-10 09:23:11 status half-installed lib64gcc1 1:4.0.2-6 2006-03-10 09:23:11 status half-installed lib64gcc1 1:4.0.2-6 2006-03-10 09:23:11 status unpacked lib64gcc1 1:4.0.2-9 2006-03-10 09:23:11 status unpacked lib64gcc1 1:4.0.2-9 2006-03-10 09:23:11 upgrade gcc-4.0-base 4.0.2-6 4.0.2-9 2006-03-10 09:23:11 status half-configured gcc-4.0-base 4.0.2-6 2006-03-10 09:23:11 status unpacked gcc-4.0-base 4.0.2-6 2006-03-10 09:23:11 status half-installed gcc-4.0-base 4.0.2-6 2006-03-10 09:23:11 status half-installed gcc-4.0-base 4.0.2-6 2006-03-10 09:23:11 status unpacked gcc-4.0-base 4.0.2-9 2006-03-10 09:23:11 status unpacked gcc-4.0-base 4.0.2-9 2006-03-10 09:23:11 upgrade libgcc1 1:4.0.2-6 1:4.0.2-9 2006-03-10 09:23:11 status half-configured libgcc1 1:4.0.2-6 2006-03-10 09:23:11 status unpacked libgcc1 1:4.0.2-6 2006-03-10 09:23:11 status half-installed libgcc1 1:4.0.2-6 2006-03-10 09:23:11 status half-installed libgcc1 1:4.0.2-6 2006-03-10 09:23:11 status unpacked libgcc1 1:4.0.2-9 2006-03-10 09:23:11 status unpacked libgcc1 1:4.0.2-9 2006-03-10 09:23:11 status unpacked gcc-4.0-base 4.0.2-9 2006-03-10 09:23:11 status half-configured gcc-4.0-base 4.0.2-9 2006-03-10 09:23:11 status installed gcc-4.0-base 4.0.2-9 2006-03-10 09:23:11 status unpacked libgcc1 1:4.0.2-9 2006-03-10 09:23:11 status half-configured libgcc1 1:4.0.2-9 2006-03-10 09:23:11 status installed libgcc1 1:4.0.2-9 2006-03-10 09:23:11 status unpacked cpp-4.0 4.0.2-9 2006-03-10 09:23:11 status half-configured cpp-4.0 4.0.2-9 2006-03-10 09:23:11 status installed cpp-4.0 4.0.2-9 2006-03-10 09:23:11 status unpacked gcc-4.0 4.0.2-9 200
Bug#355439: gcc-4.0-base: Debian changelog and copyright lost after upgrade
Matthias Klose wrote: please recheck (after downgrading to 4.0.2-9), I had two copies of the packages at different places. Sorry. I now looked into the new 4.0.3-1 versions, they hopefully fix this for good. Some people may wonder why the files in /usr/share/doc/gcc-4.0-base have two names, but better have two links for them than none. Cheers, Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#385732: fsf-funding.7: it's back!
found #385732 1.47 thanks In version 1.47, fsf-funding.7 is in the source tarball again. Reopening the bug, Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384809: How about closing this bug?
Shouldn't this bug be closed, now that gcc-4.1-doc is available in non-free and gcc-doc has moved to contrib? Kind regards, Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405791: gcc-defaults: Please provide gcc-locales metapackage
Package: gcc-defaults Version: 1.50 Severity: wishlist It would be nice if there were a gcc-locales metapackage depending on the gcc-x.y-locales package for the default Debian gcc version. It would not only pull it automacically in, but people who only want to have one gcc version on their system could get rid of old ones more easily. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.19.1 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#421162: gcc-4.1: libssp0 is gone, several packages depend on it
Package: gcc-4.1 Version: 4.1.2-4 Severity: grave The latest gcc-4.1 upload is lacking libssp0 on which several packages on my system depend, for instance some libavahi-* packages. Looking at http://packages.qa.debian.org/g/gcc-4.1/news/20070425T222047Z.html, it is still mentioned in the Binary field, but not in the list of files. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.20.7 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gcc-4.1 depends on: ii binutils 2.17-3 The GNU assembler, linker and bina ii cpp-4.1 4.1.1-21 The GNU C preprocessor ii gcc-4.1-base 4.1.1-21 The GNU Compiler Collection (base ii libc6 2.5-4 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-21 GCC support library ii libssp0 4.1.1-21 GCC stack smashing protection libr Versions of packages gcc-4.1 recommends: ii libc6-dev 2.5-4 GNU C Library: Development Librari ii libmudflap0-dev 4.1.1-21 GCC mudflap support libraries (dev -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#421162: gcc-4.1: libssp0 is gone, several packages depend on it
Matthias Klose writes: > it's gone on all architectures which have glibc-2.5. please file bug > reports on the packages depending on it Done for all six of them (counting source packages). > and/or check if these can be fixed by binary rebuilds. I'll leave this to the respective maintainers. Regards, Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#827173: gcc-6: missing "Debian" in "gcc-6 --version" output
On 2016-06-13 14:43 +0200, Matthias Klose wrote: > On 13.06.2016 12:46, Vincent Lefevre wrote: >> Package: gcc-6 >> Version: 6.1.1-6 >> Severity: minor >> >> $ gcc-6 --version >> gcc-6 ( 6.1.1-6) 6.1.1 20160609 >> Copyright (C) 2016 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >> >> The first line of the output should have been: >> >> gcc-6 (Debian 6.1.1-6) 6.1.1 20160609 >> >> There was no such problem with gcc-6 6.1.1-5. > > from the logs: > >> Configured with: -v >> --with-pkgversion=' 6.1.1-6' > > Don't know what happened. A new build has the distro name again. It's because of #826962, but I cannot reproduce that bug. Cheers, Sven
Bug#827173: gcc-6: missing "Debian" in "gcc-6 --version" output
On 2016-06-13 15:55 +0200, Sven Joachim wrote: > On 2016-06-13 14:43 +0200, Matthias Klose wrote: > >> On 13.06.2016 12:46, Vincent Lefevre wrote: >>> Package: gcc-6 >>> Version: 6.1.1-6 >>> Severity: minor >>> >>> $ gcc-6 --version >>> gcc-6 ( 6.1.1-6) 6.1.1 20160609 >>> Copyright (C) 2016 Free Software Foundation, Inc. >>> This is free software; see the source for copying conditions. There is NO >>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >>> >>> The first line of the output should have been: >>> >>> gcc-6 (Debian 6.1.1-6) 6.1.1 20160609 >>> >>> There was no such problem with gcc-6 6.1.1-5. >> >> from the logs: >> >>> Configured with: -v >>> --with-pkgversion=' 6.1.1-6' >> >> Don't know what happened. A new build has the distro name again. > > It's because of #826962, but I cannot reproduce that bug. Ah, it's because of a bug in python 3.5 3.5.1-14, and you already fixed it in -15. Will reassign #826962 accordingly. Cheers, Sven
Bug#754879: FTBFS on i386
On 2014-07-16 03:55 +0200, Matthias Klose wrote: > Am 15.07.2014 16:27, schrieb Michael Biebl: >> Source: gcc-4.9 >> Version: 4.9.0-11 >> Severity: serious >> >> The package FTBFS on i386 and hurd-i386 but successfully built in the >> past. >> >> Complete build log at [1] > > how helpful is this report? > > - i386: I'd appreciate an analysis what did go wrong The error happens here: , | cp -p $(find /«PKGBUILDDIR»/build -mindepth 3 -name '*.sum' ! -name libgo.sum) \ | debian/g++-4.9/usr/share/doc/gcc-4.9-base/test-summaries/ | cp: will not overwrite just-created 'debian/g++-4.9/usr/share/doc/gcc-4.9-base/test-summaries/gfortran.sum' with '/«PKGBUILDDIR»/build/gcc/testsuite/gfortran2/gfortran.sum' | cp: will not overwrite just-created 'debian/g++-4.9/usr/share/doc/gcc-4.9-base/test-summaries/gfortran.sum' with '/«PKGBUILDDIR»/build/gcc/testsuite/gfortran5/gfortran.sum' | cp: will not overwrite just-created 'debian/g++-4.9/usr/share/doc/gcc-4.9-base/test-summaries/gfortran.sum' with '/«PKGBUILDDIR»/build/gcc/testsuite/gfortran/gfortran.sum' | cp: will not overwrite just-created 'debian/g++-4.9/usr/share/doc/gcc-4.9-base/test-summaries/gfortran.sum' with '/«PKGBUILDDIR»/build/gcc/testsuite/gfortran6/gfortran.sum' | cp: will not overwrite just-created 'debian/g++-4.9/usr/share/doc/gcc-4.9-base/test-summaries/gfortran.sum' with '/«PKGBUILDDIR»/build/gcc/testsuite/gfortran4/gfortran.sum' | cp: will not overwrite just-created 'debian/g++-4.9/usr/share/doc/gcc-4.9-base/test-summaries/gfortran.sum' with '/«PKGBUILDDIR»/build/gcc/testsuite/gfortran1/gfortran.sum' ` There are multiple files named gfortran.sum, and cp refuses to copy them all to the same destination file. In the coreutils source I found the following explanation (in src/copy.c): , | /* Don't let the user destroy their data, even if they try hard: |This mv command must fail (likewise for cp): | rm -rf a b c; mkdir a b c; touch a/f b/f; mv a/f b/f c |Otherwise, the contents of b/f would be lost. |In the case of 'cp', b/f would be lost if the user simulated |a move using cp and rm. |Note that it works fine if you use --backup=numbered. */ ` I wonder why this did not happen on other architectures as well, since they also run the gfortran testsuite multiple times. Cheers, Sven -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87sim1n765@turtle.gmx.de
Bug#757835: nfs-kernel-server: after update 1.2.8-6->1.2.8-8 rpc.mountd starts crashing
On 2014-08-12 20:23 +0200, Ben Hutchings wrote:
> On Tue, 2014-08-12 at 09:05 -0700, Steve Langasek wrote:
> [...]
>> Matthias, could you please have a look at the below test case? We have a
>> regression in the latest nfs-kernel-server build, which appears to be caused
>> by a gcc-4.9 bug.
>>
>> Should I work around this in nfs-utils, or is a quick fix possible in
>> gcc-4.9?
>>
>> > char buf[100];
>> >
>> > void
>> > add_name(char *old)
>> > {
>> >char *cp = old;
>> >
>> >while (cp && *cp) {
>> >cp++;
>> >}
>> >__builtin_strncpy(buf, old, cp-old);
> [...]
>
> So far as I know (haven't checked the latest standard), pointer
> subtraction has undefined behaviour unless both operands point into (or
> one beyond) the same array. As this is not true of null pointers, the
> compiler may infer that old can't be null, so cp can't be null, so there
> is no need to check whether it is.
This is true in C, unfortunately. However…
> I.e. this is a bug in nfs-utils, not the compiler.
…Petr's example program crashes even when compiled with g++-4.9, and in
C++ subtracting two null pointers is valid, yielding zero.
Cheers,
Sven
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/874mxhmtbw@turtle.gmx.de
powerpc64 gcc compiler ...
Hello, I am currently trying to build a ppc64 aware gcc 3.4 package, as mentioned in Matthias post : http://lists.debian.org/debian-gcc/2004/debian-gcc-200403/msg00021.html First, i found that this gcc-3.4 package in experimental wasn't yet built on powerpc, which i did. It did output lot of FAILs in the tests later on, but i am not sure this is worrying or not. It builds simple binaries without problems. But it didn't build the biarch toolchain, so it was of no use for me. After a bit of investigation, i found out that : --target=powerpc64-linux --with-cpu=default32 Where needed for gcc-3.4 to build the biarch toolchain, and default to 32bit binaries, unless the -m64 option is given to gcc-3.4. I looked a bit at the source code, and found out that other 64bit arches did : # sparc64 build ifeq ($(DEB_TARGET_ARCH),sparc) biarch := yes with_lib64gcc := yes with_lib64cxx := yes endif So i guess a good solution would be to do something similar for powerpc, not sure if this would include the --with-cpu=default32 though. I don't really know what the plans are for ppc64 support, but i hear that biarch userland is a post sarge issue. Also, i understood that we will not switch over to gcc 3.4 for sarge, which is the reason why it is in experimental currently. Or maybe it would be possible to have gcc 3.4 in unstable and later sarge, without it necessarily being the default ? What i am trying to do, and what would be nice, would be to have at least ppc64 kernels for the sarge release, since some boxes may need this and will have trouble with 32bit kernels. Don't know if this is realistic, but it seems to me that only gcc support is needed in order to achieve that. I hear that a 64bit procps and module-init-tools will be needed too, and probably a libncurses, which may be a problem, but let's worry about this later. Anyway, my question here is if you would consider it reasonable to enable the powerpc biarch toolchain, and have it default to 32bit for gcc 3.4 ? This should cause no problem for ordinary powerpc, but would allow to build ppc64 stuff with the same toolchain. Am i correct with this assumption ? I will try tomorrow to build this, but would it make sense to enable this in the experimental powerpc packages ? And what about the not gcc or cxx compilers ? Friendly, Sven Luther
Re: powerpc64 gcc compiler ...
On Wed, Mar 31, 2004 at 08:12:36AM +0200, Matthias Klose wrote: > Sven Luther writes: > > First, i found that this gcc-3.4 package in experimental wasn't yet > > built on powerpc, which i did. It did output lot of FAILs in the tests > > later on, but i am not sure this is worrying or not. > > Please have a look at http://gcc.gnu.org/ml/gcc-testresults/ and compare. Ok. Mmm, i seem to have more stuff, including something which seems really broken. You can have a look at the full build log at : http://people.debian.org:~luther/gcc-3.4-powerpc.log.gz > > It builds simple binaries without problems. But it didn't build the > > biarch toolchain, so it was of no use for me. > > > > After a bit of investigation, i found out that : > > > > --target=powerpc64-linux --with-cpu=default32 > > both s390 and sparc build the 32bit compiler and patch gcc/config.gcc > to include the 64bit specific Makefile chunks. At least this installs > things in a -linux subdirectory, not -linux64. I don't > know if there other changes building this way. Look at the -biarch > patches in debian/patches. Huh, notice that this is gcc-3.4, which i am told support powerpc biarch without need for patching. Indeed, if i look at the s390-biarch patch, i only get : While if i consult src/gcc/config.c, i find that i already have this : powerpc64-*-linux*) tmake_file="rs6000/t-fprules t-slibgcc-elf-ver t-linux rs6000/t-ppccomm rs6000/t-linux64" So, it should be ok for powerpc64. That said, for non-64 powerpc i have : powerpc-*-linux*) tmake_file="rs6000/t-fprules rs6000/t-ppcos t-slibgcc-elf-ver t-linux rs6000/t-ppccomm" So the t-linux64 is clearly missing. Now, i don't know which of the two cases will be chosen with the above options. The ppc64 guys tell me that the above is enough in gcc-3.4 to enable ppc32 and ppc64 biarch, and to make ppc32 the default, so i somehow guess that the first one is chosen, right ? > > I don't really know what the plans are for ppc64 support, but i hear > > that biarch userland is a post sarge issue. Also, i understood that we > > will not switch over to gcc 3.4 for sarge, which is the reason why it is > > in experimental currently. Or maybe it would be possible to have gcc 3.4 > > in unstable and later sarge, without it necessarily being the default ? > > not one more compiler in sarge. If we want to have 3.4 in sarge, we > should drop 3.2 first. If 3.4 is released, built for all Debian > architectures and no regressions found for packages which replace > their 3.3 counterparts, then lets propose this to debian-release ... > Upstream development asked/proposed Linux distributions to include a > libstdc++6 in current releases. Ok, this doesn mean that you condemn any chance of there being a set of ppc64 kernels in debian/sarge, which means that some box will be unsupported. Or do you mean i should use backports, or the gcc 3.3 hammer branch, and have 3.3 support this, which means a possibly more disruptive situation ? And do some arches not need 3.4 ? What would be the price of dropping 3.2 first ? BTW, even if 3.4 goes to unstable and is hold out of sarge by a hold-RC-bug or something, would this addition of gcc-3.4 not be transparently added without further impact on the gcc->gcc-3.3 use. > > What i am trying to do, and what would be nice, would be to have at > > least ppc64 kernels for the sarge release, since some boxes may need > > this and will have trouble with 32bit kernels. Don't know if this is > > realistic, but it seems to me that only gcc support is needed in order > > to achieve that. I hear that a 64bit procps and module-init-tools will > > be needed too, and probably a libncurses, which may be a problem, but > > let's worry about this later. > > well, you need a lib64c6-dev as well. Unsure how much prepared the > glibc sources are and if the glibc maintainers are willing to include > such packages for sarge. I doubt they will. And i think a glibc fixup would be something which would follow a 64bit gcc and kernel. In my understanding, the support chain goes as follows : binutils (ok) -> gcc -> kernel -> glibc. > > Anyway, my question here is if you would consider it reasonable to > > enable the powerpc biarch toolchain, and have it default to 32bit for > > gcc 3.4 ? This should cause no problem for ordinary powerpc, but would > > allow to build ppc64 stuff with the same toolchain. Am i correct with > > this assumption ? I will try tomorrow to build this, but would it make > > sense to enable this in the experimental powerpc packages ? And what > > about the not gcc or cxx compilers ? > > Including your patches is ok, enable it by default not, as lib64
Re: powerpc64 gcc compiler ...
On Wed, Mar 31, 2004 at 12:44:16PM +0200, Sven Luther wrote: > > > It builds simple binaries without problems. But it didn't build the > > > biarch toolchain, so it was of no use for me. > > > > > > After a bit of investigation, i found out that : > > > > > > --target=powerpc64-linux --with-cpu=default32 > > > > both s390 and sparc build the 32bit compiler and patch gcc/config.gcc > > to include the 64bit specific Makefile chunks. At least this installs > > things in a -linux subdirectory, not -linux64. I don't > > know if there other changes building this way. Look at the -biarch > > patches in debian/patches. > > Huh, notice that this is gcc-3.4, which i am told support powerpc biarch > without need for patching. Indeed, if i look at the s390-biarch patch, i > only get : > > > While if i consult src/gcc/config.c, i find that i already have this : > > powerpc64-*-linux*) >tmake_file="rs6000/t-fprules t-slibgcc-elf-ver t-linux > rs6000/t-ppccomm rs6000/t-linux64" > > So, it should be ok for powerpc64. That said, for non-64 powerpc i have : > > powerpc-*-linux*) > tmake_file="rs6000/t-fprules rs6000/t-ppcos t-slibgcc-elf-ver t-linux > rs6000/t-ppccomm" > > So the t-linux64 is clearly missing. Now, i don't know which of the two > cases will be chosen with the above options. The ppc64 guys tell me that > the above is enough in gcc-3.4 to enable ppc32 and ppc64 biarch, and to > make ppc32 the default, so i somehow guess that the first one is chosen, > right ? > > > Including your patches is ok, enable it by default not, as lib64c6-dev > > is missing as a build dependency. To disable the runtime lib64raries > > you do not want add a patch like sparc-config-ml or s390-config-ml. > > I have difficulties parsing this. Mmm, the build done when enabling a few stuff to make it build a ppc64 target failed (after 7 hours :() because it failed to build the lib64gcc1 package : dh_installdirs -plib64gcc1 \ usr/share/doc/lib64gcc1 \ lib64 install -d debian/tmp/lib64 mv debian/tmp/usr/lib64/libgcc_s.so.1 debian/tmp/lib64/. mv: ne peut évaluer `debian/tmp/usr/lib64/libgcc_s.so.1': Aucun fichier ou répertoire de ce type Well, sorry for the french message, i will build with LANG=C in the future. The translation is evident though: no such file or directory :) Anyway, in light of this, i guess what is happening, is that since i am building a biarch compiler, there should be no lib64gcc1 package, but only the libgcc1 one (which should maybe provide lib64gcc1 ?). Sorry for being a bit naive perhaps, but this is the first time i ever looked in the gcc build stuff. Friendly, Sven Luther
Re: powerpc64 gcc compiler ...
On Wed, Mar 31, 2004 at 11:50:11AM -0500, Daniel Jacobowitz wrote: > On Wed, Mar 31, 2004 at 08:12:36AM +0200, Matthias Klose wrote: > > well, you need a lib64c6-dev as well. Unsure how much prepared the > > glibc sources are and if the glibc maintainers are willing to include > > such packages for sarge. > > Absolutely not... the base system is frozen, remember? > > I don't know how easily you can build 64-bit gcc with the current > packaging, without a 64-bit glibc. I imagine we try to build both > shared libgcc's which will fail. Let's wait on this until after sarge. Absolutely not ... :) This is based on the gcc 3.4 package currently in experimental, so should cause no problem whatsover with regard to the sarge release cycle. And the wait for after sarge, altough reasonable now that sarge seems to be near release, is only a receipt for inactivity. Furthermore i have time now to work on this, but who knows if i will have time to work on this later on, so waiting is no solution. So, let's implement this in experimental now, which is the right place for this kind of stuff, and if it is reasy before the sarge freeze, fine, if not, well, we would at least have many month of headstart on this. As said, my plan was to have at least a gcc 3.4 biarch compiler, and be able to build 64bit kernels, and let the glibc/userland issues for post-sarge. That said, i have close to zero deep understanding on how glibc and gcc interact on this issue, and what is going on about libgcc. I am told by the #ppc64 folk that i should compile gcc with the ppc64 target, but have it default to 32bit code by default. My early tries for this try to generate a lib64gcc1, and fails, as you said. Do you have any wisdom to share with me about why this is the case ? Friendly, Sven Luther
Re: powerpc64 gcc compiler ...
On Sat, Apr 03, 2004 at 09:02:32AM +0200, Matthias Klose wrote: > Sven Luther writes: > > That said, i have close to zero deep understanding on how glibc and gcc > > interact on this issue, and what is going on about libgcc. I am told by > > the #ppc64 folk that i should compile gcc with the ppc64 target, but > > have it default to 32bit code by default. My early tries for this try to > > generate a lib64gcc1, and fails, as you said. Do you have any wisdom to > > share with me about why this is the case ? > > comment out the --disable-multilib in debian/rules2, add a patch not > to build the -nof libraries and disable some biarch libraries (see the > sparc-config-ml patch for an example). Mmm. the with-nof is set to no on powerpc per default, so this should be ok, i disabled the --disable-multilib which was set in the no-nof case only, and i more or less copied the sparc biarch stuff in debian/rules.conf. Will try a build. BTW, is it possible to easily disable the tests in order to spare a few hours of build when experimenting like that. Having to wait 7 hours for the build to complete is, well, not very productive. Friendly, Sven Luther
Re: powerpc64 gcc compiler ...
On Sat, Apr 03, 2004 at 10:44:10AM +0200, Matthias Klose wrote: > Sven Luther writes: > > BTW, is it possible to easily disable the tests in order to spare a few > > hours of build when experimenting like that. Having to wait 7 hours for > > the build to complete is, well, not very productive. > > WITHOUT_CHECK=yes dpkg-buildpackage ... Oh, ok. I edited with_test := no in debian/rules.conf or something such, i suppose this will also do. Friendly, Sven Luther
Re: powerpc64 gcc compiler ...
On Sat, Apr 03, 2004 at 09:02:32AM +0200, Matthias Klose wrote: > Sven Luther writes: > > That said, i have close to zero deep understanding on how glibc and gcc > > interact on this issue, and what is going on about libgcc. I am told by > > the #ppc64 folk that i should compile gcc with the ppc64 target, but > > have it default to 32bit code by default. My early tries for this try to > > generate a lib64gcc1, and fails, as you said. Do you have any wisdom to > > share with me about why this is the case ? > > comment out the --disable-multilib in debian/rules2, add a patch not > to build the -nof libraries and disable some biarch libraries (see the > sparc-config-ml patch for an example). dpkg-deb : construction du paquet « libgcc1 » dans « ../libgcc1_3.4-0pre2_powerpc.deb ». trap '' 1 2 3 15; touch stamps/08-binary-stamp-libgcc; mv stamps/07-install-stamp-tmp stamps/07-install-stamp dh_testdir dh_testroot mv stamps/07-install-stamp stamps/07-install-stamp-tmp rm -rf debian/lib64gcc1 dh_installdirs -plib64gcc1 \ usr/share/doc/lib64gcc1 \ lib64 install -d debian/tmp/lib64 mv debian/tmp/usr/lib64/libgcc_s.so.1 debian/tmp/lib64/. mv: ne peut évaluer `debian/tmp/usr/lib64/libgcc_s.so.1': Aucun fichier ou répertoire de ce type make[1]: *** [stamps/08-binary-stamp-lib64gcc] Erreur 1 Didn't work out, apparently. I would like to ask a question about this. lib64gcc1 should contain the needed stuff for the ppc64 target and is thus needed in this case, or is it that since we are building a biarch compiler, it is not needed since the appropriate code is moved to the libgcc1 library ? Friendly, Sven Luther
Re: powerpc64 gcc compiler ...
On Sat, Apr 03, 2004 at 04:09:41PM +0200, Sven Luther wrote: > On Sat, Apr 03, 2004 at 09:02:32AM +0200, Matthias Klose wrote: > > Sven Luther writes: > > > That said, i have close to zero deep understanding on how glibc and gcc > > > interact on this issue, and what is going on about libgcc. I am told by > > > the #ppc64 folk that i should compile gcc with the ppc64 target, but > > > have it default to 32bit code by default. My early tries for this try to > > > generate a lib64gcc1, and fails, as you said. Do you have any wisdom to > > > share with me about why this is the case ? > > > > comment out the --disable-multilib in debian/rules2, add a patch not > > to build the -nof libraries and disable some biarch libraries (see the > > sparc-config-ml patch for an example). > > I would like to ask a question about this. lib64gcc1 should contain the > needed stuff for the ppc64 target and is thus needed in this case, or is > it that since we are building a biarch compiler, it is not needed since > the appropriate code is moved to the libgcc1 library ? Thanks Matthias for hinting me in the right direction. It seems that setting biarch on powerpc is not enough, and that --target=powerpc64-linux is needed to continue the build. Now, i have reached a second step of the build, where i need some direction from the glibc folk, or other person interested on this. I have not yet looked at the glibc package though. Basically, to build the full gcc package with ppc64 support, the ppc64 glibc and kernel headers are needed too, in addition to the ppc32 ones we already have. Now since a 64bit gcc is needed for building the ppc64 glibc, ... I was told that it is possible to only build the glibc headers with make install-headers, without having the appropriate gcc yet, which may solve this. What is the commone practice to solve this circular dependency problem with regard to debian packages ? BTW, my intentions are to build this whole stuff in experimental, so there should be no 'let's wait for after the sarge release' or such involved here. Friendly, Sven Luther
