* [Bug libc/15648] multiple definition of `__lll_lock_wait_private'
2013-06-19 10:15 [Bug libc/15648] New: multiple definition of `__lll_lock_wait_private' knrstaj at gmail dot com
@ 2013-06-19 15:01 ` carlos at redhat dot com
2013-06-20 2:47 ` knrstaj at gmail dot com
` (22 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: carlos at redhat dot com @ 2013-06-19 15:01 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=15648
Carlos O'Donell <carlos at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |WAITING
CC| |carlos at redhat dot com
--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
We need a complete reproducer for this issue please.
Include exactly the steps you took and the expected versus observed results.
This includes the exact gcc command you used to compile your application, and
exactly what version of glibc you were using.
If you are using a distro glibc then you need to file this issue upstream with
the distro so they can determine if any of their patches caused the problem.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/15648] multiple definition of `__lll_lock_wait_private'
2013-06-19 10:15 [Bug libc/15648] New: multiple definition of `__lll_lock_wait_private' knrstaj at gmail dot com
2013-06-19 15:01 ` [Bug libc/15648] " carlos at redhat dot com
@ 2013-06-20 2:47 ` knrstaj at gmail dot com
2013-06-20 2:54 ` knrstaj at gmail dot com
` (21 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: knrstaj at gmail dot com @ 2013-06-20 2:47 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=15648
Neil <knrstaj at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |knrstaj at gmail dot com
--- Comment #2 from Neil <knrstaj at gmail dot com> ---
Created attachment 7085
--> http://sourceware.org/bugzilla/attachment.cgi?id=7085&action=edit
multiple definition of `__lll_lock_wait_private' example
OS version : Ubuntu 12.04
gcc version : gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
untar the tarball, and use make to reproduce the bug.
I expect there is no error message.
But I get error message when linking.
compiler options "-ftree-parallelize-loops=2 -flto -O1" are necessary.
gcc -ftree-parallelize-loops=2 -flto -O1 core_list_join.i -c -o
core_list_join.o
gcc -ftree-parallelize-loops=2 -flto -O1 core_main.i -c -o core_main.o
gcc -ftree-parallelize-loops=2 -flto -O1 core_matrix.i -c -o core_matrix.o
gcc -ftree-parallelize-loops=2 -flto -O1 core_state.i -c -o core_state.o
gcc -ftree-parallelize-loops=2 -flto -O1 core_util.i -c -o core_util.o
gcc -ftree-parallelize-loops=2 -flto -O1 core_portme.i -c -o core_portme.o
gcc -ftree-parallelize-loops=2 -flto -O1 *.o -static -o coremark.exe
/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/libpthread.a(lowlevellock.o):
In function `__lll_lock_wait_private':
/build/buildd/eglibc-2.15/nptl/../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S:76:
multiple definition of `__lll_lock_wait_private'
/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/libc.a(libc-lowlevellock.o):(.text+0x0):
first defined here
/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/libpthread.a(lowlevellock.o):
In function `__lll_unlock_wake_private':
/build/buildd/eglibc-2.15/nptl/../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S:332:
multiple definition of `__lll_unlock_wake_private'
/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/libc.a(libc-lowlevellock.o):(.text+0x30):
first defined here
collect2: ld returned 1 exit status
make: *** [all] Error 1
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/15648] multiple definition of `__lll_lock_wait_private'
2013-06-19 10:15 [Bug libc/15648] New: multiple definition of `__lll_lock_wait_private' knrstaj at gmail dot com
2013-06-19 15:01 ` [Bug libc/15648] " carlos at redhat dot com
2013-06-20 2:47 ` knrstaj at gmail dot com
@ 2013-06-20 2:54 ` knrstaj at gmail dot com
2013-06-20 3:32 ` [Bug libc/15648] Support building glibc with -flto carlos at redhat dot com
` (20 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: knrstaj at gmail dot com @ 2013-06-20 2:54 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=15648
--- Comment #3 from Neil <knrstaj at gmail dot com> ---
I also try linaro gcc 4.8 toolchain
http://releases.linaro.org/13.05/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.8-2013.05_linux.tar.bz2
the same situation
/work/linaro_tools/gcc-linaro-arm-linux-gnueabihf-4.8-2013.04-20130417_linux/bin/arm-linux-gnueabihf-gcc
-ftree-parallelize-loops=2 -flto -O1 core_list_join.i -c -o core_list_join.o
/work/linaro_tools/gcc-linaro-arm-linux-gnueabihf-4.8-2013.04-20130417_linux/bin/arm-linux-gnueabihf-gcc
-ftree-parallelize-loops=2 -flto -O1 core_main.i -c -o core_main.o
/work/linaro_tools/gcc-linaro-arm-linux-gnueabihf-4.8-2013.04-20130417_linux/bin/arm-linux-gnueabihf-gcc
-ftree-parallelize-loops=2 -flto -O1 core_matrix.i -c -o core_matrix.o
/work/linaro_tools/gcc-linaro-arm-linux-gnueabihf-4.8-2013.04-20130417_linux/bin/arm-linux-gnueabihf-gcc
-ftree-parallelize-loops=2 -flto -O1 core_state.i -c -o core_state.o
/work/linaro_tools/gcc-linaro-arm-linux-gnueabihf-4.8-2013.04-20130417_linux/bin/arm-linux-gnueabihf-gcc
-ftree-parallelize-loops=2 -flto -O1 core_util.i -c -o core_util.o
/work/linaro_tools/gcc-linaro-arm-linux-gnueabihf-4.8-2013.04-20130417_linux/bin/arm-linux-gnueabihf-gcc
-ftree-parallelize-loops=2 -flto -O1 core_portme.i -c -o core_portme.o
/work/linaro_tools/gcc-linaro-arm-linux-gnueabihf-4.8-2013.04-20130417_linux/bin/arm-linux-gnueabihf-gcc
-ftree-parallelize-loops=2 -flto -O1 *.o -static -o coremark.exe
/work/linaro_tools/gcc-linaro-arm-linux-gnueabihf-4.8-2013.04-20130417_linux/bin/../arm-linux-gnueabihf/libc/usr/lib/arm-linux-gnueabihf/libpthread.a(lowlevellock.o):
In function `__lll_lock_wait_private':
lowlevellock.c:(.text+0x0): multiple definition of `__lll_lock_wait_private'
/home/neilh/work/linaro_tools/gcc-linaro-arm-linux-gnueabihf-4.8-2013.04-20130417_linux/bin/../arm-linux-gnueabihf/libc/usr/lib/arm-linux-gnueabihf/libc.a(libc-lowlevellock.o):(.text+0x0):
first defined here
collect2: error: ld returned 1 exit status
make: *** [all] Error 1
Hope these information are enough to reproduce the issue.
Regards,
Neil
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/15648] Support building glibc with -flto.
2013-06-19 10:15 [Bug libc/15648] New: multiple definition of `__lll_lock_wait_private' knrstaj at gmail dot com
` (2 preceding siblings ...)
2013-06-20 2:54 ` knrstaj at gmail dot com
@ 2013-06-20 3:32 ` carlos at redhat dot com
2013-06-20 3:34 ` carlos at redhat dot com
` (19 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: carlos at redhat dot com @ 2013-06-20 3:32 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=15648
Carlos O'Donell <carlos at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
Summary|multiple definition of |Support building glibc with
|`__lll_lock_wait_private' |-flto.
Severity|normal |enhancement
--- Comment #4 from Carlos O'Donell <carlos at redhat dot com> ---
This doesn't work at all for me for entirely different reasons.
I expect that you haven't actually tried to use -flto.
glibc master is currently unbuildable with -flto because of:
http://sourceware.org/bugzilla/show_bug.cgi?id=15648
You should always see:
checking for .preinit_array/.init_array/.fini_array support... no
configure: error: Need linker with .init_array/.fini_array support.
This is because -flto throws out the .init_array support.
A potential fix is:
diff --git a/configure.in b/configure.in
index 8b11081..415e777 100644
--- a/configure.in
+++ b/configure.in
@@ -1383,7 +1383,7 @@ AC_CACHE_CHECK(for .preinit_array/.init_array/.fini_array
support,
libc_cv_initfini_array, [dnl
LIBC_TRY_LINK_STATIC([
int foo (void) { return 1; }
-int (*fp) (void) __attribute__ ((section (".init_array"))) = foo;
+int (*fp) (void) __attribute__ ((section (".init_array"), used)) = foo;
],
[if $READELF -S conftest | fgrep INIT_ARRAY > /dev/null; then
libc_cv_initfini_array=yes
~~~
However, given that nobody has built with -flto it's going to require
considerable work to make it happen.
I'm retitling and marking as enhancement.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/15648] Support building glibc with -flto.
2013-06-19 10:15 [Bug libc/15648] New: multiple definition of `__lll_lock_wait_private' knrstaj at gmail dot com
` (3 preceding siblings ...)
2013-06-20 3:32 ` [Bug libc/15648] Support building glibc with -flto carlos at redhat dot com
@ 2013-06-20 3:34 ` carlos at redhat dot com
2013-06-20 6:10 ` knrstaj at gmail dot com
` (18 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: carlos at redhat dot com @ 2013-06-20 3:34 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=15648
--- Comment #5 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Carlos O'Donell from comment #4)
> glibc master is currently unbuildable with -flto because of:
> http://sourceware.org/bugzilla/show_bug.cgi?id=15648
Should have been:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51255
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/15648] Support building glibc with -flto.
2013-06-19 10:15 [Bug libc/15648] New: multiple definition of `__lll_lock_wait_private' knrstaj at gmail dot com
` (4 preceding siblings ...)
2013-06-20 3:34 ` carlos at redhat dot com
@ 2013-06-20 6:10 ` knrstaj at gmail dot com
2013-06-20 8:15 ` [Bug libc/15648] multiple definition of `__lll_lock_wait_private' schwab@linux-m68k.org
` (17 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: knrstaj at gmail dot com @ 2013-06-20 6:10 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=15648
--- Comment #6 from Neil <knrstaj at gmail dot com> ---
Created attachment 7086
--> http://sourceware.org/bugzilla/attachment.cgi?id=7086&action=edit
multiple definition of `__lll_lock_wait_private' example2
I don't want to build glibc with -flto option.
I build application with -flto.
The problem is like building thread program which static link with -lc
-lpthread
For example:
gcc thread_program.c -lc -lpthread -static
/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/libpthread.a(lowlevellock.o):
In function `__lll_lock_wait_private':
/build/buildd/eglibc-2.15/nptl/../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S:76:
multiple definition of `__lll_lock_wait_private'
/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/libc.a(libc-lowlevellock.o):(.text+0x0):
first defined here
/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/libpthread.a(lowlevellock.o):
In function `__lll_unlock_wake_private':
/build/buildd/eglibc-2.15/nptl/../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S:332:
multiple definition of `__lll_unlock_wake_private'
/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/libc.a(libc-lowlevellock.o):(.text+0x30):
first defined here
collect2: ld returned 1 exit status
But, I don't know why -flto causes the problem for my first example. :(
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/15648] multiple definition of `__lll_lock_wait_private'
2013-06-19 10:15 [Bug libc/15648] New: multiple definition of `__lll_lock_wait_private' knrstaj at gmail dot com
` (5 preceding siblings ...)
2013-06-20 6:10 ` knrstaj at gmail dot com
@ 2013-06-20 8:15 ` schwab@linux-m68k.org
2013-06-20 9:24 ` knrstaj at gmail dot com
` (16 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: schwab@linux-m68k.org @ 2013-06-20 8:15 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=15648
Andreas Schwab <schwab@linux-m68k.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Support building glibc with |multiple definition of
|-flto. |`__lll_lock_wait_private'
--- Comment #7 from Andreas Schwab <schwab@linux-m68k.org> ---
This has nothing to do with building glibc with -flto. There are simply two
defintions of __lll_lock_wait_private and __lll_unlock_wait_private, one in
libpthread.a(lowlevellock.o) and another one in libc.a(libc-lowlevellock.o).
One of them needs to be elided from the static library.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/15648] multiple definition of `__lll_lock_wait_private'
2013-06-19 10:15 [Bug libc/15648] New: multiple definition of `__lll_lock_wait_private' knrstaj at gmail dot com
` (6 preceding siblings ...)
2013-06-20 8:15 ` [Bug libc/15648] multiple definition of `__lll_lock_wait_private' schwab@linux-m68k.org
@ 2013-06-20 9:24 ` knrstaj at gmail dot com
2013-06-20 12:55 ` carlos at redhat dot com
` (15 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: knrstaj at gmail dot com @ 2013-06-20 9:24 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=15648
--- Comment #8 from Neil <knrstaj at gmail dot com> ---
Yes, I see the libc.a and libpthread.a
nm /usr/lib/i386-linux-gnu/libpthread.a
lowlevellock.o:
U __have_futex_clock_realtime
00000030 T __lll_lock_wait
00000000 T __lll_lock_wait_private
00000060 T __lll_timedlock_wait
000001c0 T __lll_timedwait_tid
00000190 T __lll_unlock_wake
00000160 T __lll_unlock_wake_private
U _dl_sysinfo
nm /usr/lib/i386-linux-gnu/libc.a
libc-lowlevellock.o:
00000000 T __lll_lock_wait_private
00000030 T __lll_unlock_wake_private
U _dl_sysinfo
Why not to make __lll_lock_wait_private and __lll_unlock_wake_private in a
individual file?
If ld include libc-lowlevellock.o first, it always cause error when includeing
lowlevellock.o. Right?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/15648] multiple definition of `__lll_lock_wait_private'
2013-06-19 10:15 [Bug libc/15648] New: multiple definition of `__lll_lock_wait_private' knrstaj at gmail dot com
` (7 preceding siblings ...)
2013-06-20 9:24 ` knrstaj at gmail dot com
@ 2013-06-20 12:55 ` carlos at redhat dot com
2013-06-20 12:57 ` carlos at redhat dot com
` (14 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: carlos at redhat dot com @ 2013-06-20 12:55 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=15648
--- Comment #9 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Neil from comment #6)
> Created attachment 7086 [details]
> multiple definition of `__lll_lock_wait_private' example2
>
> I don't want to build glibc with -flto option.
> I build application with -flto.
Thanks, I misunderstood your problem.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/15648] multiple definition of `__lll_lock_wait_private'
2013-06-19 10:15 [Bug libc/15648] New: multiple definition of `__lll_lock_wait_private' knrstaj at gmail dot com
` (8 preceding siblings ...)
2013-06-20 12:55 ` carlos at redhat dot com
@ 2013-06-20 12:57 ` carlos at redhat dot com
2013-06-20 12:58 ` jakub at redhat dot com
` (13 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: carlos at redhat dot com @ 2013-06-20 12:57 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=15648
--- Comment #10 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Carlos O'Donell from comment #9)
> (In reply to Neil from comment #6)
> > Created attachment 7086 [details]
> > multiple definition of `__lll_lock_wait_private' example2
> >
> > I don't want to build glibc with -flto option.
> > I build application with -flto.
>
> Thanks, I misunderstood your problem.
Filed:
Bug 15658 - Support building glibc with -flto.
http://sourceware.org/bugzilla/show_bug.cgi?id=15658
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/15648] multiple definition of `__lll_lock_wait_private'
2013-06-19 10:15 [Bug libc/15648] New: multiple definition of `__lll_lock_wait_private' knrstaj at gmail dot com
` (9 preceding siblings ...)
2013-06-20 12:57 ` carlos at redhat dot com
@ 2013-06-20 12:58 ` jakub at redhat dot com
2013-06-20 13:52 ` carlos at redhat dot com
` (12 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: jakub at redhat dot com @ 2013-06-20 12:58 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=15648
--- Comment #11 from Jakub Jelinek <jakub at redhat dot com> ---
(In reply to Neil from comment #8)
> If ld include libc-lowlevellock.o first, it always cause error when
> includeing lowlevellock.o. Right?
But why does that happen?
You link -lc before -lpthread? That is never going to work properly when
linking the libraries statically.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/15648] multiple definition of `__lll_lock_wait_private'
2013-06-19 10:15 [Bug libc/15648] New: multiple definition of `__lll_lock_wait_private' knrstaj at gmail dot com
` (10 preceding siblings ...)
2013-06-20 12:58 ` jakub at redhat dot com
@ 2013-06-20 13:52 ` carlos at redhat dot com
2013-06-21 1:22 ` knrstaj at gmail dot com
` (11 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: carlos at redhat dot com @ 2013-06-20 13:52 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=15648
Carlos O'Donell <carlos at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |WAITING
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/15648] multiple definition of `__lll_lock_wait_private'
2013-06-19 10:15 [Bug libc/15648] New: multiple definition of `__lll_lock_wait_private' knrstaj at gmail dot com
` (11 preceding siblings ...)
2013-06-20 13:52 ` carlos at redhat dot com
@ 2013-06-21 1:22 ` knrstaj at gmail dot com
2013-06-21 1:33 ` knrstaj at gmail dot com
` (10 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: knrstaj at gmail dot com @ 2013-06-21 1:22 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=15648
--- Comment #13 from Neil <knrstaj at gmail dot com> ---
(In reply to Jakub Jelinek from comment #11)
> (In reply to Neil from comment #8)
> > If ld include libc-lowlevellock.o first, it always cause error when
> > includeing lowlevellock.o. Right?
>
> But why does that happen?
> You link -lc before -lpthread? That is never going to work properly when
> linking the libraries statically.
Exactly, statically link -c before -pthread never works well.
I mean I encounter the similar problem like that but I don't link -c before
-pthread.
I use gcc4.6 and the option "-ftree-parallelize-loops=2 -flto -O1" to compile
program.
Because of option "-ftree-parallelize-loops=2", gcc will auto apply -lpthread
to linker.
Then the error message show up.
In this case, I'm not sure this is gcc issue or glibc issue.
But I modify glibc source, the issue can be resolved.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/15648] multiple definition of `__lll_lock_wait_private'
2013-06-19 10:15 [Bug libc/15648] New: multiple definition of `__lll_lock_wait_private' knrstaj at gmail dot com
` (12 preceding siblings ...)
2013-06-21 1:22 ` knrstaj at gmail dot com
@ 2013-06-21 1:33 ` knrstaj at gmail dot com
2013-06-21 7:42 ` schwab@linux-m68k.org
` (9 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: knrstaj at gmail dot com @ 2013-06-21 1:33 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=15648
--- Comment #14 from Neil <knrstaj at gmail dot com> ---
Created attachment 7088
--> http://sourceware.org/bugzilla/attachment.cgi?id=7088&action=edit
link error message
I add -v and -Wl,--verbose.
There are more information.
Please see the attachment file.
Following is linking information.
gcc -ftree-parallelize-loops=2 -flto -O1 -save-temps *.o -static -o
coremark.exe -v -Wl,--verbose
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --enable-targets=all --disable-werror
--with-arch-32=i686 --with-tune=generic --enable-checking=release
--build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
COMPILER_PATH=/usr/lib/gcc/i686-linux-gnu/4.6/:/usr/lib/gcc/i686-linux-gnu/4.6/:/usr/lib/gcc/i686-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/4.6/:/usr/lib/gcc/i686-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i686-linux-gnu/4.6/:/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/4.6/../../../../lib/:/lib/i386-linux-gnu/:/lib/../lib/:/usr/lib/i386-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/i686-linux-gnu/4.6/../../../:/lib/:/usr/lib/
Reading specs from /usr/lib/gcc/i686-linux-gnu/4.6/libgomp.spec
COLLECT_GCC_OPTIONS='-ftree-parallelize-loops=2' '-flto' '-O1' '-save-temps'
'-static' '-o' 'coremark.exe' '-v' '-mtune=generic' '-march=i686' '-pthread'
/usr/lib/gcc/i686-linux-gnu/4.6/collect2 -plugin
/usr/lib/gcc/i686-linux-gnu/4.6/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/i686-linux-gnu/4.6/lto-wrapper
-plugin-opt=-fresolution=--verbose.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lpthread
-plugin-opt=-pass-through=-lc -flto --sysroot=/ --build-id --no-add-needed
--as-needed -m elf_i386 --hash-style=gnu -static -z relro -o coremark.exe
/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/crt1.o
/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/crti.o
/usr/lib/gcc/i686-linux-gnu/4.6/crtbeginT.o -L/usr/lib/gcc/i686-linux-gnu/4.6
-L/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu
-L/usr/lib/gcc/i686-linux-gnu/4.6/../../../../lib -L/lib/i386-linux-gnu
-L/lib/../lib -L/usr/lib/i386-linux-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/i686-linux-gnu/4.6/../../.. core_list_join.o core_main.o
coremark.exe.ltrans0.o core_matrix.o core_portme.o core_state.o core_util.o
--verbose -lgomp -lrt --start-group -lgcc -lgcc_eh -lpthread -lc --end-group
/usr/lib/gcc/i686-linux-gnu/4.6/crtend.o
/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/crtn.o
Hope this will help you.
Thanks,
Neil
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/15648] multiple definition of `__lll_lock_wait_private'
2013-06-19 10:15 [Bug libc/15648] New: multiple definition of `__lll_lock_wait_private' knrstaj at gmail dot com
` (13 preceding siblings ...)
2013-06-21 1:33 ` knrstaj at gmail dot com
@ 2013-06-21 7:42 ` schwab@linux-m68k.org
2013-06-21 7:52 ` jakub at redhat dot com
` (8 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: schwab@linux-m68k.org @ 2013-06-21 7:42 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=15648
--- Comment #15 from Andreas Schwab <schwab@linux-m68k.org> ---
The problem is that even though libpthread.a(lowlevellock.o) would resolve the
reference to __lll_lock_wait_private and/or __lll_unlock_wake_private the first
reference is from libc.a, and libpthread.a will only be rescanned after libc.a
cannot resolve any more references.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/15648] multiple definition of `__lll_lock_wait_private'
2013-06-19 10:15 [Bug libc/15648] New: multiple definition of `__lll_lock_wait_private' knrstaj at gmail dot com
` (14 preceding siblings ...)
2013-06-21 7:42 ` schwab@linux-m68k.org
@ 2013-06-21 7:52 ` jakub at redhat dot com
2013-06-21 13:13 ` carlos at redhat dot com
` (7 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: jakub at redhat dot com @ 2013-06-21 7:52 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=15648
Jakub Jelinek <jakub at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at redhat dot com
--- Comment #16 from Jakub Jelinek <jakub at redhat dot com> ---
Static linking of -lpthread never worked well, there are tons of issues with
that, which is why in Fedora/RHEL we are just linking all the content of
libpthread.a using ld -r into libpthread.o and libpthread.a contains just that
single object. Then this bug doesn't exist. There are many assumptions
(unwritten dependencies) in between libpthread object files, with dynamic
linking you simply have all of them together or nothing, but with libpthread,
unless you do that ld -r hack, you don't. Not to mention that many programs
(e.g. gcc gthr.h) check using weakref for availability of some pthread_*
symbol(s) and if non-NULL, assume all of libpthread is available, rather than
random parts from it.
Why exactly are you linking statically?
http://www.akkadia.org/drepper/no_static_linking.html
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/15648] multiple definition of `__lll_lock_wait_private'
2013-06-19 10:15 [Bug libc/15648] New: multiple definition of `__lll_lock_wait_private' knrstaj at gmail dot com
` (15 preceding siblings ...)
2013-06-21 7:52 ` jakub at redhat dot com
@ 2013-06-21 13:13 ` carlos at redhat dot com
2013-06-21 13:21 ` carlos at redhat dot com
` (6 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: carlos at redhat dot com @ 2013-06-21 13:13 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=15648
--- Comment #17 from Carlos O'Donell <carlos at redhat dot com> ---
Created attachment 7089
--> http://sourceware.org/bugzilla/attachment.cgi?id=7089&action=edit
Make __lll_lock_wait_private and __lll_unlock_wake_private weak in libc.
Could you test the following patch to see if it fixes the issue for you?
http://sourceware.org/glibc/wiki/Testing/Builds
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/15648] multiple definition of `__lll_lock_wait_private'
2013-06-19 10:15 [Bug libc/15648] New: multiple definition of `__lll_lock_wait_private' knrstaj at gmail dot com
` (16 preceding siblings ...)
2013-06-21 13:13 ` carlos at redhat dot com
@ 2013-06-21 13:21 ` carlos at redhat dot com
2013-06-21 14:42 ` knrstaj at gmail dot com
` (5 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: carlos at redhat dot com @ 2013-06-21 13:21 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=15648
--- Comment #18 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Jakub Jelinek from comment #16)
> Static linking of -lpthread never worked well, there are tons of issues with
> that, which is why in Fedora/RHEL we are just linking all the content of
> libpthread.a using ld -r into libpthread.o and libpthread.a contains just
> that single object. Then this bug doesn't exist. There are many
> assumptions (unwritten dependencies) in between libpthread object files,
> with dynamic linking you simply have all of them together or nothing, but
> with libpthread, unless you do that ld -r hack, you don't. Not to mention
> that many programs (e.g. gcc gthr.h) check using weakref for availability of
> some pthread_* symbol(s) and if non-NULL, assume all of libpthread is
> available, rather than random parts from it.
Then we need to file a bug to fix glibc to use ld -r or gather community
consensus that static linking is no longer supported. Current community
consensus is that we will continue to support static linking where possible.
> Why exactly are you linking statically?
> http://www.akkadia.org/drepper/no_static_linking.html
Good question, but it doesn't answer the more fundamental question of glibc
support for static linking.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/15648] multiple definition of `__lll_lock_wait_private'
2013-06-19 10:15 [Bug libc/15648] New: multiple definition of `__lll_lock_wait_private' knrstaj at gmail dot com
` (17 preceding siblings ...)
2013-06-21 13:21 ` carlos at redhat dot com
@ 2013-06-21 14:42 ` knrstaj at gmail dot com
2013-10-02 17:05 ` neleai at seznam dot cz
` (4 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: knrstaj at gmail dot com @ 2013-06-21 14:42 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=15648
--- Comment #19 from Neil <knrstaj at gmail dot com> ---
(In reply to Carlos O'Donell from comment #17)
> Created attachment 7089 [details]
> Make __lll_lock_wait_private and __lll_unlock_wake_private weak in libc.
>
> Could you test the following patch to see if it fixes the issue for you?
>
> http://sourceware.org/glibc/wiki/Testing/Builds
That's awesome!
This patch fixes the issue for me.
Is this patch OK for the trunk?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/15648] multiple definition of `__lll_lock_wait_private'
2013-06-19 10:15 [Bug libc/15648] New: multiple definition of `__lll_lock_wait_private' knrstaj at gmail dot com
` (18 preceding siblings ...)
2013-06-21 14:42 ` knrstaj at gmail dot com
@ 2013-10-02 17:05 ` neleai at seznam dot cz
2013-10-03 1:00 ` carlos at redhat dot com
` (3 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: neleai at seznam dot cz @ 2013-10-02 17:05 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=15648
Ondrej Bilka <neleai at seznam dot cz> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |neleai at seznam dot cz
--- Comment #20 from Ondrej Bilka <neleai at seznam dot cz> ---
Carlos, is your patch ready to libc-alpha?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/15648] multiple definition of `__lll_lock_wait_private'
2013-06-19 10:15 [Bug libc/15648] New: multiple definition of `__lll_lock_wait_private' knrstaj at gmail dot com
` (19 preceding siblings ...)
2013-10-02 17:05 ` neleai at seznam dot cz
@ 2013-10-03 1:00 ` carlos at redhat dot com
2014-02-07 3:04 ` [Bug nptl/15648] " jsm28 at gcc dot gnu.org
` (2 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: carlos at redhat dot com @ 2013-10-03 1:00 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=15648
Carlos O'Donell <carlos at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
--- Comment #21 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Ondrej Bilka from comment #20)
> Carlos, is your patch ready to libc-alpha?
No. This issue needs to be driven to consensus over the solution to use for
libpthread, either we link with `ld -r' and force all of libpthread into the
application during a static link or we do it piece-meal dependency by
dependency trying to keep the link minimal.
Previous comments from Roland and myself was that we should try to fix these
kinds of issues one at a time, but it's looking liked `ld -r' is going to be
the only real solution given the number of applications and core tools that use
a weakref and a check to test for conditional library inclusion.
This has to go to libca-alpha for discussion, but I don't have time to champion
this right now. If you are interested I encourage you to get consensus and
implement a solution, I'd be happy to review.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug nptl/15648] multiple definition of `__lll_lock_wait_private'
2013-06-19 10:15 [Bug libc/15648] New: multiple definition of `__lll_lock_wait_private' knrstaj at gmail dot com
` (20 preceding siblings ...)
2013-10-03 1:00 ` carlos at redhat dot com
@ 2014-02-07 3:04 ` jsm28 at gcc dot gnu.org
2014-06-13 15:03 ` fweimer at redhat dot com
2021-02-23 8:32 ` fweimer at redhat dot com
23 siblings, 0 replies; 25+ messages in thread
From: jsm28 at gcc dot gnu.org @ 2014-02-07 3:04 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=15648
Joseph Myers <jsm28 at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|libc |nptl
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug nptl/15648] multiple definition of `__lll_lock_wait_private'
2013-06-19 10:15 [Bug libc/15648] New: multiple definition of `__lll_lock_wait_private' knrstaj at gmail dot com
` (21 preceding siblings ...)
2014-02-07 3:04 ` [Bug nptl/15648] " jsm28 at gcc dot gnu.org
@ 2014-06-13 15:03 ` fweimer at redhat dot com
2021-02-23 8:32 ` fweimer at redhat dot com
23 siblings, 0 replies; 25+ messages in thread
From: fweimer at redhat dot com @ 2014-06-13 15:03 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=15648
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |security-
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug nptl/15648] multiple definition of `__lll_lock_wait_private'
2013-06-19 10:15 [Bug libc/15648] New: multiple definition of `__lll_lock_wait_private' knrstaj at gmail dot com
` (22 preceding siblings ...)
2014-06-13 15:03 ` fweimer at redhat dot com
@ 2021-02-23 8:32 ` fweimer at redhat dot com
23 siblings, 0 replies; 25+ messages in thread
From: fweimer at redhat dot com @ 2021-02-23 8:32 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=15648
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |2.34
CC| |fweimer at redhat dot com
Status|NEW |RESOLVED
Resolution|--- |FIXED
Assignee|unassigned at sourceware dot org |fweimer at redhat dot com
--- Comment #22 from Florian Weimer <fweimer at redhat dot com> ---
This should be fixed in glibc 2.34 by:
commit 2f4019de81024cc0d05a5b5cedb1afb28b59a836
Author: Florian Weimer <fweimer@redhat.com>
Date: Mon Feb 22 18:30:52 2021 +0100
nptl: Move lowlevellock into libc [BZ #15648]
And export __lll_lock_wait and __lll_lock_wait_private as
GLIBC_PRIVATE. This should eliminate the need for the previous
riscv kludge.
Similar issues for different symbols may still exist.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread