Version: 2.5 I'm trying to build an oldabi arm-v4t toolchain with glibc-2.5 linuxthreads-2.5 and ports-2.5 addon. Linking 'libc_pic.os' fails with: arm-v4t-linux-gnu-gcc -shared -static-libgcc -Wl,-O1 -Wl,-z,defs -Wl,-dynamic-linker=/lib/ld-linux.so.2 -B/home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/csu/ -Wl,--version-script=/home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/libc.map -Wl,-soname=libc.so.6 -Wl,-z,combreloc -Wl,-z,relro -nostdlib -nostartfiles -e __libc_main -L/home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build -L/home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/math -L/home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/elf -L/home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/dlfcn -L/home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/nss -L/home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/nis -L/home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/rt -L/home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/resolv -L/home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/crypt -L/home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/linuxthreads -Wl,-rpath-link=/home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build:/home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/math:/home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/elf:/home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/dlfcn:/home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/nss:/home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/nis:/home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/rt:/home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/resolv:/home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/crypt:/home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/linuxthreads -o /home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/libc.so -T /home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/shlib.lds /home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/csu/abi-note.o /home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/elf/soinit.os /home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/libc_pic.os /home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/elf/sofini.os /home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/elf/interp.os /home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/elf/ld.so -lgcc /home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/libc_pic.os: In function `__getcwd': ../sysdeps/unix/sysv/linux/getcwd.c:90: undefined reference to `MAX' MAX is undefined during compilation of "sysdeps/unix/sysv/linux/getcwd.c": arm-v4t-linux-gnu-gcc ../sysdeps/unix/sysv/linux/getcwd.c -c -std=gnu99 -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -g -Wstr ict-prototypes -I../include -I/home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/io -I/home/mkl /pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build -I../ports/sysdeps/arm/elf -I../ports/sysdeps/unix/sysv/li nux/arm/linuxthreads -I../ports/sysdeps/unix/sysv/linux/arm -I../ports/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdep s/unix/mman -I../sysdeps/unix/inet -I../ports/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../ports/sys deps/unix/arm -I../ports/sysdeps/unix -I../linuxthreads/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../ports/sysdeps/arm/linuxthr eads -I../ports/sysdeps/arm -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sy sdeps/generic/elf -I../sysdeps/generic -I../ports -I../linuxthreads -I.. -I../libio -I. -nostdinc -isystem /opt/OSELAS.Toolchain-trunk/a rm-v4t-linux-gnu/gcc-4.1.1-glibc-2.5/lib/gcc/arm-v4t-linux-gnu/4.1.1/include -isystem /opt/OSELAS.Toolchain-trunk/arm-v4t-linux-gnu/gcc-4 .1.1-glibc-2.5/sysroot-arm-v4t-linux-gnu/usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -o /home/mkl/pengutronix/ ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/io/getcwd.o -MD -MP -MF /home/mkl/pengutronix/ptxdist/build/OSELAS.Tool chain-trunk/build-target/glibc-2.5-build/io/getcwd.o.dt -MT /home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-target/glibc -2.5-build/io/getcwd.o ../sysdeps/unix/sysv/linux/getcwd.c: In function '__getcwd': ../sysdeps/unix/sysv/linux/getcwd.c:90: warning: implicit declaration of function 'MAX' arm-v4t-linux-gnu-gcc is a first stage i686->arm-v4t crosscompiler: [mkl@himalia:~/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk]$ /opt/OSELAS.Toolchain-trunk/arm-v4t-linux-gnu/gcc-4.1.1-glibc-2.5/bin/arm-v4t-linux-gnu-gcc -v Using built-in specs. Target: arm-v4t-linux-gnu Configured with: /home/mkl/pengutronix/ptxdist/build/OSELAS.Toolchain-trunk/build-cross/gcc-4.1.1/configure --host=i686-host-linux-gnu --target=arm-v4t-linux-gnu --prefix=/opt/OSELAS.Toolchain-trunk/arm-v4t-linux-gnu/gcc-4.1.1-glibc-2.5 --with-sysroot=/opt/OSELAS.Toolchain-trunk/arm-v4t-linux-gnu/gcc-4.1.1-glibc-2.5/sysroot-arm-v4t-linux-gnu --with-arch=armv4t --with-float=soft --with-fpu=vfp --disable-nls --enable-symvers=gnu --enable-__cxa_atexit --disable-multilib --disable-shared --enable-threads=no --enable-languages=c
dupe of Bug 2929 ... but perhaps we can get this fixed properly instead of simply duping it and ignoring the issue ... http://sourceware.org/ml/libc-alpha/2006-06/msg00068.html
Or perhaps you could add whatever the missing #include is, as Ulrich suggested, and we could fix it in ports, and just stop worrying about it?
ive seen this failure in a couple of ports ... i dont really care to try and track down the implicit include path in every one as simply including the header that defines MAX() in the file that uses MAX() seems a lot saner to me
Subject: Re: In function `__getcwd': undefined reference to `MAX' On Tue, Oct 31, 2006 at 08:06:19PM -0000, vapier at gentoo dot org wrote: > ive seen this failure in a couple of ports ... i dont really care to try and > track down the implicit include path in every one as simply including the header > that defines MAX() in the file that uses MAX() seems a lot saner to me One of these fixes we have the option to commit at all; the other we don't. I'll take building over not building any day.
i personally dont have the ability to directly fix either so that leaves me the luxury of bitching about it :)
ARM old-ABI support is removed and new-ABI builds OK, so I think we can take the build problem as fixed. However, I think source files should also include headers whose API actually includes providing whatever definitions the source file needs. That is, I think adding the missing #include to libc is an obvious fix. I'm pinging it on libc-alpha.
i agree completely, but Ulrich gave an unequivocal "no" when i posted patches to fix exactly that. for example: http://sources.redhat.com/ml/libc-alpha/2006-08/msg00008.html but he's said as much in other places iirc
It was agreed on libc-alpha that we do want to make this sort of change. I've checked this patch in. Just because one person objects to a patch does not mean the final conclusion will be against putting that patch in - but if people assume it does and don't speak up if they support the patch that others oppose, then we can't avoid the opposition standing. So please contribute to patch discussions if you feel you can add something useful.
not sure what you mean ... i challenged the rejection a few times but to no avail (at the time). glad it's worked out in the long run.
Many developers are now more willing than they were in 2006 not to treat a rejection as the last word on a patch but to seek a consensus conclusion from other developers instead and to commit patches on the basis of such a conclusion. We now have a general answer for this kind of patch (i.e., source files *should* include the headers declaring things they use) different from the one that applied before.