From: Joel Konkle-P. <jj...@ms...> - 2004-10-03 01:30:39
Attachments:
.config
|
I'm having a compilation failure using linux-2.6.8.1 and uml-patch-2.6.8.1-1 on Gentoo. My host kernel is gentoo-sources-2.6.8-r3 and I'm using glibc-2.3.3.20040420-r1 with NPTL. Here's the failure: -- # make linux ARCH=um [...] gcc -Wl,-T,arch/um/uml.lds.s -static -Wl,--wrap,malloc -Wl,--wrap,free -Wl,--wrap,calloc \ -o linux arch/um/main.o vmlinux -L/usr/lib -lutil vmlinux(.text+0xf8740): In function `strcpy': lib/string.c:71: multiple definition of `strcpy' arch/um/kernel/tt/unmap_fin.o(.text+0x3e8c8): first defined here /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bin/ld: Warning: size of symbol `strcpy' changed from 35 in arch/um/kernel/tt/unmap_fin.o to 32 in vmlinux vmlinux(.text+0xf8a10): In function `strrchr': lib/string.c:273: multiple definition of `strrchr' arch/um/kernel/tt/unmap_fin.o(.text+0x186c0): first defined here /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bin/ld: Warning: size of symbol `strrchr' changed from 441 in arch/um/kernel/tt/unmap_fin.o to 47 in vmlinux vmlinux(.text+0xf8980): In function `strncmp': lib/string.c:236: multiple definition of `strncmp' arch/um/kernel/tt/unmap_fin.o(.text+0x5538): first defined here /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bin/ld: Warning: size of symbol `strncmp' changed from 171 in arch/um/kernel/tt/unmap_fin.o to 66 in vmlinux vmlinux(.text+0xf9cb0): In function `sscanf': lib/vsprintf.c:836: multiple definition of `sscanf' arch/um/kernel/tt/unmap_fin.o(.text+0x31e74): first defined here vmlinux(.text+0xf8950): In function `strcmp': lib/string.c:215: multiple definition of `strcmp' arch/um/kernel/tt/unmap_fin.o(.text+0x5510): first defined here /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bin/ld: Warning: size of symbol `strcmp' changed from 37 in arch/um/kernel/tt/unmap_fin.o to 39 in vmlinux vmlinux(.text+0xf89d0): In function `strchr': lib/string.c:257: multiple definition of `strchr' arch/um/kernel/tt/unmap_fin.o(.text+0x53a0): first defined here /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bin/ld: Warning: size of symbol `strchr' changed from 359 in arch/um/kernel/tt/unmap_fin.o to 53 in vmlinux vmlinux(.text+0xf8b40): In function `strpbrk': lib/string.c:394: multiple definition of `strpbrk' arch/um/kernel/tt/unmap_fin.o(.text+0x34070): first defined here /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bin/ld: Warning: size of symbol `strpbrk' changed from 179 in arch/um/kernel/tt/unmap_fin.o to 82 in vmlinux /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bin/ld: BFD 2.14.90.0.8 20040114 assertion fail elf.c:3465 collect2: ld returned 1 exit status make: *** [linux] Error 1 # -- I've seen mention of this failure before, but I haven't seen any solutions. I've attached my .config. Any suggestions on how I can fix this? -- Joel Konkle-Parker Webmaster [Ballsome.com] E-mail [jj...@ms...] |
From: BlaisorBlade <bla...@ya...> - 2004-10-03 14:42:14
|
On Sunday 03 October 2004 03:22, Joel Konkle-Parker wrote: > I'm having a compilation failure using linux-2.6.8.1 and > uml-patch-2.6.8.1-1 on Gentoo. My host kernel is gentoo-sources-2.6.8-r3 > and I'm using glibc-2.3.3.20040420-r1 with NPTL. > > Here's the failure: > > -- > # make linux ARCH=um > > [...] > > > Any suggestions on how I can fix this? Try saving your .config, "make mrproper ARCH=um", putting the .config back and retrying the compilation.... I don't see anything else as possible reason than stale object files... -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Joel Konkle-P. <jj...@ms...> - 2004-10-03 17:47:12
|
BlaisorBlade wrote: > On Sunday 03 October 2004 03:22, Joel Konkle-Parker wrote: > >>I'm having a compilation failure using linux-2.6.8.1 and >>uml-patch-2.6.8.1-1 on Gentoo. My host kernel is gentoo-sources-2.6.8-r3 >>and I'm using glibc-2.3.3.20040420-r1 with NPTL. > > Try saving your .config, "make mrproper ARCH=um", putting the .config back and > retrying the compilation.... I don't see anything else as possible reason > than stale object files... Unfortunately, that's not it. I did exactly what you said, and I still get the same error. I've been doing it from scratch each time anyway, so stale object files aren't my problem. Here's a link to a Gentoo bug that deals with this issue: http://bugs.gentoo.org/show_bug.cgi?id=65220 Thanks for your help. -- Joel Konkle-Parker Webmaster [Ballsome.com] E-mail [jj...@ms...] |
From: Peter H. <ph...@me...> - 2004-10-03 18:33:58
|
Joel Konkle-Parker schrieb: > BlaisorBlade wrote: > >> On Sunday 03 October 2004 03:22, Joel Konkle-Parker wrote: >> >>> I'm having a compilation failure using linux-2.6.8.1 and >>> uml-patch-2.6.8.1-1 on Gentoo. My host kernel is gentoo-sources-2.6.8-r3 >>> and I'm using glibc-2.3.3.20040420-r1 with NPTL. > > > > >> Try saving your .config, "make mrproper ARCH=um", putting the .config >> back and retrying the compilation.... I don't see anything else as >> possible reason than stale object files... What about a "make ARCH=um oldconfig" ? I had some problems to build a running linux while mixing "make menuconfig" and "make ARCH=um menuconfig".... $ phu |
From: Joel Konkle-P. <jj...@ms...> - 2004-10-03 19:19:20
|
Peter Hummel wrote: > Joel Konkle-Parker schrieb: >> BlaisorBlade wrote: >>> On Sunday 03 October 2004 03:22, Joel Konkle-Parker wrote: >>> >>>> I'm having a compilation failure using linux-2.6.8.1 and >>>> uml-patch-2.6.8.1-1 on Gentoo. My host kernel is >>>> gentoo-sources-2.6.8-r3 >>>> and I'm using glibc-2.3.3.20040420-r1 with NPTL. >> >>> Try saving your .config, "make mrproper ARCH=um", putting the .config >>> back and retrying the compilation.... I don't see anything else as >>> possible reason than stale object files... > > What about a "make ARCH=um oldconfig" ? I had some problems to build a > running linux while mixing "make menuconfig" and "make ARCH=um > menuconfig".... Here's what I'm doing, in a nutshell: # make distclean ARCH=um ... # make menuconfig ARCH=um ... # make linux ARCH=um [error] Taking your advice, I tried putting in a 'make mrproper ARCH=um' after the menuconfig step and copied back the .config, but to no avail. I tried putting your 'make ARCH=um oldconfig' step between my menuconfig and linux steps, but that didn't work either. -- Joel Konkle-Parker Webmaster [Ballsome.com] E-mail [jj...@ms...] |
From: Jeremy U. <jer...@gm...> - 2004-10-04 10:15:26
|
On Sun, 03 Oct 2004 14:17:51 -0500, Joel Konkle-Parker <jj...@ms...> wrote: > Peter Hummel wrote: > > Joel Konkle-Parker schrieb: > >> BlaisorBlade wrote: > >>> On Sunday 03 October 2004 03:22, Joel Konkle-Parker wrote: > >>> > >>>> I'm having a compilation failure using linux-2.6.8.1 and > >>>> uml-patch-2.6.8.1-1 on Gentoo. My host kernel is > >>>> gentoo-sources-2.6.8-r3 > >>>> and I'm using glibc-2.3.3.20040420-r1 with NPTL. > >> > >>> Try saving your .config, "make mrproper ARCH=um", putting the .config > >>> back and retrying the compilation.... I don't see anything else as > >>> possible reason than stale object files... > > > > What about a "make ARCH=um oldconfig" ? I had some problems to build a > > running linux while mixing "make menuconfig" and "make ARCH=um > > menuconfig".... > > Here's what I'm doing, in a nutshell: > > # make distclean ARCH=um > ... > # make menuconfig ARCH=um > ... > # make linux ARCH=um > [error] > > Taking your advice, I tried putting in a 'make mrproper ARCH=um' after > the menuconfig step and copied back the .config, but to no avail. I > tried putting your 'make ARCH=um oldconfig' step between my menuconfig > and linux steps, but that didn't work either. > > > > > -- > Joel Konkle-Parker > Webmaster [Ballsome.com] > > E-mail [jj...@ms...] This is exactly the type of error I've seen with attempts to compile ANY UML kernel on my recent LinuxFromScratch machines. A bunch of us on the LFS lists tried for a long time to debug the problem to no avail, however, one was able to get a UML kernel built with a private version of glibc with linuxthreads installed elsewhere on the system (we used /opt). I suspect there's something in the UML code that's causing symbol conflicts with newer glibc sources...something that the major distro's like Fedora are resolving for themselves, but I don't know for sure. However, I'd be willing to assist anyone in trying to resolve this, down to giving a user shell on a system that is affected by the problem. Jeremy Utley Editor, LinuxFromScratch project |
From: BlaisorBlade <bla...@ya...> - 2004-10-04 19:06:24
|
On Monday 04 October 2004 12:15, Jeremy Utley wrote: > On Sun, 03 Oct 2004 14:17:51 -0500, Joel Konkle-Parker <jj...@ms...> wrote: > > Peter Hummel wrote: > > > Joel Konkle-Parker schrieb: > > >> BlaisorBlade wrote: > This is exactly the type of error I've seen with attempts to compile > ANY UML kernel on my recent LinuxFromScratch machines. A bunch of us > on the LFS lists tried for a long time to debug the problem to no > avail, however, one was able to get a UML kernel built with a private > version of glibc with linuxthreads installed elsewhere on the system > (we used /opt). > I suspect there's something in the UML code that's causing symbol > conflicts with newer glibc sources...something that the major distro's > like Fedora are resolving for themselves, but I don't know for sure. > However, I'd be willing to assist anyone in trying to resolve this, > down to giving a user shell on a system that is affected by the > problem. Ok, thanks a lot, I start understanding the problem (I don't need the shell, I'm experiencing it here too, even if it's silent). lib/string.o should not contain any function definition, actually. This means that with newer glibcs, the NPTL code requires to link with some str* functions (this does not happen here). And, also, that you must apply this patch to fix the conflict (if the patch does not apply, try adding -l): diff -puN include/asm-um/string.h~uml-use-glibc-str-func include/asm-um/string.h --- linux-2.6.9-current/include/asm-um/string.h~uml-use-glibc-str-func 2004-10-04 20:58:08.000000000 +0200 +++ linux-2.6.9-current-paolo/include/asm-um/string.h 2004-10-04 21:01:37.000000000 +0200 @@ -4,4 +4,30 @@ #include "asm/arch/string.h" #include "asm/archparam.h" +#define __HAVE_ARCH_STRNICMP +#define __HAVE_ARCH_STRCPY +#define __HAVE_ARCH_STRNCPY +#define __HAVE_ARCH_STRLCPY +#define __HAVE_ARCH_STRCAT +#define __HAVE_ARCH_STRNCAT +#define __HAVE_ARCH_STRLCAT +#define __HAVE_ARCH_STRCMP +#define __HAVE_ARCH_STRNCMP +#define __HAVE_ARCH_STRCHR +#define __HAVE_ARCH_STRRCHR +#define __HAVE_ARCH_STRNCHR +#define __HAVE_ARCH_STRLEN +#define __HAVE_ARCH_STRNLEN +#define __HAVE_ARCH_STRSPN +#define __HAVE_ARCH_STRPBRK +#define __HAVE_ARCH_STRSEP +#define __HAVE_ARCH_MEMSET +#define __HAVE_ARCH_BCOPY +#define __HAVE_ARCH_MEMCPY +#define __HAVE_ARCH_MEMMOVE +#define __HAVE_ARCH_MEMCMP +#define __HAVE_ARCH_MEMSCAN +#define __HAVE_ARCH_STRSTR +#define __HAVE_ARCH_MEMCHR + #endif Bye -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: BlaisorBlade <bla...@ya...> - 2004-10-05 17:46:00
|
On Monday 04 October 2004 12:15, Jeremy Utley wrote: > On Sun, 03 Oct 2004 14:17:51 -0500, Joel Konkle-Parker <jj...@ms...> wrote: > This is exactly the type of error I've seen with attempts to compile > ANY UML kernel on my recent LinuxFromScratch machines. A bunch of us > on the LFS lists tried for a long time to debug the problem to no > avail, however, one was able to get a UML kernel built with a private > version of glibc with linuxthreads installed elsewhere on the system > (we used /opt). > I suspect there's something in the UML code that's causing symbol > conflicts with newer glibc sources...something that the major distro's > like Fedora are resolving for themselves, but I don't know for sure. I've read that glibc-2.3.3 has been released in a strange way. Patrick Volkerding from Slackware says that probably nobody will release the official glibc 2.3.3 tarball: http://www.slackware.com/changelog/current.php?cpu=i386 This probably explains the difference with what you call "major distros". In fact, by accident, I run a 2.3.3 glibc (the Mandrake 10.0 official revision). > However, I'd be willing to assist anyone in trying to resolve this, > down to giving a user shell on a system that is affected by the > problem. > > Jeremy Utley > Editor, LinuxFromScratch project Hmm, I don't want to flame, but what is the reason for not posting this here? I hope we don't bite, and if we do, I'm very sorry. The bug is due to the fact that arch/um/kernel/tt/unmap_fin.o must be linked statically (see arch/um/kernel/tt/Makefile) and to the fact that the Linux kernel defines its own string function. Also, if you look at the code for arch/um/kernel/tt/unmap.c, you see that it does not use any str* function. But the object file, with nm, gives this: paolo $ nm arch/um/kernel/tt/unmap_fin.o 00000000 B errno 00000000 B _errno 000000c0 W __errno_location 00000130 T __libc_disable_asynccancel 000000f0 T __libc_enable_asynccancel 00000004 B __libc_multiple_threads 00000130 T __librt_disable_asynccancel 000000f0 T __librt_enable_asynccancel 00000004 B __librt_multiple_threads 00000060 W mmap 00000060 T __mmap 00000080 W munmap 00000080 T __munmap w __pthread_do_exit w __pthread_thread_self 00000000 T switcheroo 000000a0 T __syscall_error 000000a2 T __syscall_error_1 As you see, the mmap definition needs some librt functions, which are thread-related. So I'm not surprised that using LinuxThreads worked around the problem. Bye -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Joel Konkle-P. <jj...@ms...> - 2004-10-05 03:03:25
|
BlaisorBlade wrote: > Ok, thanks a lot, I start understanding the problem (I don't need the shell, > I'm experiencing it here too, even if it's silent). lib/string.o should not > contain any function definition, actually. > > This means that with newer glibcs, the NPTL code requires to link with some > str* functions (this does not happen here). > > And, also, that you must apply this patch to fix the conflict (if the patch > does not apply, try adding -l): Here's my new string.h: -- $ cat /usr/src/uml/linux/include/asm-um/string.h #ifndef __UM_STRING_H #define __UM_STRING_H #include "asm/arch/string.h" #include "asm/archparam.h" #define __HAVE_ARCH_STRNICMP #define __HAVE_ARCH_STRCPY #define __HAVE_ARCH_STRNCPY #define __HAVE_ARCH_STRLCPY #define __HAVE_ARCH_STRCAT #define __HAVE_ARCH_STRNCAT #define __HAVE_ARCH_STRLCAT #define __HAVE_ARCH_STRCMP #define __HAVE_ARCH_STRNCMP #define __HAVE_ARCH_STRCHR #define __HAVE_ARCH_STRRCHR #define __HAVE_ARCH_STRNCHR #define __HAVE_ARCH_STRLEN #define __HAVE_ARCH_STRNLEN #define __HAVE_ARCH_STRSPN #define __HAVE_ARCH_STRPBRK #define __HAVE_ARCH_STRSEP #define __HAVE_ARCH_MEMSET #define __HAVE_ARCH_BCOPY #define __HAVE_ARCH_MEMCPY #define __HAVE_ARCH_MEMMOVE #define __HAVE_ARCH_MEMCMP #define __HAVE_ARCH_MEMSCAN #define __HAVE_ARCH_STRSTR #define __HAVE_ARCH_MEMCHR #endif $ -- Here's what happened: -- # make linux ARCH=um [...] gcc -Wl,-T,arch/um/uml.lds.s -static -Wl,--wrap,malloc -Wl,--wrap,free -Wl,--wrap,calloc \ -o linux arch/um/main.o vmlinux -L/usr/lib -lutil vmlinux(.text+0xf9780): In function `sscanf': lib/vsprintf.c:836: multiple definition of `sscanf' arch/um/kernel/tt/unmap_fin.o(.text+0x31e74): first defined here /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bin/ld: BFD 2.14.90.0.8 20040114 assertion fail elf.c:3465 vmlinux(.text+0x42b96): In function `kallsyms_lookup_name': kernel/kallsyms.c:50: undefined reference to `strlcpy' vmlinux(.text+0x42ee4): In function `get_ksymbol_core': kernel/kallsyms.c:177: undefined reference to `strlcpy' vmlinux(.text+0x436a9): In function `do_acct_process': kernel/acct.c:402: undefined reference to `strlcpy' vmlinux(.text+0x6706b): In function `sget': fs/super.c:284: undefined reference to `strlcpy' vmlinux(.text+0x67862): In function `get_sb_bdev': fs/super.c:670: undefined reference to `strlcpy' vmlinux(.text+0x8701c):fs/binfmt_misc.c:122: more undefined references to `strlcpy' follow vmlinux(.text+0xd70c0): In function `vfat_valid_longname': fs/vfat/namei.c:245: undefined reference to `strnicmp' vmlinux(.text+0xd70ea):fs/vfat/namei.c:247: undefined reference to `strnicmp' vmlinux(.text+0xd710a):fs/vfat/namei.c:236: undefined reference to `strnicmp' vmlinux(.text+0xd7128):fs/vfat/namei.c:236: undefined reference to `strnicmp' vmlinux(.text+0xd7146):fs/vfat/namei.c:236: undefined reference to `strnicmp' vmlinux(.text+0xd7164):fs/vfat/namei.c:236: more undefined references to `strnicmp' follow vmlinux(.text+0x108189): In function `class_device_rename': drivers/base/class.c:442: undefined reference to `strlcpy' vmlinux(.text+0x108815): In function `platform_device_register': drivers/base/platform.c:101: undefined reference to `strlcpy' vmlinux(.text+0x1090f9): In function `dma_pool_create': drivers/base/dmapool.c:133: undefined reference to `strlcpy' vmlinux(.text+0x10efc7): In function `register_blkdev': drivers/block/genhd.c:92: undefined reference to `strlcpy' vmlinux(.text+0x12e1e9): In function `dev_alloc_name': net/core/dev.c:732: undefined reference to `strnchr' vmlinux(.text+0x12e2fb):net/core/dev.c:765: undefined reference to `strlcpy' vmlinux(.text+0x12e506): In function `dev_change_name': net/core/dev.c:806: undefined reference to `strlcpy' vmlinux(.text+0x1381c3): In function `netdev_register_sysfs': net/core/net-sysfs.c:413: undefined reference to `strlcpy' vmlinux(.text+0x163f14): In function `arp_req_get': net/ipv4/arp.c:1049: undefined reference to `strlcpy' vmlinux(.text+0x1726ea): In function `packet_rcv_spkt': net/packet/af_packet.c:282: undefined reference to `strlcpy' vmlinux(.text+0x17377a):net/packet/af_packet.c:910: more undefined references to `strlcpy' follow collect2: ld returned 1 exit status make: *** [linux] Error 1 # -- Any suggestions? -- Joel Konkle-Parker Webmaster [Ballsome.com] E-mail [jj...@ms...] |
From: Jeremy U. <jer...@gm...> - 2004-10-05 08:12:39
|
On Mon, 04 Oct 2004 22:03:08 -0500, Joel Konkle-Parker <jj...@ms...> wrote: > > Here's what happened: > > -- > # make linux ARCH=um > [...] > gcc -Wl,-T,arch/um/uml.lds.s -static -Wl,--wrap,malloc -Wl,--wrap,free > -Wl,--wrap,calloc \ > -o linux arch/um/main.o vmlinux -L/usr/lib -lutil > vmlinux(.text+0xf9780): In function `sscanf': > lib/vsprintf.c:836: multiple definition of `sscanf' > arch/um/kernel/tt/unmap_fin.o(.text+0x31e74): first defined here > /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bin/ld: > BFD 2.14.90.0.8 20040114 assertion fail elf.c:3465 > vmlinux(.text+0x42b96): In function `kallsyms_lookup_name': > kernel/kallsyms.c:50: undefined reference to `strlcpy' > vmlinux(.text+0x42ee4): In function `get_ksymbol_core': > kernel/kallsyms.c:177: undefined reference to `strlcpy' > vmlinux(.text+0x436a9): In function `do_acct_process': > kernel/acct.c:402: undefined reference to `strlcpy' > vmlinux(.text+0x6706b): In function `sget': > fs/super.c:284: undefined reference to `strlcpy' > vmlinux(.text+0x67862): In function `get_sb_bdev': > fs/super.c:670: undefined reference to `strlcpy' > vmlinux(.text+0x8701c):fs/binfmt_misc.c:122: more undefined references > to `strlcpy' follow > vmlinux(.text+0xd70c0): In function `vfat_valid_longname': > fs/vfat/namei.c:245: undefined reference to `strnicmp' > vmlinux(.text+0xd70ea):fs/vfat/namei.c:247: undefined reference to > `strnicmp' > vmlinux(.text+0xd710a):fs/vfat/namei.c:236: undefined reference to > `strnicmp' > vmlinux(.text+0xd7128):fs/vfat/namei.c:236: undefined reference to > `strnicmp' > vmlinux(.text+0xd7146):fs/vfat/namei.c:236: undefined reference to > `strnicmp' > vmlinux(.text+0xd7164):fs/vfat/namei.c:236: more undefined references to > `strnicmp' follow > vmlinux(.text+0x108189): In function `class_device_rename': > drivers/base/class.c:442: undefined reference to `strlcpy' > vmlinux(.text+0x108815): In function `platform_device_register': > drivers/base/platform.c:101: undefined reference to `strlcpy' > vmlinux(.text+0x1090f9): In function `dma_pool_create': > drivers/base/dmapool.c:133: undefined reference to `strlcpy' > vmlinux(.text+0x10efc7): In function `register_blkdev': > drivers/block/genhd.c:92: undefined reference to `strlcpy' > vmlinux(.text+0x12e1e9): In function `dev_alloc_name': > net/core/dev.c:732: undefined reference to `strnchr' > vmlinux(.text+0x12e2fb):net/core/dev.c:765: undefined reference to `strlcpy' > vmlinux(.text+0x12e506): In function `dev_change_name': > net/core/dev.c:806: undefined reference to `strlcpy' > vmlinux(.text+0x1381c3): In function `netdev_register_sysfs': > net/core/net-sysfs.c:413: undefined reference to `strlcpy' > vmlinux(.text+0x163f14): In function `arp_req_get': > net/ipv4/arp.c:1049: undefined reference to `strlcpy' > vmlinux(.text+0x1726ea): In function `packet_rcv_spkt': > net/packet/af_packet.c:282: undefined reference to `strlcpy' > vmlinux(.text+0x17377a):net/packet/af_packet.c:910: more undefined > references to `strlcpy' follow > collect2: ld returned 1 exit status > make: *** [linux] Error 1 > # > -- > > Any suggestions? > No Suggestion, but I can definately duplicate what Joel encountered with the patch provided by BlaisorBlade. I would like to also note that this only occurs when TT mode is enabled. When only SKAS is enabled for the UML kernel, the compile will complete, but will segfault immediately on running. That might be why BlaisorBlade never sees this, as if I'm not mistaken, he uses only SKAS mode. Jeremy |
From: BlaisorBlade <bla...@ya...> - 2004-10-05 17:47:02
|
On Tuesday 05 October 2004 10:12, Jeremy Utley wrote: > On Mon, 04 Oct 2004 22:03:08 -0500, Joel Konkle-Parker <jj...@ms...> wrote: > > Here's what happened: > > -- > > # make linux ARCH=um > > [...] > > gcc -Wl,-T,arch/um/uml.lds.s -static -Wl,--wrap,malloc -Wl,--wrap,free > > -Wl,--wrap,calloc \ > > -o linux arch/um/main.o vmlinux -L/usr/lib -lutil > > vmlinux(.text+0xf9780): In function `sscanf': > > lib/vsprintf.c:836: multiple definition of `sscanf' > > arch/um/kernel/tt/unmap_fin.o(.text+0x31e74): first defined here > > /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bi > > vmlinux(.text+0xd70c0): In function `vfat_valid_longname': > > fs/vfat/namei.c:245: undefined reference to `strnicmp' > > vmlinux(.text+0xd7164):fs/vfat/namei.c:236: more undefined references to > > `strnicmp' follow > > drivers/block/genhd.c:92: undefined reference to `strlcpy' > > net/core/dev.c:732: undefined reference to `strnchr' > > Any suggestions? > No Suggestion, but I can definately duplicate what Joel encountered > with the patch provided by BlaisorBlade. I would like to also note > that this only occurs when TT mode is enabled. When only SKAS is > enabled for the UML kernel, the compile will complete, but will > segfault immediately on running. That might be why BlaisorBlade never > sees this, as if I'm not mistaken, he uses only SKAS mode. I always compile both TT and SKAS mode in... the patch was, indeed, not well tested (I hadn't the time). The reason I don't see this is some glibc change... And the reason the patch does not work is that some functions are not defined inside glibc. However, I'm looking at this more in detail now. This is the 2nd revision of the patch (I've removed the __HAVE_ARCH_ definitions matching kernel-only functions, so that lib/string.c defines them). It links and runs on my system fine, and I think should link on yours, too. By comparison, I am almost sure that the 1st version would not have linked even on my system, because glibc does not define strlcpy() by sure, at least; it does not even define strnicmp (it's called strncasecmp IIRC). diff -puN include/asm-um/string.h~uml-use-glibc-str-func include/asm-um/string.h --- linux-2.6.9-current/include/asm-um/string.h~uml-use-glibc-str-func 2004-10-05 18:27:47.046946784 +0200 +++ linux-2.6.9-current-paolo/include/asm-um/string.h 2004-10-05 19:22:12.347545640 +0200 @@ -4,4 +4,25 @@ #include "asm/arch/string.h" #include "asm/archparam.h" +#define __HAVE_ARCH_STRCPY +#define __HAVE_ARCH_STRNCPY +#define __HAVE_ARCH_STRCAT +#define __HAVE_ARCH_STRNCAT +#define __HAVE_ARCH_STRCMP +#define __HAVE_ARCH_STRNCMP +#define __HAVE_ARCH_STRCHR +#define __HAVE_ARCH_STRRCHR +#define __HAVE_ARCH_STRLEN +#define __HAVE_ARCH_STRNLEN +#define __HAVE_ARCH_STRSPN +#define __HAVE_ARCH_STRPBRK +#define __HAVE_ARCH_STRSEP +#define __HAVE_ARCH_MEMSET +#define __HAVE_ARCH_BCOPY +#define __HAVE_ARCH_MEMCPY +#define __HAVE_ARCH_MEMMOVE +#define __HAVE_ARCH_MEMCMP +#define __HAVE_ARCH_STRSTR +#define __HAVE_ARCH_MEMCHR + #endif diff -puN lib/vsprintf.c~uml-use-glibc-str-func lib/vsprintf.c --- linux-2.6.9-current/lib/vsprintf.c~uml-use-glibc-str-func 2004-10-05 19:26:11.749151064 +0200 +++ linux-2.6.9-current-paolo/lib/vsprintf.c 2004-10-05 19:26:24.593198472 +0200 @@ -826,6 +826,7 @@ int vsscanf(const char * buf, const char EXPORT_SYMBOL(vsscanf); +#if 0 /** * sscanf - Unformat a buffer into a list of arguments * @buf: input buffer @@ -842,5 +843,6 @@ int sscanf(const char * buf, const char va_end(args); return i; } +#endif EXPORT_SYMBOL(sscanf); Bye -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Joel Konkle-P. <jj...@ms...> - 2004-10-06 05:24:24
|
BlaisorBlade wrote: > diff -puN include/asm-um/string.h~uml-use-glibc-str-func > include/asm-um/string.h > --- linux-2.6.9-current/include/asm-um/string.h~uml-use-glibc-str-func > 2004-10-05 18:27:47.046946784 +0200 > +++ linux-2.6.9-current-paolo/include/asm-um/string.h 2004-10-05 > 19:22:12.347545640 +0200 > @@ -4,4 +4,25 @@ > #include "asm/arch/string.h" > #include "asm/archparam.h" > > +#define __HAVE_ARCH_STRCPY > +#define __HAVE_ARCH_STRNCPY > +#define __HAVE_ARCH_STRCAT > +#define __HAVE_ARCH_STRNCAT > +#define __HAVE_ARCH_STRCMP > +#define __HAVE_ARCH_STRNCMP > +#define __HAVE_ARCH_STRCHR > +#define __HAVE_ARCH_STRRCHR > +#define __HAVE_ARCH_STRLEN > +#define __HAVE_ARCH_STRNLEN > +#define __HAVE_ARCH_STRSPN > +#define __HAVE_ARCH_STRPBRK > +#define __HAVE_ARCH_STRSEP > +#define __HAVE_ARCH_MEMSET > +#define __HAVE_ARCH_BCOPY > +#define __HAVE_ARCH_MEMCPY > +#define __HAVE_ARCH_MEMMOVE > +#define __HAVE_ARCH_MEMCMP > +#define __HAVE_ARCH_STRSTR > +#define __HAVE_ARCH_MEMCHR > + > #endif > diff -puN lib/vsprintf.c~uml-use-glibc-str-func lib/vsprintf.c > --- linux-2.6.9-current/lib/vsprintf.c~uml-use-glibc-str-func 2004-10-05 > 19:26:11.749151064 +0200 > +++ linux-2.6.9-current-paolo/lib/vsprintf.c 2004-10-05 19:26:24.593198472 > +0200 > @@ -826,6 +826,7 @@ int vsscanf(const char * buf, const char > > EXPORT_SYMBOL(vsscanf); > > +#if 0 > /** > * sscanf - Unformat a buffer into a list of arguments > * @buf: input buffer > @@ -842,5 +843,6 @@ int sscanf(const char * buf, const char > va_end(args); > return i; > } > +#endif > > EXPORT_SYMBOL(sscanf); As an aside, what's the step-by-step procedure for applying these patches? Copy each to a file, run 'patch -p1 <file', something like that? -- Joel Konkle-Parker Webmaster [Ballsome.com] E-mail [jj...@ms...] |
From: Joel Konkle-P. <jj...@ms...> - 2004-10-07 05:32:31
|
Joel Konkle-Parker wrote: > As an aside, what's the step-by-step procedure for applying these > patches? Copy each to a file, run 'patch -p1 <file', something like that? Nevermind, I got it. I just copied both patches to a file and did 'cat file | patch -p1'. -- Joel Konkle-Parker Webmaster [Ballsome.com] E-mail [jj...@ms...] |
From: Jeremy U. <jer...@gm...> - 2004-10-06 08:08:04
|
On Tue, 5 Oct 2004 19:46:04 +0200, BlaisorBlade <bla...@ya...> wrote: > > > On Tuesday 05 October 2004 10:12, Jeremy Utley wrote: > > On Mon, 04 Oct 2004 22:03:08 -0500, Joel Konkle-Parker <jj...@ms...> > wrote: > > > Here's what happened: > > > > -- > > > # make linux ARCH=um > > > [...] > > > gcc -Wl,-T,arch/um/uml.lds.s -static -Wl,--wrap,malloc -Wl,--wrap,free > > > -Wl,--wrap,calloc \ > > > -o linux arch/um/main.o vmlinux -L/usr/lib -lutil > > > > vmlinux(.text+0xf9780): In function `sscanf': > > > lib/vsprintf.c:836: multiple definition of `sscanf' > > > > arch/um/kernel/tt/unmap_fin.o(.text+0x31e74): first defined here > > > > /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bi > > > > vmlinux(.text+0xd70c0): In function `vfat_valid_longname': > > > fs/vfat/namei.c:245: undefined reference to `strnicmp' > > > > vmlinux(.text+0xd7164):fs/vfat/namei.c:236: more undefined references to > > > `strnicmp' follow > > > > drivers/block/genhd.c:92: undefined reference to `strlcpy' > > > > net/core/dev.c:732: undefined reference to `strnchr' > > > > Any suggestions? > > > No Suggestion, but I can definately duplicate what Joel encountered > > with the patch provided by BlaisorBlade. I would like to also note > > that this only occurs when TT mode is enabled. When only SKAS is > > enabled for the UML kernel, the compile will complete, but will > > segfault immediately on running. That might be why BlaisorBlade never > > sees this, as if I'm not mistaken, he uses only SKAS mode. > > I always compile both TT and SKAS mode in... the patch was, indeed, not well > tested (I hadn't the time). The reason I don't see this is some glibc > change... And the reason the patch does not work is that some functions are > not defined inside glibc. > > However, I'm looking at this more in detail now. This is the 2nd revision of > the patch (I've removed the __HAVE_ARCH_ definitions matching kernel-only > functions, so that lib/string.c defines them). It links and runs on my system > fine, and I think should link on yours, too. By comparison, I am almost sure > that the 1st version would not have linked even on my system, because glibc > does not define strlcpy() by sure, at least; it does not even define strnicmp > (it's called strncasecmp IIRC). > > diff -puN include/asm-um/string.h~uml-use-glibc-str-func > include/asm-um/string.h > --- linux-2.6.9-current/include/asm-um/string.h~uml-use-glibc-str-func > 2004-10-05 18:27:47.046946784 +0200 > +++ linux-2.6.9-current-paolo/include/asm-um/string.h 2004-10-05 > 19:22:12.347545640 +0200 > @@ -4,4 +4,25 @@ > #include "asm/arch/string.h" > #include "asm/archparam.h" > > +#define __HAVE_ARCH_STRCPY > +#define __HAVE_ARCH_STRNCPY > +#define __HAVE_ARCH_STRCAT > +#define __HAVE_ARCH_STRNCAT > +#define __HAVE_ARCH_STRCMP > +#define __HAVE_ARCH_STRNCMP > +#define __HAVE_ARCH_STRCHR > +#define __HAVE_ARCH_STRRCHR > +#define __HAVE_ARCH_STRLEN > +#define __HAVE_ARCH_STRNLEN > +#define __HAVE_ARCH_STRSPN > +#define __HAVE_ARCH_STRPBRK > +#define __HAVE_ARCH_STRSEP > +#define __HAVE_ARCH_MEMSET > +#define __HAVE_ARCH_BCOPY > +#define __HAVE_ARCH_MEMCPY > +#define __HAVE_ARCH_MEMMOVE > +#define __HAVE_ARCH_MEMCMP > +#define __HAVE_ARCH_STRSTR > +#define __HAVE_ARCH_MEMCHR > + > #endif > diff -puN lib/vsprintf.c~uml-use-glibc-str-func lib/vsprintf.c > --- linux-2.6.9-current/lib/vsprintf.c~uml-use-glibc-str-func 2004-10-05 > 19:26:11.749151064 +0200 > +++ linux-2.6.9-current-paolo/lib/vsprintf.c 2004-10-05 19:26:24.593198472 > +0200 > @@ -826,6 +826,7 @@ int vsscanf(const char * buf, const char > > EXPORT_SYMBOL(vsscanf); > > +#if 0 > /** > * sscanf - Unformat a buffer into a list of arguments > * @buf: input buffer > @@ -842,5 +843,6 @@ int sscanf(const char * buf, const char > va_end(args); > return i; > } > +#endif > > EXPORT_SYMBOL(sscanf); OK, this gets us closer, but not quite there yet, at least on my system. This resolves the string symbol errors, but we're still left with an assertion fail coming from ld at the end of the compile process: gcc -Wl,-T,arch/um/uml.lds.s -static -Wl,--wrap,malloc -Wl,--wrap,free -Wl,--wrap,calloc \ -o linux arch/um/main.o vmlinux -L/usr/lib -lutil /usr/bin/ld: BFD 2.15.92.0.2 20040927 assertion fail ../../binutils-2.15.92.0.2/bfd/elf.c:3633 The linux binary is created, but when run, generates an immediate segfault: jeremy@vulcan ~/linux-2.6.8.1> ./linux Segmentation fault I'll go ahead and outline the toolchain in use here on my system currently: GCC version 3.4.2 Glibc CVS pull from 2004-08-01 HJ Lu's binutils branch 2.15.92.0.2 This toolchain has built some 300-odd packages outside UML, with minimal need for alteration of source, and also passes the testsuites as it should, so it looks like we still have a incompatibility between UML and a NPTL-enabled glibc. Jeremy |
From: Joel Konkle-P. <jj...@ms...> - 2004-10-07 05:46:13
|
Jeremy Utley wrote: > OK, this gets us closer, but not quite there yet, at least on my > system. This resolves the string symbol errors, but we're still left > with an assertion fail coming from ld at the end of the compile > process: > > gcc -Wl,-T,arch/um/uml.lds.s -static -Wl,--wrap,malloc -Wl,--wrap,free > -Wl,--wrap,calloc \ > -o linux arch/um/main.o vmlinux -L/usr/lib -lutil > /usr/bin/ld: BFD 2.15.92.0.2 20040927 assertion fail > ../../binutils-2.15.92.0.2/bfd/elf.c:3633 > > > The linux binary is created, but when run, generates an immediate segfault: > > jeremy@vulcan ~/linux-2.6.8.1> ./linux > Segmentation fault Yes, I'm seeing this also: gcc -Wl,-T,arch/um/uml.lds.s -static -Wl,--wrap,malloc -Wl,--wrap,free -Wl,--wrap,calloc \ -o linux arch/um/main.o vmlinux -L/usr/lib -lutil /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bin/ld: BFD 2.14.90.0.8 20040114 assertion fail elf.c:3465 # ./linux Segmentation fault (core dumped) # gdb linux core GNU gdb 6.0 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 "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". Core was generated by `./linux'. Program terminated with signal 11, Segmentation fault. #0 0xa00024f6 in ptmalloc_init () (gdb) bt #0 0xa00024f6 in ptmalloc_init () #1 0xa0002cc2 in malloc_hook_ini () #2 0xa0004039 in malloc () #3 0xa0007ae3 in _dl_init_paths () #4 0x00000020 in ?? () #5 0xbffff048 in ?? () #6 0xa000f7ba in __libc_setup_tls () Previous frame inner to this frame (corrupt stack?) (gdb) q # > I'll go ahead and outline the toolchain in use here on my system currently: > > GCC version 3.4.2 > Glibc CVS pull from 2004-08-01 > HJ Lu's binutils branch 2.15.92.0.2 > > This toolchain has built some 300-odd packages outside UML, with > minimal need for alteration of source, and also passes the testsuites > as it should, so it looks like we still have a incompatibility between > UML and a NPTL-enabled glibc. I have a less exotic toolchain: gcc (GCC) 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6) glibc-2.3.3-20040420 # /lib/libc-2.3.3.so GNU C Library stable release version 2.3.3, by Roland McGrath et al. Copyright (C) 2004 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 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6). Compiled on a Linux 2.6.7-gentoo-r11 system on 2004-08-10. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others NPTL 0.61 by Ulrich Drepper BIND-8.2.3-T5B NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Thread-local storage support included. binutils-2.14.90.0.8-r1 -- Joel Konkle-Parker Webmaster [Ballsome.com] E-mail [jj...@ms...] |