Re: static link with NPTL on ARM fails
On Sun, Jan 29, 2012 at 07:55:10PM +0100, Johannes Stezenbach wrote: On Sat, Jan 28, 2012 at 10:35:43PM +0100, Bernhard Reutner-Fischer wrote: Can you try attached two patches please? I built a new toolchain with these patches applied on top of current git (219aa9c), and built a statically linked iperf with it. That worked fine. I'll let you know tomorrow if the iperf also runs ;-) Yeah, iperf works. Thank you all for fixing this! Johannes ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: static link with NPTL on ARM fails
On Sat, Jan 28, 2012 at 10:35:43PM +0100, Bernhard Reutner-Fischer wrote: Can you try attached two patches please? I built a new toolchain with these patches applied on top of current git (219aa9c), and built a statically linked iperf with it. That worked fine. I'll let you know tomorrow if the iperf also runs ;-) Thanks Johannes ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: static link with NPTL on ARM fails
On Jan 27, 2012 5:02 PM, Carmelo AMOROSO carmelo.amor...@st.com wrote:
On 27/01/2012 16.54, Bernhard Reutner-Fischer wrote:
On Jan 27, 2012 4:47 PM, Carmelo AMOROSO carmelo.amor...@st.com
wrote:
So, to summarise I'd expect
libc.{so,a}
--- __libc_sigaction (global)
--- __GI_sigaction (hidden alias for internal use)
--- sigaction
a. A wrapper to __libc_sigaction (if NPTL configured)
b. A weak alias to __libc_sigaction (thread none)
I think that should be a strong alias if NO_THREADS.
indeed.. not expected to be overridden.
and nothing duplicated into libpthread.
make more sense ?
Yes.
:)
Can you try attached two patches please?
0001-buildsys-fixup-sigaction-handling.patch
Description:
0002-if-HAS_THREADS-strong-alias-sigaction.patch
Description:
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: static link with NPTL on ARM fails
On 26/01/2012 17.08, Johannes Stezenbach wrote: On Fri, Jan 13, 2012 at 10:38:57AM +0100, Carmelo AMOROSO wrote: On 16/12/2011 18.36, Johannes Stezenbach wrote: On Fri, Dec 16, 2011 at 05:59:16PM +0100, Carmelo Amoroso wrote: On 16/12/11 15:57, Johannes Stezenbach wrote: I was able to fix the issue like this: --- uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c.orig 2011-12-03 18:55:45.0 +0100 +++ uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c 2011-12-14 11:48:52.0 +0100 @@ -38,9 +38,9 @@ return __libc_sigaction (sig, act, oact); } -libc_hidden_proto(sigaction) +hidden_proto(sigaction) weak_alias (__sigaction, sigaction) -libc_hidden_weak(sigaction) +hidden_weak(sigaction) #else ... I have now some free time to look at pending patches. It's on my queue. I don't want to nag, but since I just had some time to work on my ARM toolchain crosstool-ng build I thought to let you know that with yesterday's git eb72efd this issue is still present. Johannes Hello, I don't think this fix is the best one; is rather a w/a. I'm reviewing the code as it seems we have a mess with sigaction symbols/aliased between libc and libpthread. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: static link with NPTL on ARM fails
On 27/01/2012 12.13, Carmelo AMOROSO wrote:
On 26/01/2012 17.08, Johannes Stezenbach wrote:
On Fri, Jan 13, 2012 at 10:38:57AM +0100, Carmelo AMOROSO wrote:
On 16/12/2011 18.36, Johannes Stezenbach wrote:
On Fri, Dec 16, 2011 at 05:59:16PM +0100, Carmelo Amoroso wrote:
On 16/12/11 15:57, Johannes Stezenbach wrote:
I was able to fix the issue like this:
--- uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c.orig
2011-12-03 18:55:45.0 +0100
+++ uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c
2011-12-14 11:48:52.0 +0100
@@ -38,9 +38,9 @@
return __libc_sigaction (sig, act, oact);
}
-libc_hidden_proto(sigaction)
+hidden_proto(sigaction)
weak_alias (__sigaction, sigaction)
-libc_hidden_weak(sigaction)
+hidden_weak(sigaction)
#else
...
I have now some free time to look at pending patches. It's on my queue.
I don't want to nag, but since I just had some time to work on my
ARM toolchain crosstool-ng build I thought to let you know that
with yesterday's git eb72efd this issue is still present.
Johannes
Hello,
I don't think this fix is the best one; is rather a w/a.
I'm reviewing the code as it seems we have a mess with sigaction
symbols/aliased between libc and libpthread.
Carmelo
Well,
what I'd expect to have for sigaction is:
libc.{so,a}
--- __libc_sigaction (global)
--- sigaction (weak alias of __libc_sigaction)
--- __GI_sigaction (hidden alias for internal use, if any)
and
libpthread.{so,a}
--- sigaction (global)
--- __libc_sigaction (undefined)
where the sigaction implementation in the libpthread should wrap around
the __libc_sigaction adding the extra check for the SIGCANCEL and SIGSETXID.
I would not expect to see, as we currently have, __libc_sigaction
reimplemented in the pthread library.
So rather then working around the static build issue, I'd prefer to tidy
things up, definitely.
Feedback are welcome.
Carmelo
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: static link with NPTL on ARM fails
On Fri, Jan 27, 2012 at 02:17:25PM +0100, Carmelo AMOROSO wrote:
Well,
what I'd expect to have for sigaction is:
libc.{so,a}
--- __libc_sigaction (global)
--- sigaction (weak alias of __libc_sigaction)
--- __GI_sigaction (hidden alias for internal use, if any)
and
libpthread.{so,a}
--- sigaction (global)
--- __libc_sigaction (undefined)
where the sigaction implementation in the libpthread should wrap around
the __libc_sigaction adding the extra check for the SIGCANCEL and SIGSETXID.
I would not expect to see, as we currently have, __libc_sigaction
reimplemented in the pthread library.
So rather then working around the static build issue, I'd prefer to tidy
things up, definitely.
Sounds good, but one question: When libc internally calls sigaction
and libpthread is also linked, which one should be called?
I would think it should call the pthread version. If libc wants
to call the libc version it would use __libc_sigaction explicitly.
However, with libc_hidden_proto(sigaction) in signal.h, libc
would end up calling __GI_sigaction which is the libc version, isn't it?
Instead there could be a __GI___libc_sigaction.
- libc_hidden_proto(sigaction)
+ libc_hidden_proto(__libc_sigaction)
Thanks
Johannes
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: static link with NPTL on ARM fails
On 27/01/2012 15.55, Johannes Stezenbach wrote:
On Fri, Jan 27, 2012 at 02:17:25PM +0100, Carmelo AMOROSO wrote:
Well,
what I'd expect to have for sigaction is:
libc.{so,a}
--- __libc_sigaction (global)
--- sigaction (weak alias of __libc_sigaction)
--- __GI_sigaction (hidden alias for internal use, if any)
and
libpthread.{so,a}
--- sigaction (global)
--- __libc_sigaction (undefined)
where the sigaction implementation in the libpthread should wrap around
the __libc_sigaction adding the extra check for the SIGCANCEL and SIGSETXID.
I would not expect to see, as we currently have, __libc_sigaction
reimplemented in the pthread library.
So rather then working around the static build issue, I'd prefer to tidy
things up, definitely.
Sounds good, but one question: When libc internally calls sigaction
and libpthread is also linked, which one should be called?
I would think it should call the pthread version.
frankly not sure. In the current implementation, when pthread are
enabled at build time (even if not used at runtime), the implementation
is taken from the pthread directory. So it should work as you expect.
Indeed, I'm thinking that there is not need at all to duplicate the
symbol into the pthread library, as the libc implementation is already
properly handling SIGCANCEL/SIGSETXID.
So, likely we should get rid of pt-sigaction.c... simply.
If libc wants
to call the libc version it would use __libc_sigaction explicitly.
However, with libc_hidden_proto(sigaction) in signal.h, libc
would end up calling __GI_sigaction which is the libc version, isn't it?
yes
Instead there could be a __GI___libc_sigaction.
- libc_hidden_proto(sigaction)
+ libc_hidden_proto(__libc_sigaction)
Thanks
Johannes
carmelo
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: static link with NPTL on ARM fails
On 27/01/2012 14.17, Carmelo AMOROSO wrote:
On 27/01/2012 12.13, Carmelo AMOROSO wrote:
On 26/01/2012 17.08, Johannes Stezenbach wrote:
On Fri, Jan 13, 2012 at 10:38:57AM +0100, Carmelo AMOROSO wrote:
On 16/12/2011 18.36, Johannes Stezenbach wrote:
On Fri, Dec 16, 2011 at 05:59:16PM +0100, Carmelo Amoroso wrote:
On 16/12/11 15:57, Johannes Stezenbach wrote:
I was able to fix the issue like this:
--- uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c.orig
2011-12-03 18:55:45.0 +0100
+++ uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c
2011-12-14 11:48:52.0 +0100
@@ -38,9 +38,9 @@
return __libc_sigaction (sig, act, oact);
}
-libc_hidden_proto(sigaction)
+hidden_proto(sigaction)
weak_alias (__sigaction, sigaction)
-libc_hidden_weak(sigaction)
+hidden_weak(sigaction)
#else
...
I have now some free time to look at pending patches. It's on my queue.
I don't want to nag, but since I just had some time to work on my
ARM toolchain crosstool-ng build I thought to let you know that
with yesterday's git eb72efd this issue is still present.
Johannes
Hello,
I don't think this fix is the best one; is rather a w/a.
I'm reviewing the code as it seems we have a mess with sigaction
symbols/aliased between libc and libpthread.
Carmelo
Well,
what I'd expect to have for sigaction is:
libc.{so,a}
--- __libc_sigaction (global)
--- sigaction (weak alias of __libc_sigaction)
--- __GI_sigaction (hidden alias for internal use, if any)
and
libpthread.{so,a}
--- sigaction (global)
--- __libc_sigaction (undefined)
So, to summarise I'd expect
libc.{so,a}
--- __libc_sigaction (global)
--- __GI_sigaction (hidden alias for internal use)
--- sigaction
a. A wrapper to __libc_sigaction (if NPTL configured)
b. A weak alias to __libc_sigaction (thread none)
and nothing duplicated into libpthread.
make more sense ?
carmelo
where the sigaction implementation in the libpthread should wrap around
the __libc_sigaction adding the extra check for the SIGCANCEL and SIGSETXID.
I would not expect to see, as we currently have, __libc_sigaction
reimplemented in the pthread library.
So rather then working around the static build issue, I'd prefer to tidy
things up, definitely.
Feedback are welcome.
Carmelo
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: static link with NPTL on ARM fails
On Jan 27, 2012 4:47 PM, Carmelo AMOROSO carmelo.amor...@st.com wrote:
So, to summarise I'd expect
libc.{so,a}
--- __libc_sigaction (global)
--- __GI_sigaction (hidden alias for internal use)
--- sigaction
a. A wrapper to __libc_sigaction (if NPTL configured)
b. A weak alias to __libc_sigaction (thread none)
I think that should be a strong alias if NO_THREADS.
and nothing duplicated into libpthread.
make more sense ?
Yes.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: static link with NPTL on ARM fails
On 27/01/2012 16.54, Bernhard Reutner-Fischer wrote:
On Jan 27, 2012 4:47 PM, Carmelo AMOROSO carmelo.amor...@st.com wrote:
So, to summarise I'd expect
libc.{so,a}
--- __libc_sigaction (global)
--- __GI_sigaction (hidden alias for internal use)
--- sigaction
a. A wrapper to __libc_sigaction (if NPTL configured)
b. A weak alias to __libc_sigaction (thread none)
I think that should be a strong alias if NO_THREADS.
indeed.. not expected to be overridden.
and nothing duplicated into libpthread.
make more sense ?
Yes.
:)
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: static link with NPTL on ARM fails
On Fri, Jan 13, 2012 at 10:38:57AM +0100, Carmelo AMOROSO wrote: On 16/12/2011 18.36, Johannes Stezenbach wrote: On Fri, Dec 16, 2011 at 05:59:16PM +0100, Carmelo Amoroso wrote: On 16/12/11 15:57, Johannes Stezenbach wrote: I was able to fix the issue like this: --- uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c.orig 2011-12-03 18:55:45.0 +0100 +++ uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c 2011-12-14 11:48:52.0 +0100 @@ -38,9 +38,9 @@ return __libc_sigaction (sig, act, oact); } -libc_hidden_proto(sigaction) +hidden_proto(sigaction) weak_alias (__sigaction, sigaction) -libc_hidden_weak(sigaction) +hidden_weak(sigaction) #else ... I have now some free time to look at pending patches. It's on my queue. I don't want to nag, but since I just had some time to work on my ARM toolchain crosstool-ng build I thought to let you know that with yesterday's git eb72efd this issue is still present. Johannes ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: static link with NPTL on ARM fails
On 16/12/2011 18.36, Johannes Stezenbach wrote: On Fri, Dec 16, 2011 at 05:59:16PM +0100, Carmelo Amoroso wrote: On 16/12/11 15:57, Johannes Stezenbach wrote: I was able to fix the issue like this: --- uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c.orig 2011-12-03 18:55:45.0 +0100 +++ uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c 2011-12-14 11:48:52.0 +0100 @@ -38,9 +38,9 @@ return __libc_sigaction (sig, act, oact); } -libc_hidden_proto(sigaction) +hidden_proto(sigaction) weak_alias (__sigaction, sigaction) -libc_hidden_weak(sigaction) +hidden_weak(sigaction) #else ... I think that the proper fix is to remove sigaction from libpthread,a instead. But they are not identical, libpthread/nptl/sysdeps/pthread/sigaction.c has this comment: /* We use the libc implementation but we tell it to not allow SIGCANCEL or SIGTIMER to be handled. */ you're right. I have now some free time to look at pending patches. It's on my queue. Carmelo Johannes ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: static link with NPTL on ARM fails
Hi, On Fri, Dec 16, 2011 at 06:36:35PM +0100, Johannes Stezenbach wrote: On Fri, Dec 16, 2011 at 05:59:16PM +0100, Carmelo Amoroso wrote: On 16/12/11 15:57, Johannes Stezenbach wrote: I was able to fix the issue like this: --- uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c.orig 2011-12-03 18:55:45.0 +0100 +++ uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c 2011-12-14 11:48:52.0 +0100 @@ -38,9 +38,9 @@ return __libc_sigaction (sig, act, oact); } -libc_hidden_proto(sigaction) +hidden_proto(sigaction) weak_alias (__sigaction, sigaction) -libc_hidden_weak(sigaction) +hidden_weak(sigaction) #else ... I think that the proper fix is to remove sigaction from libpthread,a instead. But they are not identical, libpthread/nptl/sysdeps/pthread/sigaction.c has this comment: /* We use the libc implementation but we tell it to not allow SIGCANCEL or SIGTIMER to be handled. */ Could you please let me know if you agree with my proposed fix? Thanks Johannes ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: static link with NPTL on ARM fails
On Tue, Nov 29, 2011 at 04:51:35PM +0100, Johannes Stezenbach wrote:
On Mon, Nov 28, 2011 at 10:51:04PM +0100, Bernhard Reutner-Fischer wrote:
On Nov 28, 2011 6:43 PM, Johannes Stezenbach j...@sig21.net wrote:
I'm in the process of building a toolchain with crosstool-ng,
with uClibc-0.9.32 + NPTL for ARM926EJ-S.
Trying to statically link a simple testcase with NPTL fails:
$ cat t.c
#include pthread.h
int main(int argc, char *argv[])
{
return (int)pthread_create;
}
$ arm-linux-gcc -Wall -Os t.c -lpthread -static -Wl,-Map=m
/tmp/tc/arm-unknown-linux-uclibcgnueabi/arm-unknown-linux-uclibcgnueabi/sysroot/usr/lib/libc.a(sigaction.o):
In function `__libc_sigaction':
sigaction.c:(.text+0x0): multiple definition of `__libc_sigaction'
/tmp/tc/arm-unknown-linux-uclibcgnueabi/arm-unknown-linux-uclibcgnueabi/sysroot/usr/lib/libpthread.a(pt-sigaction.o):pt-sigaction.c:(.text+0x0):
first defined here
Can you reproduce this with current master?
Yes. I get exactly the same failure.
I was able to fix the issue like this:
--- uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c.orig
2011-12-03 18:55:45.0 +0100
+++ uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c 2011-12-14
11:48:52.0 +0100
@@ -38,9 +38,9 @@
return __libc_sigaction (sig, act, oact);
}
-libc_hidden_proto(sigaction)
+hidden_proto(sigaction)
weak_alias (__sigaction, sigaction)
-libc_hidden_weak(sigaction)
+hidden_weak(sigaction)
#else
I still think that the root cause is that libc_hidden_proto() etc. are
enabled for static build at all, but it's not easy to change,
and apparently noone wants to even discuss it ;-/
If you agree on the above I'll resend with proper description
and s-o-b.
I only tested lightly (compiled and run a static iperf).
Thanks
Johannes
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: static link with NPTL on ARM fails
On 16/12/11 15:57, Johannes Stezenbach wrote:
On Tue, Nov 29, 2011 at 04:51:35PM +0100, Johannes Stezenbach wrote:
On Mon, Nov 28, 2011 at 10:51:04PM +0100, Bernhard Reutner-Fischer wrote:
On Nov 28, 2011 6:43 PM, Johannes Stezenbach j...@sig21.net wrote:
I'm in the process of building a toolchain with crosstool-ng,
with uClibc-0.9.32 + NPTL for ARM926EJ-S.
Trying to statically link a simple testcase with NPTL fails:
$ cat t.c
#include pthread.h
int main(int argc, char *argv[])
{
return (int)pthread_create;
}
$ arm-linux-gcc -Wall -Os t.c -lpthread -static -Wl,-Map=m
/tmp/tc/arm-unknown-linux-uclibcgnueabi/arm-unknown-linux-uclibcgnueabi/sysroot/usr/lib/libc.a(sigaction.o):
In function `__libc_sigaction':
sigaction.c:(.text+0x0): multiple definition of `__libc_sigaction'
/tmp/tc/arm-unknown-linux-uclibcgnueabi/arm-unknown-linux-uclibcgnueabi/sysroot/usr/lib/libpthread.a(pt-sigaction.o):pt-sigaction.c:(.text+0x0):
first defined here
Can you reproduce this with current master?
Yes. I get exactly the same failure.
I was able to fix the issue like this:
--- uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c.orig
2011-12-03 18:55:45.0 +0100
+++ uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c 2011-12-14
11:48:52.0 +0100
@@ -38,9 +38,9 @@
return __libc_sigaction (sig, act, oact);
}
-libc_hidden_proto(sigaction)
+hidden_proto(sigaction)
weak_alias (__sigaction, sigaction)
-libc_hidden_weak(sigaction)
+hidden_weak(sigaction)
#else
I still think that the root cause is that libc_hidden_proto() etc. are
enabled for static build at all, but it's not easy to change,
and apparently noone wants to even discuss it ;-/
If you agree on the above I'll resend with proper description
and s-o-b.
I only tested lightly (compiled and run a static iperf).
Thanks
Johannes
I think that the proper fix is to remove sigaction from libpthread,a instead.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: static link with NPTL on ARM fails
On Fri, Dec 16, 2011 at 05:59:16PM +0100, Carmelo Amoroso wrote: On 16/12/11 15:57, Johannes Stezenbach wrote: I was able to fix the issue like this: --- uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c.orig 2011-12-03 18:55:45.0 +0100 +++ uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c 2011-12-14 11:48:52.0 +0100 @@ -38,9 +38,9 @@ return __libc_sigaction (sig, act, oact); } -libc_hidden_proto(sigaction) +hidden_proto(sigaction) weak_alias (__sigaction, sigaction) -libc_hidden_weak(sigaction) +hidden_weak(sigaction) #else ... I think that the proper fix is to remove sigaction from libpthread,a instead. But they are not identical, libpthread/nptl/sysdeps/pthread/sigaction.c has this comment: /* We use the libc implementation but we tell it to not allow SIGCANCEL or SIGTIMER to be handled. */ Johannes ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: static link with NPTL on ARM fails
On Mon, Nov 28, 2011 at 10:51:04PM +0100, Bernhard Reutner-Fischer wrote:
On Nov 28, 2011 6:43 PM, Johannes Stezenbach j...@sig21.net wrote:
I'm in the process of building a toolchain with crosstool-ng,
with uClibc-0.9.32 + NPTL for ARM926EJ-S.
Trying to statically link a simple testcase with NPTL fails:
$ cat t.c
#include pthread.h
int main(int argc, char *argv[])
{
return (int)pthread_create;
}
$ arm-linux-gcc -Wall -Os t.c -lpthread -static -Wl,-Map=m
/tmp/tc/arm-unknown-linux-uclibcgnueabi/arm-unknown-linux-uclibcgnueabi/sysroot/usr/lib/libc.a(sigaction.o):
In function `__libc_sigaction':
sigaction.c:(.text+0x0): multiple definition of `__libc_sigaction'
/tmp/tc/arm-unknown-linux-uclibcgnueabi/arm-unknown-linux-uclibcgnueabi/sysroot/usr/lib/libpthread.a(pt-sigaction.o):pt-sigaction.c:(.text+0x0):
first defined here
Can you reproduce this with current master?
Yes. I get exactly the same failure.
A general question: What is the purpose of enabling the __GI_ internal
aliases for static objects? According to the comment in libc-symbols.h,
hidden_proto() etc. are for PLT bypassing.
I'm trying to figure out this is all supposed to work, thus a few
statements with lots of question marks. Please let me know
if this makes sense:
There could be two reasons for PLT bypassing:
1. performance (less work for ld.so since the linker can resolve these
statically)
2. correctness (even if e.g. libpthread overrides a symbol libc still needs
to call its own version)
I'm not sure if there are actual cases for reason 2?
For the sigaction issue it looks wrong to me that abort() calls __GI_sigaction
and not the NPTL version. FWIW, glibc does not have
libc_hidden_proto(sigaction),
but only libc_hidden_proto(__sigaction) and libc_hidden_proto(__libc_sigaction).
I.e. if libc wants to refer explicitly to the libc version of a function,
not to the NPTL version, it would refer to __libc_*, and not rely on
the libc_hidden_proto magic. IOW, the libc_hidden_proto magic is only
for performance, not for correctness?
Thanks
Johannes
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: static link with NPTL on ARM fails
On Nov 28, 2011 6:43 PM, Johannes Stezenbach j...@sig21.net wrote:
Hi,
I'm in the process of building a toolchain with crosstool-ng,
with uClibc-0.9.32 + NPTL for ARM926EJ-S.
Trying to statically link a simple testcase with NPTL fails:
$ cat t.c
#include pthread.h
int main(int argc, char *argv[])
{
return (int)pthread_create;
}
$ arm-linux-gcc -Wall -Os t.c -lpthread -static -Wl,-Map=m
/tmp/tc/arm-unknown-linux-uclibcgnueabi/arm-unknown-linux-uclibcgnueabi/sysroot/usr/lib/libc.a(sigaction.o):
In function `__libc_sigaction':
sigaction.c:(.text+0x0): multiple definition of `__libc_sigaction'
/tmp/tc/arm-unknown-linux-uclibcgnueabi/arm-unknown-linux-uclibcgnueabi/sysroot/usr/lib/libpthread.a(pt-sigaction.o):pt-sigaction.c:(.text+0x0):
first defined here
Can you reproduce this with current master?
Thanks,
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
