c't

c't-Projekte - Mailinglisten


[Voriger (Datum)] [Nächster (Datum)] [Voriger (Thread)] [Nächster (Thread)]
[Nach Datum][Nach Thread]

Re: [ctsrvdev] Ipcop innerhalb der ipcop-umgebung bauen

Absender: Peter Siering
Datum: Mo, 19.12.2005 10:03:30
In-reply-to: <000401c60405$4b851bc0$0801a8c0@Nia>
References: <000401c60405$4b851bc0$0801a8c0@Nia>


Hallo,

On Sun, 18 Dec 2005, Jens Friedrich wrote:

> ich habe mal nach Peters Methode versucht, den IPCop 1.4.10 mit dem
> uml-linux-2.4.31-bs2-wanninger-patch
> zu bauen. Das geht bis zu dem gleichen Problem gut, weshalb ich bei V 1.4.9
> - wie in meinemHowTo beschrieben -
> den uml-ipcop-kernel ausserhalb der der LFS-Umgebung des ipcop bauen musste,
> da fehler beim zusammenbauen von vmlinuz.o und linux zum abbruch führen.
>
> @Peter: Gab's dieses Problem bei V1.4.6 nicht?
> Wenn ich in diesem Zustand den kompletten Tree aus der LFS auf den
> Standard-Sarge-Server kopiere und kompiliere, läufts durch!
> Any Comments?
>
> Aus dem logfile:
> nm vmlinux | grep -v '\(compiled\)\|\(\.o$\)\|\( [aUw]
> \)\|\(\.\.ng$\)\|\(LASH[RL]DI\)' | sort > System.map
> pages=$(( 1 << 2 )) ; \
> m4 -DSTART=$((0xc0000000 - ((0 + 1) * 0x20000000))) -DELF_ARCH=i386 \
>         -DELF_FORMAT=elf32-i386 -DMODE_TT \
>         -DKERNEL_STACK_SIZE=$(( 4096 * $pages )) arch/um/link.ld.in >
> arch/um/link.ld
> mv vmlinux vmlinux.o
> ccache /usr/bin/gcc -Wl,-T,arch/um/link.ld -static -Wl,--wrap,malloc
> -Wl,--wrap,free -Wl,--wrap,calloc \
>         -o linux arch/um/main.o vmlinux.o -L/usr/lib -lutil
> vmlinux.o(.text+0xe8df8): In function `__stack_smash_handler':
> : multiple definition of `__stack_smash_handler'
> arch/um/kernel/tt/unmap_fin.o(.text+0x130):../sysdeps/unix/sysv/linux/stack_
> protector.c:116: first defined here
> /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.3/../../../../i386-pc-linux-gnu/bin/l
> d: Warning: size of symbol `__stack_smash_hand
> ler' changed from 642 in arch/um/kernel/tt/unmap_fin.o to 26 in vmlinux.o
> vmlinux.o(.data+0xd364): multiple definition of `__guard'
> arch/um/kernel/tt/unmap_fin.o(.bss+0x0):../sysdeps/generic/setenv.c:332:
> first defined here
> /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.3/../../../../i386-pc-linux-gnu/bin/l
> d: Warning: size of symbol `__guard' changed f
> rom 32 in arch/um/kernel/tt/unmap_fin.o to 4 in vmlinux.o
> vmlinux.o(.text+0xe87d4): In function `sscanf':
> : multiple definition of `sscanf'
> arch/um/kernel/tt/unmap_fin.o(.text+0x300d0):/usr/src/glibc-2.3.3-lfs-5.1/st
> dio-common/sscanf.c:31: first defined here
> /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.3/../../../../i386-pc-linux-gnu/bin/l
> d: Warning: size of symbol `sscanf' changed fr
> om 35 in arch/um/kernel/tt/unmap_fin.o to 26 in vmlinux.o
> vmlinux.o(.text+0xe7880): In function `strpbrk':
> : multiple definition of `strpbrk'
> arch/um/kernel/tt/unmap_fin.o(.text+0x32880):../sysdeps/i386/strpbrk.S:38:
> first defined here
> /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.3/../../../../i386-pc-linux-gnu/bin/l
> d: Warning: size of symbol `strpbrk' changed f
> rom 179 in arch/um/kernel/tt/unmap_fin.o to 67 in vmlinux.o
> collect2: ld returned 1 exit status
> make[1]: *** [linux] Error 1
> make[1]: Leaving directory `/usr/src/uml_linux-2.4.31'
>

sieht auf den ersten Blick nach dem typischen Problem aus: Sobald tt und
skas aktiv sind, klappt das Übersetzen mit aktivierten propolice/ stack
protection patches im Kernel nicht mehr. In den Patches, die ich parallel
zur Veröffentlichung des howtos bei uns auf den Server gespielt habe, sind
im Kernel-Makefile Optionen drin, die das ausschalten. Vermutlich spielt
das bei externem Übersetzen keine Geige, weil im Host-System die
propolice-Geschichten für den Linker nicht erreichbar sind.

Die eigentliche Ursache dafür habe ich nie gefunden ;-(

Gruß,
Peter