Processing of autoconf2.59_2.59-1_amd64.changes
autoconf2.59_2.59-1_amd64.changes uploaded successfully to localhost along with the files: autoconf2.59_2.59-1.dsc autoconf2.59_2.59.orig.tar.gz autoconf2.59_2.59-1.diff.gz autoconf2.59_2.59-1_all.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
autoconf2.59_2.59-1_amd64.changes is NEW
(new) autoconf2.59_2.59-1.diff.gz extra devel (new) autoconf2.59_2.59-1.dsc extra devel (new) autoconf2.59_2.59-1_all.deb extra devel automatic configure script builder (obsolete version) This obsolete version is required to build GCC (>= 4.3.3), newlib, and probably some others toolchain related packages. (new) autoconf2.59_2.59.orig.tar.gz extra devel Changes: autoconf2.59 (2.59-1) unstable; urgency=low . * Initial release, this autoconf version is needed to build GCC (>= 4.3.3), newlib, and probably some others toolchain related packages. * debian/patches/01_update_autotools.diff: Update to newer autotools. * debian/patches/02_autoreconf-aclocal.diff: Set AUTOM4TE env variable to ensure aclocal uses the right autom4te version. Override entries for your package: Announcing to debian-devel-chan...@lists.debian.org Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. You may have gotten the distribution wrong. You'll get warnings above if files already exist in other distributions. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain
Hi, On Thu, Mar 12, 2009 at 07:54:49PM +0100, Hector Oron wrote: > > install anything but libraries and headers into /usr/ -- so I > > don't think there is a pressing need to replicate a filesystem hierarchy > > standard below a triplet directory. > That is what GNU people expect when building cross tools, they use a > switch called sysroot for it and it is the recommended way to build such > cross tools. As far as I've understood, --with-sysroot gives the path to the target OS installation so the build can run "fixincludes" and add it to the search paths; since it should work with a largely unmodified snapshot of the target OS, they are pretty tolerant with the directory layout there. I don't believe that is meant as an endorsement of a particular layout, and it should work fine with --with-sysroot=/usr/ even with the current layout. Simon -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain
Hello Simon, > As far as I've understood, --with-sysroot gives the path to the target OS > installation so the build can run "fixincludes" and add it to the search > paths; since it should work with a largely unmodified snapshot of the > target OS, they are pretty tolerant with the directory layout there. I > don't believe that is meant as an endorsement of a particular layout, and > it should work fine with --with-sysroot=/usr/ even with the > current layout. Right, but it expects include/ to be under usr/include/ as FHS wants. In practice, I did a build for gcc-4.3 and here you have some of the results: Binutils 2.18 configure: ~ ../configure --host=x86_64-linux-gnu \ --build=x86_64-linux-gnu --target=s390-linux-gnu --prefix=/usr \ --enable-targets=s390x-linux-gnu --with-sysroot=/usr/s390-linux-gnu/ GCC-4.3 configure: ~~ ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl='file:///usr/share/doc/gcc-4.3/README.Bugs' --enable-languages=c,c++,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/s390-linux-gnu/include/c++/4.3.2 --program-suffix=-4.3 --with-sysroot=/usr/s390-linux-gnu/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-long-double-128 --enable-checking=release --program-prefix=s390-linux-gnu- --includedir=/usr/s390-linux-gnu/include --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=s390-linux-gnu Output error: ~ /home/zumbi/buildcross/trunk/s390/gcc-4.3-4.3.2/build/./gcc/xgcc -B/home/zumbi/buildcross/trunk/s390/gcc-4.3-4.3.2/build/./gcc/ -B/usr/s390-linux-gnu/bin/ -B/usr/s390-linux-gnu/lib/ -isystem /usr/s390-linux-gnu/include -isystem /usr/s390-linux-gnu/sys-include -O2 -O2 -g -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -mlong-double-128 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o 64/libgcc_s.so.1.tmp -O2 -g -g -O2 -m64 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o unwind-dw2_s.o unwind-dw2-fde-glibc_s.o unwind-sjlj_s.o gthr-gnat_s.o unwind-c_s.o emutls_s.o -lc && rm -f 64/libgcc_s.so && if [ -f 64/libgcc_s.so.1 ]; then mv -f 64/libgcc_s.so.1 64/libgcc_s.so.1.backup; else true; fi && mv 64/libgcc_s.so.1.tmp 64/libgcc_s.so.1 && ln -s libgcc_s.so.1 64/libgcc_s.so /usr/s390-linux-gnu/bin/ld: skipping incompatible /usr/s390-linux-gnu/lib/libc.so when searching for -lc /usr/s390-linux-gnu/bin/ld: skipping incompatible /usr/s390-linux-gnu/lib/libc.a when searching for -lc /usr/s390-linux-gnu/bin/ld: skipping incompatible /usr/s390-linux-gnu/bin/../../lib/libc.so when searching for -lc /usr/s390-linux-gnu/bin/ld: skipping incompatible /usr/s390-linux-gnu/bin/../../lib/libc.a when searching for -lc /usr/s390-linux-gnu/bin/ld: s390:31-bit architecture of input file `/usr/s390-linux-gnu/lib/crti.o' is incompatible with s390:64-bit output /usr/s390-linux-gnu/bin/ld: s390:31-bit architecture of input file `/usr/s390-linux-gnu/lib/crtn.o' is incompatible with s390:64-bit output collect2: ld returned 1 exit status -- Héctor Orón -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain
Hello, >>> , and there is generally no need to >>> install anything but libraries and headers into /usr/ -- so I >>> don't think there is a pressing need to replicate a filesystem hierarchy >>> standard below a triplet directory. > >> True, however, that is not a sufficient reason to not >> move /usr/ to /usr/lib/ and /usr/include/ >> if it means getting such support into the core Debian packaging tools. > > Indeed, however this makes building stuff without the packaging tools a lot > harder -- for example I need to patch gcc to recognize these paths if I > build gcc by hand. It might be a lot easier to have the packaging tools > handle the "current" layout than to patch all the software that assumes > that software is generally installed into "include" and "lib" dirs under a > common prefix (such as most GNU software that uses the autoconf macros to > find installed software). That's totally right and that is my point, I really think multiarch is not well designed to fit into cross compiling. They (dpkg-core) might want us to do extra work which will break our stuff. And as from the point of view of multiarch we probably have a nice, simple and working solution right now, without even notice it. The only reason I found against our approach is: " Why not prefix/arch-os/lib/ (and include/)? It would pollute the prefix directory. Can you imagine adding one entry for each target to the root and /usr directories? Better that they go under the prefix/lib/ (and include/) directories which already contain many files. " Which in practice it is not so bad to do all the extra work that multiarch needs to get done. Please correct me if I am wrong -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain
Hi, > >, since > > they have entirely different objectives > Not entirely different - the objective for the packaging tools is > actually the same, to have packages install cleanly without changes on > systems with a different architecture triplet. I'm not sure this can be achieved at all, as we still need a root filesystem that isn't prefixed with the architecture triplet. The other issue is that generally, the 32/64 bit distinction does not necessarily mean that we use a different triplet. i386/amd64 does, at least in Debian, but that is optional as well and could be changed in the gcc package, which would give us a situation where only clearly incompatible arches need to be installed into a triplet directory. > >, and there is generally no need to > > install anything but libraries and headers into /usr/ -- so I > > don't think there is a pressing need to replicate a filesystem hierarchy > > standard below a triplet directory. > True, however, that is not a sufficient reason to not > move /usr/ to /usr/lib/ and /usr/include/ > if it means getting such support into the core Debian packaging tools. Indeed, however this makes building stuff without the packaging tools a lot harder -- for example I need to patch gcc to recognize these paths if I build gcc by hand. It might be a lot easier to have the packaging tools handle the "current" layout than to patch all the software that assumes that software is generally installed into "include" and "lib" dirs under a common prefix (such as most GNU software that uses the autoconf macros to find installed software). Simon -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519562: A -help request is not an error
Package: gij-4.3 Version: 4.3.3-3 Severity: minor File: /usr/bin/gkeytool-4.3 Hi, keytool should not return an exit code indicating an error while asked for help. % keytool -help >/dev/null; echo $? 1 BTW: Why keytool prints an empty line to stderr, as you can see above? Bye, Jörg. -- System Information: Debian Release: unstable/experimental APT prefers unstable APT policy: (900, 'unstable'), (700, 'experimental') Architecture: powerpc (ppc) Kernel: Linux 2.6.29-rc7 Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gij-4.3 depends on: ii gcj-4.3-base 4.3.3-3 The GNU Compiler Collection (gcj b ii libc6 2.9-4 GNU C Library: Shared libraries ii libgcc11:4.3.3-5 GCC support library ii libgcj9-0 4.3.3-3 Java runtime library for use with ii zlib1g 1:1.2.3.3.dfsg-13 compression library - runtime gij-4.3 recommends no packages. Versions of packages gij-4.3 suggests: ii fastjar 2:0.97-3 Jar creation utility ii gcj-4.3 4.3.3-3The GNU compiler for Java(TM) ii java-gcj-compat 1.0.80-1 Java runtime environment using GIJ ii libgcj9-0-awt 4.3.3-3AWT peer runtime libraries for use -- no debconf information signature.asc Description: Digital signature http://en.wikipedia.org/wiki/OpenPGP
[Bug target/38553] [4.3 Regression] Segfault in ggc_set_mark with -maltivec
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.4.0 Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38553 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
