Re: libc dlopening libgcc on arm

2007-05-31 Thread Daniel Jacobowitz
On Wed, May 30, 2007 at 11:49:54AM +0200, Bastian Blank wrote: On Wed, May 30, 2007 at 11:31:35AM +0200, Bastian Blank wrote: On Wed, May 30, 2007 at 11:19:38AM +0200, Aurelien Jarno wrote: What I don't understand is why /sbin/init on arm now uses threads? It is /bin/sh, which should be

Re: libc dlopening libgcc on arm

2007-05-31 Thread Bastian Blank
On Wed, May 30, 2007 at 10:30:05AM +0200, Bastian Blank wrote: D-I may be also affected and mklibs needs to pull in libgcc_s.so.1 always if it catches a glibc. The attached mklibs patch always adds libgcc for old-abi arm. Bastian -- Well, Jim, I'm not much of an actor either. Index:

Re: libc dlopening libgcc on arm

2007-05-30 Thread Aurelien Jarno
Joey Hess a écrit : Just spent half an hour since my slug wouldn't boot and I had to reflash an old initramfs. This bug should be fixed ASAP before it breaks a lot of systems. [EMAIL PROTECTED]:/tmp/initramfsmkinitramfs -o out -k Working files in /root/tmp/mkinitramfs_tj3082 and overlay in

Re: libc dlopening libgcc on arm

2007-05-30 Thread Aurelien Jarno
Aurelien Jarno a écrit : Joey Hess a écrit : Just spent half an hour since my slug wouldn't boot and I had to reflash an old initramfs. This bug should be fixed ASAP before it breaks a lot of systems. [EMAIL PROTECTED]:/tmp/initramfsmkinitramfs -o out -k Working files in

Re: libc dlopening libgcc on arm

2007-05-30 Thread Bastian Blank
On Wed, May 30, 2007 at 09:27:10AM +0200, Aurelien Jarno wrote: The same code is also present on glibc 2.3.6 for nptl builds. So at least amd64 is using it in etch for the initrd. Yes. But it is only used sometimes. This code is located in libpthread and consist of direct wrappers around

Re: libc dlopening libgcc on arm

2007-05-30 Thread Bastian Blank
On Wed, May 30, 2007 at 10:30:05AM +0200, Bastian Blank wrote: This code is located in libpthread and consist of direct wrappers around libgcc functions. Isn't it possible to just correctly link against libgcc instead of this dlopen stunt? As libgcc needs libc, it is not possible to do that

Re: libc dlopening libgcc on arm

2007-05-30 Thread Aurelien Jarno
Bastian Blank a écrit : On Wed, May 30, 2007 at 10:30:05AM +0200, Bastian Blank wrote: This code is located in libpthread and consist of direct wrappers around libgcc functions. Isn't it possible to just correctly link against libgcc instead of this dlopen stunt? As libgcc needs libc, it is

Re: libc dlopening libgcc on arm

2007-05-30 Thread Bastian Blank
On Wed, May 30, 2007 at 11:19:38AM +0200, Aurelien Jarno wrote: What I don't understand is why /sbin/init on arm now uses threads? It is /bin/sh, which should be busybox. It is clear that we miss a dependency on libgcc1/libgcc2/libgcc4, but unfortunately I am not sure there is another way to

Re: libc dlopening libgcc on arm

2007-05-30 Thread Bastian Blank
On Wed, May 30, 2007 at 11:31:35AM +0200, Bastian Blank wrote: On Wed, May 30, 2007 at 11:19:38AM +0200, Aurelien Jarno wrote: What I don't understand is why /sbin/init on arm now uses threads? It is /bin/sh, which should be busybox. And it does not use pthread at all. It may be usefull to

libc dlopening libgcc on arm

2007-05-28 Thread Joey Hess
Just spent half an hour since my slug wouldn't boot and I had to reflash an old initramfs. This bug should be fixed ASAP before it breaks a lot of systems. [EMAIL PROTECTED]:/tmp/initramfsmkinitramfs -o out -k Working files in /root/tmp/mkinitramfs_tj3082 and overlay in