Re: Propose requiring Python 3.4 or later for building glibc.
On Mon, Oct 22, 2018 at 7:15 AM Helmut Grohne wrote: > Daniel Schepler is working on a native bootstrap approach. As far as I > understand, he natively bootstraps Debian from non-Debian (same > processor architecure and kernel). I expect that his work will be > impacted by the proposed change. I've added him to Cc to let him speak > up. That shouldn't be an issue - already, Python 3 tends to come significantly earlier than the rebuild of glibc in the process. (On the other hand, I don't see anybody from Linux From Scratch on the distribution list - and I'd expect they would have to add Python 3 to the host system dependencies, and also add it to the initial bootstrap system.) -- Daniel Schepler
Bug#797093: glibc: New upstream version 2.22 available
Source: glibc Severity: wishlist glibc 2.22 was released Aug 14: https://www.sourceware.org/ml/libc-alpha/2015-08/msg00609.html It would be nice to have this version packaged, at least in experimental. -- Daniel
Bug#770259: eglibc: FTBFS: These critical programs are missing or too old: make
Source: eglibc Version: 2.17-97 Severity: serious >From my pbuilder build log: ... checking for ld... ld checking version of ld... 2.24.90, ok checking for x86_64-linux-gnu-gcc... (cached) x86_64-linux-gnu-gcc-4.7 checking version of x86_64-linux-gnu-gcc-4.7... 4.7.4, ok checking for gnumake... no checking for gmake... no checking for make... make checking version of make... 4.0, bad checking for gnumsgfmt... no checking for gmsgfmt... no checking for msgfmt... msgfmt checking version of msgfmt... 0.19.3, ok checking for makeinfo... : checking version of :... v. ?.??, bad checking for sed... sed checking version of sed... 4.2.2, ok checking for gawk... gawk checking version of gawk... 4.1.1, ok checking for x86_64-linux-gnu-nm... x86_64-linux-gnu-nm checking for autoconf... false checking whether false works... no configure: error: *** These critical programs are missing or too old: make *** Check the INSTALL file for required versions. debian/rules.d/build.mk:31: recipe for target '/tmp/buildd/eglibc-2.17/stamp-dir/configure_libc' failed make: *** [/tmp/buildd/eglibc-2.17/stamp-dir/configure_libc] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 Given that src:eglibc is pretty much obsoleted by src:glibc now, I'd guess the easiest way to fix this would be to just request the removal of src:eglibc from sid. -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1664080.vU7KXrDnJZ@frobozz
My notes on bootstrapping multilib on amd64
Here are my notes on how to bootstrap multilib gcc and eglibc packages,
starting from a base without any multilib available. I thought I'd post them
here in case anybody could benefit from them, or maybe had comments on how to
improve the process.
ln -s x86_64-linux-gnu /usr/include/x86_64-linux-gnux32
ln -s x86_64-linux-gnu /usr/include/i386-linux-gnu
touch /usr/include/x86_64-linux-gnu/gnu/stubs-{32,x32}.h
Start with gcc-4.7:
Edit debian/rules2
Add --disable-libitm, --disable-libstdc++-v3 to disabled libs for
DEB_STAGE build.
Edit debian/control.m4
Remove ifenabled(`libx32gcc', ... condition from libx32gcc1 and
libx32gcc-dev entries.
DEB_STAGE=stage1 DEB_BUILD_OPTIONS="parallel=? nocheck" dpkg-buildpackage -d -b
-uc
dpkg -i --force-depends ../*.deb
[as gcc-4.7-base isn't built but is still depended on; and also
gcc-4.7-multilib still depends on libc6-dev-* which isn't built yet]
Next, eglibc:
Make sure make 3.81-8.2 is installed, and not 3.82-1 from experimental.
Edit /usr/share/perl5/Dpkg/Shlibs.pm and add /libx32 /usr/libx32 to
definition of DEFAULT_LIBRARY_PATH.
libc_cv_ssp=no DEB_BUILD_OPTIONS="parallel=? nocheck" dpkg-buildpackage -d -b
-uc
rm /usr/include/x86_64-linux-gnux32 /usr/include/i386-linux-gnu \
/usr/include/x86_64-linux-gnu/gnu/stubs-{32,x32}.h
dpkg -i ../{libc6,libc6-dev,libc6-i386,libc6-x32,
libc6-dev-i386,libc6-dev-x32,locales,libc-bin,libc-dev-bin,
multiarch-support,libc6-dbg}_*.deb
apt-get -f install [which will remove bootstrapped gcc-4.7 packages, but
they're not needed anymore]
Now build gcc-4.8:
[For overall bootstrapping of Debian, can't build the Java part yet as:
gcc-4.8 Build-Depends on libcairo2-dev
cairo Build-Depends on libgl1-mesa-dev
mesa Build-Depends on llvm-3.2-dev
llvm-toolchain-3.2 Build-Depends on gcc-4.7
So, edit debian/rules.defs and add somewhere
"with_java := disabled for bootstrap build"
I put it just above the line "ifeq ($(with_java),yes)".
]
DEB_BUILD_OPTIONS="parallel=? [nocheck]" dpkg-buildpackage -d -B -uc
dpkg -i ../lib32gcc1_*.deb ../libx32gcc1_*.deb ; resolve dependencies ; \
apt-get check && dpkg --configure -a
Next, full version of gcc-4.7:
# reextract gcc-4.7 source package -- for some reason, the previous build
# put libantlr-java into the Build-Depends
DEB_BUILD_OPTIONS="parallel=? [nocheck]" dpkg-buildpackage -B -uc
dpkg -i ../g++-4.7_*.deb ../g++-4.7-multilib_*.deb ; resolve dependencies ; \
apt-get check && dpkg --configure -a
Finally, full build of eglibc (with libssp usage compiled into the
appropriate utilities):
DEB_BUILD_OPTIONS="parallel=? [nocheck]" dpkg-buildpackage -b -uc
--
Daniel Schepler
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/3157052.KLsfge87uu@frobozz
Bug#720834: eglibc: FTBFS with make 3.82 from experimental: /usr/bin/install: cannot remove '/usr/include/locale.h': Permission denied
nvconfig
/tmp/buildd/eglibc-2.17/debian/tmp-libc/usr/sbin/iconvconfig.new
mv -f /tmp/buildd/eglibc-2.17/debian/tmp-libc/usr/sbin/iconvconfig.new
/tmp/buildd/eglibc-2.17/debian/tmp-libc/usr/sbin/iconvconfig
x86_64-linux-gnu-gcc-4.7 -nostdlib -nostartfiles -o
/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/iconv/iconv_prog
-Wl,-dynamic-linker=/lib64/ld-linux-x86-64.so.2 -Wl,-z,combreloc -Wl,-z,relro
-Wl,--hash-style=both /tmp/buildd/eglibc-2.17/build-tree/amd64-libc/csu/crt1.o
/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/csu/crti.o
`x86_64-linux-gnu-gcc-4.7 --print-file-name=crtbegin.o`
/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/iconv/iconv_prog.o
/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/iconv/iconv_charmap.o
/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/iconv/charmap.o
/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/iconv/charmap-dir.o
/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/iconv/linereader.o
/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/iconv/dummy-repertoire.o
/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/iconv/simple-hash.o
/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/iconv/xstrdup.o
/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/iconv/xmalloc.o
-Wl,-rpath-link=/tmp/buildd/eglibc-2.17/build-tree/amd64-libc:/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/math:/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/elf:/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/dlfcn:/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/nss:/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/nis:/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/rt:/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/resolv:/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/crypt:/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/nptl
/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/libc.so.6
/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/libc_nonshared.a -Wl,--as-needed
/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/elf/ld.so -Wl,--no-as-needed
-lgcc `x86_64-linux-gnu-gcc-4.7 --print-file-name=crtend.o`
/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/csu/crtn.o
.././scripts/mkinstalldirs /tmp/buildd/eglibc-2.17/debian/tmp-libc/usr/bin
mkdir /tmp/buildd/eglibc-2.17/debian/tmp-libc/usr/bin
/usr/bin/install -c
/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/iconv/iconv_prog
/tmp/buildd/eglibc-2.17/debian/tmp-libc/usr/bin/iconv.new
mv -f /tmp/buildd/eglibc-2.17/debian/tmp-libc/usr/bin/iconv.new
/tmp/buildd/eglibc-2.17/debian/tmp-libc/usr/bin/iconv
(cd /tmp/buildd/eglibc-2.17/build-tree/amd64-libc/iconv/.; objdump -h
iconv_open.o iconv.o iconv_close.o gconv_open.o gconv.o gconv_close.o
gconv_db.o gconv_conf.o gconv_builtin.o gconv_simple.o gconv_trans.o
gconv_cache.o gconv_dl.o iconv_open.os iconv.os iconv_close.os gconv_open.os
gconv.os gconv_close.os gconv_db.os gconv_conf.os gconv_builtin.os
gconv_simple.os gconv_trans.os gconv_cache.os gconv_dl.os iconv_open.op
iconv.op iconv_close.op gconv_open.op gconv.op gconv_close.op gconv_db.op
gconv_conf.op gconv_builtin.op gconv_simple.op gconv_trans.op gconv_cache.op
gconv_dl.op iconv_charmap.o charmap.o charmap-dir.o linereader.o
dummy-repertoire.o simple-hash.o xstrdup.o xmalloc.o strtab.o hash-string.o) | \
gawk '/\.gnu\.glibc-stub\./ { \
sub(/\.gnu\.glibc-stub\./, "", $2); \
stubs[$2] = 1; } \
END { for (s in stubs) print "#define __stub_" s }' >
/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/iconv/stubsT
mv -f /tmp/buildd/eglibc-2.17/build-tree/amd64-libc/iconv/stubsT
/tmp/buildd/eglibc-2.17/build-tree/amd64-libc/iconv/stubs
make[3]: Leaving directory `/tmp/buildd/eglibc-2.17/iconv'
/usr/bin/make subdir=locale -C locale ..=../ subdir_install
make[3]: Entering directory `/tmp/buildd/eglibc-2.17/locale'
make[3]: Leaving directory `/tmp/buildd/eglibc-2.17/locale'
make[3]: Entering directory `/tmp/buildd/eglibc-2.17/locale'
/usr/bin/install -c -m 644 locale.h /usr/include/locale.h
/usr/bin/install: cannot remove '/usr/include/locale.h': Permission denied
make[3]: *** [/usr/include/locale.h] Error 1
make[3]: Leaving directory `/tmp/buildd/eglibc-2.17/locale'
make[2]: *** [locale/subdir_install] Error 2
make[2]: Leaving directory `/tmp/buildd/eglibc-2.17'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/tmp/buildd/eglibc-2.17/build-tree/amd64-libc'
make: *** [/tmp/buildd/eglibc-2.17/stamp-dir/install_libc] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
(It seems strange that there are several successful directories, and then
suddenly in locale/ it forgets about DESTDIR. But this is 100% reproducible
with this version of make. Even stranger, if I rerun fakeroot debian/rules
binary after this failure, it goes through successfully, even for the
subsequent i386 and x32 installs.)
--
Daniel Schepler
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/72512315.AsaItdiPd1@frobozz
Changes needed for building eglibc on x32
Here's a patch I needed to get eglibc (2.16-0experimental0) building on x32 again. Without it, the build fails when it comes time to do the "native" compile of rpcgen, trying to use gcc-4.6. The patch will probably also be needed for sysdeps/arm64.mk. * Fix build on x32: BUILD_CC and BUILD_CXX also need to be overridden to gcc-4.7 and g++-4.7, respectively. diff -Nru eglibc-2.16/debian/sysdeps/x32.mk eglibc-2.16/debian/sysdeps/x32.mk --- eglibc-2.16/debian/sysdeps/x32.mk 2012-10-25 09:23:58.0 -0700 +++ eglibc-2.16/debian/sysdeps/x32.mk 2012-11-25 02:42:33.0 -0800 @@ -4,6 +4,8 @@ # There is no gcc-4.6 for x32, so use 4.7 CC = $(DEB_HOST_GNU_TYPE)-$(BASE_CC)-4.7 CXX = $(DEB_HOST_GNU_TYPE)-$(BASE_CXX)-4.7 +BUILD_CC = $(DEB_HOST_GNU_TYPE)-$(BASE_CC)-4.7 +BUILD_CXX = $(DEB_HOST_GNU_TYPE)-$(BASE_CXX)-4.7 # build 64-bit (amd64) alternative library EGLIBC_PASSES += amd64 -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201211250712.53215.dschep...@gmail.com
Re: Issue with upgrading libc6-dev-amd64:i386 to 2.16
I also just noticed that you merged in my changes to debian/rules.d/tarball.mk setting an explicit checkout revision for making the orig.tar.xz. That was meant to be a purely local change, to get me something comparable to what debian/patches was originally applying against, but I guess it must have leaked into the patch I posted previously. You can feel free to revert that part of the changes if you want. But while I'm thinking about it -- do we actually need linuxthreads for anything anymore? It's no longer distributed at all by glibc upstream (there isn't even a glibc-linuxthreads.git to parallel glibc.git and glibc-ports.git). -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadf0c47qjy-znr-4le6c5vhnxqj6unsizu6x1ckzrevg6yn...@mail.gmail.com
Issue with upgrading libc6-dev-amd64:i386 to 2.16
Hi, I just noticed that you merged my x32 changes into the SVN eglibc-2.16 branch - thanks. I just thought I'd give you a heads-up on an issue I saw while doing these changes: if I upgrade libc6-dev-amd64 in an i386 chroot from 2.13-35 to 2.16-0experimental0, several header files under /usr/include/bits get lost. I would guess it's because of the reorganization changing copies of amd64 headers into symlinks on that arch. I'm not sure I'm familiar enough with the intricacies of dpkg maintainer scripts to formulate a proper fix myself, though. So for now, I'm just working around it by installing the newer libc6-dev-amd64 package twice. -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADf0C47hH_-f5hoJB1qv1NB=K7mXo5vYGBQZ5Pso-=0unow...@mail.gmail.com
Re: Issues with trying to build Debian x32 gcc with multilib support
On Wed, Oct 17, 2012 at 9:15 AM, Daniel Schepler wrote: > Here are my current changes against the 2.16 branch of eglibc SVN. So > far, it's built packages on x32 and amd64 without any problems, and I > don't foresee any difficulties with i386. Once I have everything > built, I'll update the packages on people.debian.org this evening. I've now updated the packages on people.debian.org with the new eglibc builds. -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadf0c458c0ewk-pvebkore-lkmq-4ybsmwgt724_1cuzx5f...@mail.gmail.com
Re: Issues with trying to build Debian x32 gcc with multilib support
On Mon, Oct 15, 2012 at 4:18 PM, Daniel Schepler wrote: > This merge might take a couple days, depending on how smoothly it > goes. So, I'm going to try to upload the following to > people.debian.org this evening: > * kernel packages (somewhat outdated) built with CONFIG_X86_X32=y > * gcc-4.7packages (also somewhat outdated) > * libc packages based on the glibc 2.16 release and eglibc 2.13-34 > packaging with most Debian patches stripped out. All right, these are now uploaded to deb http://people.debian.org/~schepler/x32 amd64/ (or of course, you can replace the amd64 with i386). Sorry it took so long -- in the middle of the transfer, I started having connectivity problems to ravel. Plus, I realized I'd only built the latest iteration of the glibc packages for x32, so I had to go back and quickly build them for amd64 and i386. -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADf0C47y1PRc5pHBd=uLLm6DArt+k333b5kxxv3Av=am4q5...@mail.gmail.com
Re: Issues with trying to build Debian x32 gcc with multilib support
On Mon, Oct 15, 2012 at 3:01 AM, Matthias Klose wrote: > On 12.10.2012 20:44, Daniel Schepler wrote: >> I did the changes to add libx32gcc1 et al on amd64 and i386, and build >> lib64* and lib32* on x32; but I haven't updated the changes since >> 4.7.1-7. I'm attaching the debdiff for 4.7.1-7 to my local >> 4.7.1-7+x32+1 version for now. If you want, I'd be happy to look at >> forward porting the changes (and hopefully reducing the hard-coding in >> the amd64/i386/x32 triarch config, if you have suggestions on how to >> do that). Just let me know where to check things out. >> >> I guess we'd need to coordinate this with adding x32 builds to eglibc >> 2.16 experimental... I also have preliminary patches for that, of >> course. > > could you send these as well, and maybe coordinate the integration of these > with > Adam Conrad? OK, I've now found svn://svn.debian.org/pkg-glibc/glibc-package/branches/eglibc-2.16/debian which should provide a good base for integrating my eglibc changes for x32 support. What exactly should I be using as the orig.tar.xz files to put this on top of for my merge? Also, on a technical note, I'll need to apply a patch that fixes glibc BZ#14562 (assuming it's not already applied otherwise). It seems to be more important on x32 than on other builds/architectures, but it's not formulated as an x32-specific fix. The fix was already committed in glibc git a couple weeks ago, so it's probably migrated into eglibc CVS by now. So what would I name this patch, and what formatting guidelines would I need to adhere to for the patch file itself? This merge might take a couple days, depending on how smoothly it goes. So, I'm going to try to upload the following to people.debian.org this evening: * kernel packages (somewhat outdated) built with CONFIG_X86_X32=y * gcc-4.7packages (also somewhat outdated) * libc packages based on the glibc 2.16 release and eglibc 2.13-34 packaging with most Debian patches stripped out. -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadf0c44yx1y-gzya-jqzn0kfrabmvtnw91ca3fn89tquvg+...@mail.gmail.com
Re: RFC: Patch for building x32 libc packages from glibc git master
On Sunday, June 10, 2012 02:28:55 AM Aurelien Jarno wrote: > Your changes are quite invasive and remove plenty of needed patches or > code. It's fine if your goal is only to get an x32 package, but in that > case please make it clear in the version number. Point taken -- I'll make sure to include "+x32" somewhere in the version number on the next build. Yes, this was meant as a preliminary build to get a working x32 package, without having to merge all the Debian patches into a new upstream version. I was more interested in any comments on the x32-specific parts. -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201206101018.50335.dschep...@gmail.com
Bug#672934: eglibc: New upstream version available
Source: eglibc Version: 2.13-32 Severity: wishlist According to eglibc.org, 2.14 and 2.15 branches are available, and according to www.gnu.org/software/libc, GLIBC 2.15 has been released. I'm curious what plans, if any, there are for upgrading the version of eglibc in experimental and/or sid. -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADf0C44fKrYAELoT7VLsdDSJ8Y4KH_7OuqLNy4ZFyxGhV0Kv=w...@mail.gmail.com
Bug#643567: eglibc: Yet another test (tst-cancelx17) which sometimes fails
On Tuesday, September 27, 2011 12:51:15 PM Aurelien Jarno wrote: > On Tue, Sep 27, 2011 at 08:54:28AM -0700, Daniel Schepler wrote: > > Encountered regressions that don't match expected failures: > > tst-cancelx17.out, Error 1 > > make: *** [/tmp/buildd/eglibc-2.13/stamp-dir/check_libc] Error 1 > > dpkg-buildpackage: error: debian/rules build gave error exit status 2 > > I never seen that, and amd64 is my usual build architecture. Which > kernel version are you using? It's 3.0.0-1-amd64. I do seem to notice these extra test failures more regularly on my laptop than on my desktop machine -- maybe powersave mode is kicking in on the laptop and messing up timing? -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201109271922.13532.dschep...@gmail.com
Bug#643567: eglibc: Yet another test (tst-cancelx17) which sometimes fails
Source: eglibc Version: 2.13-21 Severity: important From my pbuilder build log (on amd64, this time): ... make[2]: Target `check' not remade because of errors. make[2]: Leaving directory `/tmp/buildd/eglibc-2.13' make[1]: *** [check] Error 2 make[1]: Leaving directory `/tmp/buildd/eglibc-2.13/build-tree/amd64-libc' # # Testsuite failures, someone should be working towards # fixing these! They are listed here for the purpose of # regression testing during builds. # Format: , Error [(ignored)] # annexc.out, Error 1 (ignored) tst-cancelx17.out, Error 1 tst-cpuclock2.out, Error 1 tst-writev.out, Error 1 *** Encountered regressions that don't match expected failures: tst-cancelx17.out, Error 1 make: *** [/tmp/buildd/eglibc-2.13/stamp-dir/check_libc] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201109270854.29386.dschep...@gmail.com
Bug#640276: tzdata: FTBFS: Cannot find openjdk-6 JVM
Source: tzdata Version: 2011i-1 Severity: serious From my pbuilder build log: ... # Generate a java version /usr/lib/jvm/java-6-openjdk/bin/java -jar /usr/lib/jvm/java-6- openjdk/jre/lib/javazic.jar -V 2011i -d /tmp/buildd/tzdata-2011i/tzgen-java africa antarctica asia australasia europe northamerica southamerica etcetera factory backward systemv pacificnew solar87 solar88 solar89 gmt jdk11_backward make: /usr/lib/jvm/java-6-openjdk/bin/java: Command not found make: *** [build-indep-stamp] Error 127 dpkg-buildpackage: error: debian/rules build gave error exit status 2 -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201109031312.51365.dschep...@gmail.com
Bug#637000: libc6-dev-amd64: uintptr_t is a 32-bit type
Package: libc6-dev-amd64
Version: 2.13-14
Severity: serious
On i386 (actually with "linux32 pbuilder login" into a 32-bit pbuilder chroot
on amd64), I get the following issue:
root@frobozz:/tmp# cat intptr_t_test.c
#include
#include
int main() {
printf("sizeof(uintptr_t) = %lu\n", (unsigned long) sizeof(uintptr_t));
return 0;
}
root@frobozz:/tmp# gcc -m32 -o intptr_t_test_32 intptr_t_test.c
root@frobozz:/tmp# ./intptr_t_test_32
sizeof(uintptr_t) = 4
root@frobozz:/tmp# gcc -m64 -o intptr_t_test_64 intptr_t_test.c
root@frobozz:/tmp# ./intptr_t_test_64
sizeof(uintptr_t) = 4
On amd64 with libc6-dev-i386, the same test passes, returning 4 and 8
respectively.
Marking this as serious because it's currently causing at least gcc-4.5 and
gcc-4.6 to FTBFS on i386 (haven't checked gcc-4.4):
...
cc1: warnings being treated as errors
In file included from ../../../../src/libgomp/libgomp.h:50:0,
from ../../../../src/libgomp/alloc.c:29:
../../../../src/libgomp/config/linux/ptrlock.h: In function 'gomp_ptrlock_get':
../../../../src/libgomp/config/linux/ptrlock.h:42:7: error: cast from pointer
to integer of different size
...
--
Daniel Schepler
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201108070945.50853.dschep...@gmail.com
Bug#556559: eglibc: FTBFS [amd64]: Test failure in tst-mqueue5
On Sunday 22 November 2009 14:41:05 you wrote: > On Tue, Nov 17, 2009 at 08:17:15AM +0100, Aurelien Jarno wrote: > > tag 556559 + unreproducible > > thanks > > > > On Mon, Nov 16, 2009 at 11:02:13AM -0800, Daniel Schepler wrote: > > > Package: eglibc > > > Version: 2.10.1-7 > > > Severity: serious > > > > > > From my pbuilder build log: > > > > > > ... > > > # > > > # Testsuite failures, someone should be working towards > > > # fixing these! They are listed here for the purpose of > > > # regression testing during builds. > > > # Format: , Error [(ignored)] > > > # > > > annexc.out, Error 1 (ignored) > > > check-localplt.out, Error 1 > > > tst-mqueue5.out, Error 1 > > > *** > > > Encountered regressions that don't match expected failures: > > > tst-mqueue5.out, Error 1 > > > make: *** [/tmp/buildd/eglibc-2.10.1/stamp-dir/check_libc] Error 1 > > > dpkg-buildpackage: error: debian/rules build gave error exit status 2 > > > > > > This seems to be an intermittent error, but I've seen it several times > > > before on previous builds of eglibc. > > > > How often are you seeing this problem? I have done dozens of build of > > eglibc 2.10.1 on amd64 and never seen his problem. > > > > Could you please send use the content of > > build-tree/amd64-libc/rt/tst-mqueue5.out so we can have more details > > about the problem? > > > > Are you using an up to date sid chroot to build eglibc, do you use > > modified packages? > > > > Finally what is your kernel version? Do you have any additional patches? > > Any news on that? I can't seem to reproduce the bug at will, even by running the mqueue5 executable multiple times in a row. And unfortunately, usually the unpacked pbuilder chroot is gone by the time I see this error, so I haven't been able to check mqueue5.out. Actually, I think that the previous times I saw an mqueue5 failure, it was in the amd64 tests building eglibc in an i386 chroot on an amd64 machine. This is probably the first time I saw it in a pure amd64 build. So maybe it's easier to reproduce in that situation. -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#556559: eglibc: FTBFS [amd64]: Test failure in tst-mqueue5
Package: eglibc Version: 2.10.1-7 Severity: serious From my pbuilder build log: ... # # Testsuite failures, someone should be working towards # fixing these! They are listed here for the purpose of # regression testing during builds. # Format: , Error [(ignored)] # annexc.out, Error 1 (ignored) check-localplt.out, Error 1 tst-mqueue5.out, Error 1 *** Encountered regressions that don't match expected failures: tst-mqueue5.out, Error 1 make: *** [/tmp/buildd/eglibc-2.10.1/stamp-dir/check_libc] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 This seems to be an intermittent error, but I've seen it several times before on previous builds of eglibc. -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533364: libc6-i386: Missing /lib/ld-linux.so.2
Package: libc6-i386
Version: 2.9-15
Severity: grave
My test session log from within a pbuilder chroot:
...
frobozz:/tmp# apt-get install gcc-multilib
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
gcc-4.3-multilib lib32gcc1 libc6-dev-i386 libc6-i386
The following NEW packages will be installed:
gcc-4.3-multilib gcc-multilib lib32gcc1 libc6-dev-i386 libc6-i386
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B/7659kB of archives.
After this operation, 18.6MB of additional disk space will be used.
Do you want to continue [Y/n]?
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously deselected package libc6-i386.
(Reading database ... 9818 files and directories currently installed.)
Unpacking libc6-i386 (from .../libc6-i386_2.9-15_amd64.deb) ...
Selecting previously deselected package libc6-dev-i386.
Unpacking libc6-dev-i386 (from .../libc6-dev-i386_2.9-15_amd64.deb) ...
Selecting previously deselected package lib32gcc1.
Unpacking lib32gcc1 (from .../lib32gcc1_1%3a4.4.0-6_amd64.deb) ...
Selecting previously deselected package gcc-4.3-multilib.
Unpacking gcc-4.3-multilib (from .../gcc-4.3-multilib_4.3.3-11_amd64.deb) ...
Selecting previously deselected package gcc-multilib.
Unpacking gcc-multilib (from .../gcc-multilib_4%3a4.3.3-9_amd64.deb) ...
Setting up libc6-i386 (2.9-15) ...
Setting up libc6-dev-i386 (2.9-15) ...
Setting up lib32gcc1 (1:4.4.0-6) ...
Setting up gcc-4.3-multilib (4.3.3-11) ...
Setting up gcc-multilib (4:4.3.3-9) ...
frobozz:/tmp# cat hello.c
#include
int main() { printf("Hello 32-bit world!\n"); return 0; }
frobozz:/tmp# gcc -m32 -o hello hello.c
frobozz:/tmp# ./hello
-bash: ./hello: No such file or directory
--
Daniel Schepler
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#453072: gcj-4.2: Java processes are memory hogs on amd64
Package: gcj-4.2 Version: 4.2.2-3 Severity: important X-Debbugs-CC: debian-glibc@lists.debian.org It appears that the bug making gcj-4.2 based Java processes consume insane amounts of memory on amd64 is still there. For example, trying to build checkstyle under pbuilder, I watched the `java' process grow to over 4G virtual memory before I had to kill it. Cc to debian-glibc because as I recall, the bug was previously worked around in glibc, but it seems not to be any more since version 2.7-1. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#433962: libc6-dev: error including
Package: libc6-dev Version: 2.6-2 Severity: important Tags: sid Blocks: 428952 On an i386 sid system (with linux-libc-dev version 2.6.22): [EMAIL PROTECTED]:/tmp$ cat test.c #include [EMAIL PROTECTED]:/tmp$ gcc -c test.c In file included from /usr/include/netinet/if_fddi.h:26, from test.c:1: /usr/include/linux/if_fddi.h:88: error: expected specifier-qualifier-list before ‘__be16’ This is causing net-tools to FTBFS (bug #428952). -- Daniel Schepler
Bug #355099: kdelibs FTBFS
After some investigation of the failure of kdelibs to build, I found it appears to be a bug in either libtool, ld, or the dynamic linker, so I'm CC'ing the maintainers of those packages. The problem is that lt-meinproc is getting linked with a NEEDED entry pointing to libkdecore.so because it directly uses symbols from that library, which is indirectly brought in by the -lkio argument, but the RPATH on the resulting binary only includes the directory containing libkio.so. Then the dynamic linker can't find where libkdecore.so is, despite the fact that libkio.so's RPATH includes the directories containing its dependencies, and one of those libraries has the RPATH needed for libkdecore.so. So I can see a few different ways to fix this: * Make libtool include all indirect rpath's directly on the link command line. But I find this ugly, and in fact a step backwards from recent improvements, and it really doesn't solve the general problem either. * Make the dynamic loader able to find libraries within rpath's from already loaded libraries. But this doesn't totally solve the case outside libtool -- what if that other library then gets relinked in such a way that it doesn't indirectly include that rpath anymore? * Make ld add the required directory to RPATH when it automatically adds a NEEDED entry due to direct usage of symbols from the library involved. Somewhat ugly, though. Anyway, in the meantime, this can be fixed in the kdelibs package by adding $(LIB_KDECORE) explicitly to meinproc_LDADD, which it's appropriate to list anyway since meinproc directly uses kdecore functions. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334673: libc6-dev-amd64: Cannot link 64-bit programs
Package: libc6-dev-amd64 Severity: important Version: 2.3.5-7 When I try linking a simple test program in 64-bit mode, I get: frobnitz:/tmp/buildd# gcc -m64 -o test test.c /usr/bin/ld: warning: ld-linux-x86-64.so.2, needed by /lib64/libc.so.6, not found (try using -rpath or -rpath-link) /lib64/libc.so.6: undefined reference to [EMAIL PROTECTED]' /lib64/libc.so.6: undefined reference to [EMAIL PROTECTED]' /lib64/libc.so.6: undefined reference to [EMAIL PROTECTED]' /lib64/libc.so.6: undefined reference to [EMAIL PROTECTED]' /lib64/libc.so.6: undefined reference to [EMAIL PROTECTED]' /lib64/libc.so.6: undefined reference to [EMAIL PROTECTED]' /lib64/libc.so.6: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status If I create a symlink /lib/ld-linux-x86-64.so.2 -> /lib64/ld-linux-x86-64.so.2, the link stage succeeds -- but that might not be a proper solution in general. (Especially if it also happens with other binary dependencies between 64-bit libraries, which I haven't been able to test.) I don't know whether this is actually a problem in the glibc, gcc, or binutils packages -- feel free to reassign, or clone/block, as appropriate. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318565: linux-kernel-headers: Missing linux/umsdos_fs.h
Package: linux-kernel-headers Version: 2.6.12.0-1 Severity: normal As the subject says, the package is missing linux/umsdos_fs.h, which causes the umsdos package to FTBFS: ... gcc -I../include -pipe -O2 -g -Wall -Wno-implicit-function-declaration -Wno-implicit -o testver testver.o umsdosio.o ../debian/mangle.c ../debian/mangle.c:13:29: error: linux/umsdos_fs.h: No such file or directory ../debian/mangle.c:28: warning: 'struct umsdos_info' declared inside parameter list ../debian/mangle.c:28: warning: its scope is only this definition or declaration, which is probably not what you want ... make[2]: *** [mangle.o] Error 1 make[2]: Leaving directory `/tmp/buildd/umsdos-1.13/util' make[1]: *** [all] Error 2 make[1]: Leaving directory `/tmp/buildd/umsdos-1.13' make: *** [build-stamp] Error 2 -- System Information: Debian Release: testing/unstable Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-9-amd64-k8 Locale: LANG=en, LC_CTYPE=en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) -- no debconf information -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#315793: glibc: FTBFS with new dpkg
Package: glibc Severity: serious Version: 2.3.2.ds1-22 >From my build log, using pbuilder in an i386 chroot: ... touch /tmp/buildd/glibc-2.3.2.ds1/stamp-dir/glibc-2.3.2.tar.bz2 touch /tmp/buildd/glibc-2.3.2.ds1/stamp-dir/unpack test -d /tmp/buildd/glibc-2.3.2.ds1/stamp-dir/patched || install -d /tmp/buildd/glibc-2.3.2.ds1/stamp-dir/patched applying patch debian/patches/10_cvs.dpatch... failed. make: *** [/tmp/buildd/glibc-2.3.2.ds1/stamp-dir/patch-stamp] Error 1 I get similar errors trying to build the current version from experimental. On the other hand, if I edit debian/rules to use DEB_HOST_ARCH_OS instead of DEB_HOST_GNU_SYSTEM, the patches apply fine. -- System Information: Debian Release: testing/unstable Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-9-amd64-k8 Locale: LANG=en, LC_CTYPE=en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#215463: fenris: FTBFS: Cannot execute /lib/libc.so.6
Bill Allombert <[EMAIL PROTECTED]> writes: > On Sat, Jan 31, 2004 at 08:37:21AM -0800, Daniel Schepler wrote: >> Package: fenris >> Severity: serious >> Version: 1:0.07build3244-2.1 >> >> >From my build log: >> >> ... >> [+] Version (build): 0.07-m (3244) >> [*] Overriding sanity checks! Yuppi! >> [+] Operating system check: Linux (supported) >> [+] Processor check: i686 (supported) >> [+] GNU C library version: ./build: line 1: /lib/libc.so.6: Permission denied >> cannot determine libc version! >> [-] I am affraid I cannot continue. Please consult documentation. >> >> make: *** [build-stamp] Error 1 >> >> I think that file was made non-executable because even if it were >> executable, the dynamic loader would fail with a failed assertion. I >> guess you'll have to find another method to find the glibc version. > > (irrespective of whether it is a sane thing to do) > The dynamic loader do not fail: > > %/lib/ld-linux.so.2 /lib/libc.so.6 > GNU C Library stable release version 2.3.2, by Roland McGrath et al. > Copyright (C) 2003 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. > Compiled by GNU CC version 3.3.3 20031206 (prerelease) (Debian). > Compiled on a Linux 2.6.0-test7 system on 2004-01-20. > Available extensions: > GNU libio by Per Bothner > crypt add-on version 2.1 by Michael Glad and others > linuxthreads-0.10 by Xavier Leroy > BIND-8.2.3-T5B > libthread_db work sponsored by Alpha Processor Inc > NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk > Thread-local storage support included. > Report bugs using the `glibcbug' script to <[EMAIL PROTECTED]>. That's strange, it still gives the assertion failure on my machine: [EMAIL PROTECTED]:~$ /lib/ld-linux.so.2 /lib/libc.so.6 Inconsistency detected by ld.so: rtld.c: 1259: dl_main: Assertion `_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next' failed! [EMAIL PROTECTED]:~$ /lib/ld-linux.so.2 /lib/tls/libc.so.6 Inconsistency detected by ld.so: rtld.c: 1259: dl_main: Assertion `_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next' failed! [EMAIL PROTECTED]:~$ /lib/ld-linux.so.2 /lib/tls/i686/cmov/libc.so.6 Inconsistency detected by ld.so: rtld.c: 1259: dl_main: Assertion `_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next' failed! > /lib/libc.so.6 in woody is executable, FWIW. > Glibc maintainers: was it changed on purpose ? > changelog is unclear about it. I think it was probably intentional; see bug #215463. -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card
Bug#215463: fenris: FTBFS: Cannot execute /lib/libc.so.6
Bill Allombert <[EMAIL PROTECTED]> writes: > On Sat, Jan 31, 2004 at 08:37:21AM -0800, Daniel Schepler wrote: >> Package: fenris >> Severity: serious >> Version: 1:0.07build3244-2.1 >> >> >From my build log: >> >> ... >> [+] Version (build): 0.07-m (3244) >> [*] Overriding sanity checks! Yuppi! >> [+] Operating system check: Linux (supported) >> [+] Processor check: i686 (supported) >> [+] GNU C library version: ./build: line 1: /lib/libc.so.6: Permission denied >> cannot determine libc version! >> [-] I am affraid I cannot continue. Please consult documentation. >> >> make: *** [build-stamp] Error 1 >> >> I think that file was made non-executable because even if it were >> executable, the dynamic loader would fail with a failed assertion. I >> guess you'll have to find another method to find the glibc version. > > (irrespective of whether it is a sane thing to do) > The dynamic loader do not fail: > > %/lib/ld-linux.so.2 /lib/libc.so.6 > GNU C Library stable release version 2.3.2, by Roland McGrath et al. > Copyright (C) 2003 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. > Compiled by GNU CC version 3.3.3 20031206 (prerelease) (Debian). > Compiled on a Linux 2.6.0-test7 system on 2004-01-20. > Available extensions: > GNU libio by Per Bothner > crypt add-on version 2.1 by Michael Glad and others > linuxthreads-0.10 by Xavier Leroy > BIND-8.2.3-T5B > libthread_db work sponsored by Alpha Processor Inc > NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk > Thread-local storage support included. > Report bugs using the `glibcbug' script to <[EMAIL PROTECTED]>. That's strange, it still gives the assertion failure on my machine: [EMAIL PROTECTED]:~$ /lib/ld-linux.so.2 /lib/libc.so.6 Inconsistency detected by ld.so: rtld.c: 1259: dl_main: Assertion `_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next' failed! [EMAIL PROTECTED]:~$ /lib/ld-linux.so.2 /lib/tls/libc.so.6 Inconsistency detected by ld.so: rtld.c: 1259: dl_main: Assertion `_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next' failed! [EMAIL PROTECTED]:~$ /lib/ld-linux.so.2 /lib/tls/i686/cmov/libc.so.6 Inconsistency detected by ld.so: rtld.c: 1259: dl_main: Assertion `_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next' failed! > /lib/libc.so.6 in woody is executable, FWIW. > Glibc maintainers: was it changed on purpose ? > changelog is unclear about it. I think it was probably intentional; see bug #215463. -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#224570: linux-kernel-headers: linux/isdn.h is broken
Package: linux-kernel-headers Version: 2.5.999-test7-bk-10 Severity: important When I try building a source file containing just "#include ", it gives errors: In file included from /usr/include/linux/timer.h:6, from /usr/include/linux/isdn/fsm.h:15, from /usr/include/linux/isdn.h:18, from /tmp/isdn.c:1: /usr/include/linux/spinlock.h: In function `bit_spin_lock': /usr/include/linux/spinlock.h:413: error: invalid type argument of `->' /usr/include/linux/spinlock.h: In function `bit_spin_trylock': /usr/include/linux/spinlock.h:430: error: invalid type argument of `->' /usr/include/linux/spinlock.h:433: error: invalid type argument of `->' /usr/include/linux/spinlock.h:433: error: `TIF_NEED_RESCHED' undeclared (first use in this function) /usr/include/linux/spinlock.h:433: error: (Each undeclared identifier is reported only once /usr/include/linux/spinlock.h:433: error: for each function it appears in.) In file included from /usr/include/linux/timer.h:6, from /usr/include/linux/isdn/fsm.h:15, from /usr/include/linux/isdn.h:18, from /tmp/isdn.c:1: /usr/include/linux/spinlock.h: In function `bit_spin_unlock': /usr/include/linux/spinlock.h:451: error: invalid type argument of `->' /usr/include/linux/spinlock.h:451: error: `TIF_NEED_RESCHED' undeclared (first use in this function) In file included from /usr/include/linux/isdn/fsm.h:15, from /usr/include/linux/isdn.h:18, from /tmp/isdn.c:1: /usr/include/linux/timer.h: At top level: /usr/include/linux/timer.h:11: error: field `entry' has incomplete type /usr/include/linux/timer.h: In function `init_timer': /usr/include/linux/timer.h:43: error: `NULL' undeclared (first use in this function) /usr/include/linux/timer.h: In function `timer_pending': /usr/include/linux/timer.h:60: error: `NULL' undeclared (first use in this function) Removing the include of from linux/isdn.h fixes this, and also fixes build errors in several packages, including at least pdnsd, isdnbutton, and libgtop2. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux frobnitz 2.6.0-test11 #1 Wed Dec 3 21:42:26 PST 2003 i686 Locale: LANG=en, LC_CTYPE=en (ignored: LC_ALL set to en_US.ISO-8859-1) -- no debconf information -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card
Bug#224570: linux-kernel-headers: linux/isdn.h is broken
Package: linux-kernel-headers Version: 2.5.999-test7-bk-10 Severity: important When I try building a source file containing just "#include ", it gives errors: In file included from /usr/include/linux/timer.h:6, from /usr/include/linux/isdn/fsm.h:15, from /usr/include/linux/isdn.h:18, from /tmp/isdn.c:1: /usr/include/linux/spinlock.h: In function `bit_spin_lock': /usr/include/linux/spinlock.h:413: error: invalid type argument of `->' /usr/include/linux/spinlock.h: In function `bit_spin_trylock': /usr/include/linux/spinlock.h:430: error: invalid type argument of `->' /usr/include/linux/spinlock.h:433: error: invalid type argument of `->' /usr/include/linux/spinlock.h:433: error: `TIF_NEED_RESCHED' undeclared (first use in this function) /usr/include/linux/spinlock.h:433: error: (Each undeclared identifier is reported only once /usr/include/linux/spinlock.h:433: error: for each function it appears in.) In file included from /usr/include/linux/timer.h:6, from /usr/include/linux/isdn/fsm.h:15, from /usr/include/linux/isdn.h:18, from /tmp/isdn.c:1: /usr/include/linux/spinlock.h: In function `bit_spin_unlock': /usr/include/linux/spinlock.h:451: error: invalid type argument of `->' /usr/include/linux/spinlock.h:451: error: `TIF_NEED_RESCHED' undeclared (first use in this function) In file included from /usr/include/linux/isdn/fsm.h:15, from /usr/include/linux/isdn.h:18, from /tmp/isdn.c:1: /usr/include/linux/timer.h: At top level: /usr/include/linux/timer.h:11: error: field `entry' has incomplete type /usr/include/linux/timer.h: In function `init_timer': /usr/include/linux/timer.h:43: error: `NULL' undeclared (first use in this function) /usr/include/linux/timer.h: In function `timer_pending': /usr/include/linux/timer.h:60: error: `NULL' undeclared (first use in this function) Removing the include of from linux/isdn.h fixes this, and also fixes build errors in several packages, including at least pdnsd, isdnbutton, and libgtop2. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux frobnitz 2.6.0-test11 #1 Wed Dec 3 21:42:26 PST 2003 i686 Locale: LANG=en, LC_CTYPE=en (ignored: LC_ALL set to en_US.ISO-8859-1) -- no debconf information -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#224360: linux-kernel-headers: linux/usb.h is broken
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > Please try removing the include of linux/mod_devicetable.h from > linux/usb.h. Does that fix it? Wrapping that include in an #ifdef __KERNEL__ fixed those compilation errors. But then when I was testing the actual package builds of eagle-adsl and fxload, I found that usbdevice_fs.h now gave errors: In file included from ezusb.c:33: /usr/include/linux/usbdevice_fs.h:49: error: variable or field `__user' declared void /usr/include/linux/usbdevice_fs.h:49: error: syntax error before '*' token /usr/include/linux/usbdevice_fs.h:56: error: variable or field `__user' declared void /usr/include/linux/usbdevice_fs.h:56: error: syntax error before '*' token /usr/include/linux/usbdevice_fs.h:100: error: variable or field `__user' declared void /usr/include/linux/usbdevice_fs.h:100: error: syntax error before '*' token /usr/include/linux/usbdevice_fs.h:109: error: syntax error before '}' token /usr/include/linux/usbdevice_fs.h:116: error: variable or field `__user' declared void /usr/include/linux/usbdevice_fs.h:116: error: syntax error before '*' token Adding #include to linux/usbdevice_fs.h fixed these errors. -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card
Bug#224360: linux-kernel-headers: linux/usb.h is broken
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > Please try removing the include of linux/mod_devicetable.h from > linux/usb.h. Does that fix it? Wrapping that include in an #ifdef __KERNEL__ fixed those compilation errors. But then when I was testing the actual package builds of eagle-adsl and fxload, I found that usbdevice_fs.h now gave errors: In file included from ezusb.c:33: /usr/include/linux/usbdevice_fs.h:49: error: variable or field `__user' declared void /usr/include/linux/usbdevice_fs.h:49: error: syntax error before '*' token /usr/include/linux/usbdevice_fs.h:56: error: variable or field `__user' declared void /usr/include/linux/usbdevice_fs.h:56: error: syntax error before '*' token /usr/include/linux/usbdevice_fs.h:100: error: variable or field `__user' declared void /usr/include/linux/usbdevice_fs.h:100: error: syntax error before '*' token /usr/include/linux/usbdevice_fs.h:109: error: syntax error before '}' token /usr/include/linux/usbdevice_fs.h:116: error: variable or field `__user' declared void /usr/include/linux/usbdevice_fs.h:116: error: syntax error before '*' token Adding #include to linux/usbdevice_fs.h fixed these errors. -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#224360: linux-kernel-headers: linux/usb.h is broken
Package: linux-kernel-headers Version: 2.5.999-test7-bk-10 Severity: important When I try compiling a file containing just "#include " I get the following errors: In file included from /usr/include/linux/usb.h:4, from /tmp/foo.c:1: /usr/include/linux/mod_devicetable.h:18: error: syntax error before "__u32" /usr/include/linux/mod_devicetable.h:20: error: syntax error before "class" /usr/include/linux/mod_devicetable.h:21: error: syntax error before "driver_data" /usr/include/linux/mod_devicetable.h:31: error: syntax error before "__u32" /usr/include/linux/mod_devicetable.h:33: error: syntax error before "model_id" /usr/include/linux/mod_devicetable.h:34: error: syntax error before "specifier_id" /usr/include/linux/mod_devicetable.h:35: error: syntax error before "version" /usr/include/linux/mod_devicetable.h:36: error: syntax error before "driver_data" /usr/include/linux/mod_devicetable.h:99: error: syntax error before "__u16" /usr/include/linux/mod_devicetable.h:103: error: syntax error before "idProduct" /usr/include/linux/mod_devicetable.h:104: error: syntax error before "bcdDevice_lo" /usr/include/linux/mod_devicetable.h:105: error: syntax error before "bcdDevice_hi" /usr/include/linux/mod_devicetable.h:108: error: syntax error before "bDeviceClass" /usr/include/linux/mod_devicetable.h:109: error: syntax error before "bDeviceSubClass" /usr/include/linux/mod_devicetable.h:110: error: syntax error before "bDeviceProtocol" /usr/include/linux/mod_devicetable.h:113: error: syntax error before "bInterfaceClass" /usr/include/linux/mod_devicetable.h:114: error: syntax error before "bInterfaceSubClass" /usr/include/linux/mod_devicetable.h:115: error: syntax error before "bInterfaceProtocol" /usr/include/linux/mod_devicetable.h:118: error: syntax error before "driver_info" /usr/include/linux/mod_devicetable.h:135: error: syntax error before "__u16" /usr/include/linux/mod_devicetable.h:138: error: syntax error before "dev_type" /usr/include/linux/mod_devicetable.h:139: error: syntax error before "cu_model" /usr/include/linux/mod_devicetable.h:140: error: syntax error before "dev_model" /usr/include/linux/mod_devicetable.h:142: error: syntax error before "driver_info" If I add "#include " before that, then I get: In file included from /usr/include/linux/usb.h:4, from /tmp/foo.c:2: /usr/include/linux/mod_devicetable.h:21: error: syntax error before "kernel_ulong_t" /usr/include/linux/mod_devicetable.h:36: error: syntax error before "kernel_ulong_t" /usr/include/linux/mod_devicetable.h:118: error: syntax error before "kernel_ulong_t" /usr/include/linux/mod_devicetable.h:142: error: syntax error before "kernel_ulong_t" This is breaking several package builds, including eagle-adsl and fxload. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux frobnitz 2.6.0-test11 #1 Wed Dec 3 21:42:26 PST 2003 i686 Locale: LANG=en, LC_CTYPE=en (ignored: LC_ALL set to en_US.ISO-8859-1) -- no debconf information -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card
Bug#224360: linux-kernel-headers: linux/usb.h is broken
Package: linux-kernel-headers Version: 2.5.999-test7-bk-10 Severity: important When I try compiling a file containing just "#include " I get the following errors: In file included from /usr/include/linux/usb.h:4, from /tmp/foo.c:1: /usr/include/linux/mod_devicetable.h:18: error: syntax error before "__u32" /usr/include/linux/mod_devicetable.h:20: error: syntax error before "class" /usr/include/linux/mod_devicetable.h:21: error: syntax error before "driver_data" /usr/include/linux/mod_devicetable.h:31: error: syntax error before "__u32" /usr/include/linux/mod_devicetable.h:33: error: syntax error before "model_id" /usr/include/linux/mod_devicetable.h:34: error: syntax error before "specifier_id" /usr/include/linux/mod_devicetable.h:35: error: syntax error before "version" /usr/include/linux/mod_devicetable.h:36: error: syntax error before "driver_data" /usr/include/linux/mod_devicetable.h:99: error: syntax error before "__u16" /usr/include/linux/mod_devicetable.h:103: error: syntax error before "idProduct" /usr/include/linux/mod_devicetable.h:104: error: syntax error before "bcdDevice_lo" /usr/include/linux/mod_devicetable.h:105: error: syntax error before "bcdDevice_hi" /usr/include/linux/mod_devicetable.h:108: error: syntax error before "bDeviceClass" /usr/include/linux/mod_devicetable.h:109: error: syntax error before "bDeviceSubClass" /usr/include/linux/mod_devicetable.h:110: error: syntax error before "bDeviceProtocol" /usr/include/linux/mod_devicetable.h:113: error: syntax error before "bInterfaceClass" /usr/include/linux/mod_devicetable.h:114: error: syntax error before "bInterfaceSubClass" /usr/include/linux/mod_devicetable.h:115: error: syntax error before "bInterfaceProtocol" /usr/include/linux/mod_devicetable.h:118: error: syntax error before "driver_info" /usr/include/linux/mod_devicetable.h:135: error: syntax error before "__u16" /usr/include/linux/mod_devicetable.h:138: error: syntax error before "dev_type" /usr/include/linux/mod_devicetable.h:139: error: syntax error before "cu_model" /usr/include/linux/mod_devicetable.h:140: error: syntax error before "dev_model" /usr/include/linux/mod_devicetable.h:142: error: syntax error before "driver_info" If I add "#include " before that, then I get: In file included from /usr/include/linux/usb.h:4, from /tmp/foo.c:2: /usr/include/linux/mod_devicetable.h:21: error: syntax error before "kernel_ulong_t" /usr/include/linux/mod_devicetable.h:36: error: syntax error before "kernel_ulong_t" /usr/include/linux/mod_devicetable.h:118: error: syntax error before "kernel_ulong_t" /usr/include/linux/mod_devicetable.h:142: error: syntax error before "kernel_ulong_t" This is breaking several package builds, including eagle-adsl and fxload. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux frobnitz 2.6.0-test11 #1 Wed Dec 3 21:42:26 PST 2003 i686 Locale: LANG=en, LC_CTYPE=en (ignored: LC_ALL set to en_US.ISO-8859-1) -- no debconf information -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#215463: libc6: Running /lib/libc-2.3.2.so gives ld.so error
Package: libc6 Version: 2.3.2-8 Severity: normal As the subject says, when I run /lib/libc-2.3.2.so to try to see the credits, I get instead: Inconsistency detected by ld.so: rtld.c: 1175: dl_main: Assertion `_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next' failed! This seems to be causing fenris not to build from source (when running pbuilder build fenris_0.07build3244-2.1.dsc, it gets the same error while trying to determine the glibc version). -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux frobnitz 2.6.0-test4 #1 Thu Aug 28 00:56:57 PDT 2003 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages libc6 depends on: ii libdb1-compat 2.1.3-7The Berkeley database routines [gl -- no debconf information -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card
Bug#215463: libc6: Running /lib/libc-2.3.2.so gives ld.so error
Package: libc6 Version: 2.3.2-8 Severity: normal As the subject says, when I run /lib/libc-2.3.2.so to try to see the credits, I get instead: Inconsistency detected by ld.so: rtld.c: 1175: dl_main: Assertion `_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next' failed! This seems to be causing fenris not to build from source (when running pbuilder build fenris_0.07build3244-2.1.dsc, it gets the same error while trying to determine the glibc version). -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux frobnitz 2.6.0-test4 #1 Thu Aug 28 00:56:57 PDT 2003 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages libc6 depends on: ii libdb1-compat 2.1.3-7The Berkeley database routines [gl -- no debconf information -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#198154: libc6: Does not install from apt-build
I'm seeing this also, but using pbuilder. With the packages built, running "i386-linux/obj/elf/ld-linux.so.2 /bin/sh" runs OK, but "LD_LIBRARY_PATH=i386-linux/obj /bin/sh" crashes with a segmentation fault. Analyzing a core dump of "LD_LIBRARY_PATH=i386-linux/obj i386-linux/obj/elf/ld-linux.so.2 /bin/sh" gives: GNU gdb 2003-06-06-cvs-debian Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"...(no debugging symbols found)... warning: core file may not match specified executable file. Core was generated by `i386-linux/obj/elf/ld-linux.so.2 /bin/sh'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libncurses.so.5...(no debugging symbols found)... done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from i386-linux/obj/libc.so.6...done. Loaded symbols for i386-linux/obj/libc.so.6 Reading symbols from i386-linux/obj/elf/ld-linux.so.2...done. Loaded symbols for i386-linux/obj/elf/ld-linux.so.2 Reading symbols from /lib/libnss_compat.so.2...done. Loaded symbols for /lib/libnss_compat.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 #0 strcmp (p1=0x8b02f8c1 , p2=0x8000e82b "") at ../sysdeps/generic/strcmp.c:38 38 ../sysdeps/generic/strcmp.c: No such file or directory. in ../sysdeps/generic/strcmp.c (gdb) bt #0 strcmp (p1=0x8b02f8c1 , p2=0x8000e82b "") at ../sysdeps/generic/strcmp.c:38 #1 0x800072e1 in _dl_name_match_p (__name=0x8b02f8c1 , __map=0x80011b58) at ldsodefs.h:172 #2 0x80007294 in do_lookup_versioned (undef_name=0x400534d6 "__udivdi3", hash=196128675, ref=0x4004c040, result=0xb6d0, scope=0x8b02f8c1, i=0, version=0x400c2730, skip=0x0, type_class=1) at do-lookup.h:210 #3 0x80006519 in _dl_lookup_versioned_symbol (undef_name=0x400534d6 "__udivdi3", undef_map=0x40042258, ref=0xb760, symbol_scope=0x400423f4, version=0x400c2730, type_class=1, flags=0) at dl-lookup.c:398 #4 0x80009130 in fixup (l=0x40042258, reloc_offset=2147556184) at dl-runtime.c:92 #5 0x800092e0 in _dl_runtime_resolve () at dl-runtime.c:229 #6 0x000a in ?? () -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card
Bug#198154: libc6: Does not install from apt-build
I'm seeing this also, but using pbuilder. With the packages built, running "i386-linux/obj/elf/ld-linux.so.2 /bin/sh" runs OK, but "LD_LIBRARY_PATH=i386-linux/obj /bin/sh" crashes with a segmentation fault. Analyzing a core dump of "LD_LIBRARY_PATH=i386-linux/obj i386-linux/obj/elf/ld-linux.so.2 /bin/sh" gives: GNU gdb 2003-06-06-cvs-debian Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"...(no debugging symbols found)... warning: core file may not match specified executable file. Core was generated by `i386-linux/obj/elf/ld-linux.so.2 /bin/sh'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libncurses.so.5...(no debugging symbols found)... done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from i386-linux/obj/libc.so.6...done. Loaded symbols for i386-linux/obj/libc.so.6 Reading symbols from i386-linux/obj/elf/ld-linux.so.2...done. Loaded symbols for i386-linux/obj/elf/ld-linux.so.2 Reading symbols from /lib/libnss_compat.so.2...done. Loaded symbols for /lib/libnss_compat.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 #0 strcmp (p1=0x8b02f8c1 , p2=0x8000e82b "") at ../sysdeps/generic/strcmp.c:38 38 ../sysdeps/generic/strcmp.c: No such file or directory. in ../sysdeps/generic/strcmp.c (gdb) bt #0 strcmp (p1=0x8b02f8c1 , p2=0x8000e82b "") at ../sysdeps/generic/strcmp.c:38 #1 0x800072e1 in _dl_name_match_p (__name=0x8b02f8c1 , __map=0x80011b58) at ldsodefs.h:172 #2 0x80007294 in do_lookup_versioned (undef_name=0x400534d6 "__udivdi3", hash=196128675, ref=0x4004c040, result=0xb6d0, scope=0x8b02f8c1, i=0, version=0x400c2730, skip=0x0, type_class=1) at do-lookup.h:210 #3 0x80006519 in _dl_lookup_versioned_symbol (undef_name=0x400534d6 "__udivdi3", undef_map=0x40042258, ref=0xb760, symbol_scope=0x400423f4, version=0x400c2730, type_class=1, flags=0) at dl-lookup.c:398 #4 0x80009130 in fixup (l=0x40042258, reloc_offset=2147556184) at dl-runtime.c:92 #5 0x800092e0 in _dl_runtime_resolve () at dl-runtime.c:229 #6 0x000a in ?? () -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#182654: missing ntp_adjtime on alpha
This is causing build failures of ntp (see bug #184172). According to the glibc ChangeLog's, ntp_adjtime was changed to an alias of adjtimex. It doesn't seem that change got propagated to the alpha port, though. It still appears in /usr/include/sys/timex.h, though. -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card
Bug#182654: missing ntp_adjtime on alpha
This is causing build failures of ntp (see bug #184172). According to the glibc ChangeLog's, ntp_adjtime was changed to an alias of adjtimex. It doesn't seem that change got propagated to the alpha port, though. It still appears in /usr/include/sys/timex.h, though. -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
