Re: [Bug ld/16452] New: ELF executable with weak reference linked with ld causes assertion in ld.so
Good day, I would like to clarify :
I'm trying to compile openssh , using own compiled toolchan. at compile time I
come across such an error
openbsd-compat / / libopenbsd-compat.a (bsd-misc.o): (. pdr +0 x20): undefined
reference to `setlogin @ @ GLIBC_2.0 '
/ home / andrew / Desktop / mips-toolchan / bin /.. /.. / mips-toolchan / /
root/lib/libc.so.6: undefined reference to `setlogin @ @ GLIBC_2.0
I checked
Content libraries connected during linking:
libc_pic.a: setlogin.os: U __ divdi3_internal
libc_pic.a: setlogin.os: n __ evoke_link_warning_setlogin
libc_pic.a: setlogin.os: U __ GI_memmove
libc_pic.a: setlogin.os: U __ GI_memset
libc_pic.a: setlogin.os: U _gp_disp
libc_pic.a: setlogin.os: U __ libc_errno
libc_pic.a: setlogin.os: U __ moddi3_internal
libc_pic.a: setlogin.os: T setlogin
libc_pic.a: setlogin.os: U __ udivdi3_internal
libc_pic.a: setlogin.os: U __ umoddi3_internal
This may be due to an error upomyanotoy (regression in ld)?15 янв. 2014 г.
> http://sourceware.org/bugzilla/show_bug.cgi?id=16452
>
>Bug ID: 16452
> Summary: ELF executable with weak reference linked with ld
>causes assertion in ld.so
> Product: binutils
> Version: 2.25 (HEAD)
>Status: NEW
> Severity: normal
> Priority: P2
> Component: ld
> Assignee: unassigned at sourceware dot org
> Reporter: brnguyen at nvidia dot com
>
> Created attachment 7357
> --> http://sourceware.org/bugzilla/attachment.cgi?id=7357&action=edit
> Reproduction test case
>
> The attached reproduction test case builds two DSOs, one linked against
> pthreads, and one not linked against pthreads, which implement the same
> interface. It also builds a test application which is linked against the DSO
> that uses pthreads. To reproduce the bug, the DSO that does not use pthreads
> is copied over the DSO that uses pthreads, and the test application is run.
>
> Using an ld built from commit 08d0cad39e31083cb8a885703604f7b20d359849, this
> triggers the following assertion on ld.so built from commit
> 2f10c4d6901e7a4c4ad294cc5bb8ece6547f4f62 as well as ld.so from glibc
> 2.15-0ubuntu10.5-ppa1 on my Ubuntu 12.04 LTS system:
>
> Inconsistency detected by ld.so: dl-version.c: 224: _dl_check_map_versions:
> Assertion `needed != ((void *)0)' failed!
>
> This may be related to bugs #15149 and #12549. Also relevant is Debian bug
> #728529.
>
> This appears to be a regression in ld (though there may be a bug in ld.so as
> well). I bisected binutils using this reproduction test case to try to narrow
> down the commit(s) responsible for this regression. Interestingly, ld fails to
> link the test executable in a commit range between ToT master and
> binutils_2.22, with the following error messages:
>
> /home/brnguyen/build/binutils//ld/ld: /tmp/cc3K1rHK.o: undefined reference to
> symbol 'pthread_create@@GLIBC_2.2.5'
> /home/brnguyen/build/binutils//ld/ld: note: 'pthread_create@@GLIBC_2.2.5' is
> defined in DSO //lib/x86_64-linux-gnu/libpthread.so.0 so try adding it to the
> linker command line
>
> It appears this link error was introduced by commit
> b64fb44af4f416fbbbda3de03fcfff61d80c841c ("Also track weak references") and
> later removed by commit 879707c642925947e156b7ae2169b89f844532cd ("Exclude
> weak
> refs when considering whether an --as-needed library is needed"), at which
> point ld produces an executable which triggers the assertion.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>
> ___
> bug-binutils mailing list
> bug-binutils@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-binutils
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/16452] ELF executable with weak reference linked with ld causes assertion in ld.so
http://sourceware.org/bugzilla/show_bug.cgi?id=16452
--- Comment #2 from roseandrew at me dot com ---
Good day, I would like to clarify :
I'm trying to compile openssh , using own compiled toolchan. at compile tim
e I
come across such an error
openbsd-compat / / libopenbsd-compat.a (bsd-misc.o): (. pdr +0 x20): undefi
ned
reference to `setlogin @ @ GLIBC_2.0 '
/ home / andrew / Desktop / mips-toolchan / bin /.. /.. / mips-toolchan / /
root/lib/libc.so.6: undefined reference to `setlogin @ @ GLIBC_2.0
I checked
Content libraries connected during linking:
libc_pic.a: setlogin.os: U __ divdi3_internal
libc_pic.a: setlogin.os: n __ evoke_link_warning_setlogin
libc_pic.a: setlogin.os: U __ GI_memmove
libc_pic.a: setlogin.os: U __ GI_memset
libc_pic.a: setlogin.os: U _gp_disp
libc_pic.a: setlogin.os: U __ libc_errno
libc_pic.a: setlogin.os: U __ moddi3_internal
libc_pic.a: setlogin.os: T setlogin
libc_pic.a: setlogin.os: U __ udivdi3_internal
libc_pic.a: setlogin.os: U __ umoddi3_internal
This may be due to an error upomyanotoy (regression in ld)?15 ян
в. 2014 г.
> http://sourceware.org/bugzilla/show_bug.cgi?id=16452
>
>Bug ID: 16452
> Summary: ELF executable with weak reference linked with ld
>causes assertion in ld.so
> Product: binutils
> Version: 2.25 (HEAD)
>Status: NEW
> Severity: normal
> Priority: P2
> Component: ld
> Assignee: unassigned at sourceware dot org
> Reporter: brnguyen at nvidia dot com
>
> Created attachment 7357
> --> http://sourceware.org/bugzilla/attachment.cgi?id=7357&action=edit
> Reproduction test case
>
> The attached reproduction test case builds two DSOs, one linked against
> pthreads, and one not linked against pthreads, which implement the same
> interface. It also builds a test application which is linked against the
DSO
> that uses pthreads. To reproduce the bug, the DSO that does not use pthr
eads
> is copied over the DSO that uses pthreads, and the test application is ru
n.
>
> Using an ld built from commit 08d0cad39e31083cb8a885703604f7b20d359849, t
his
> triggers the following assertion on ld.so built from commit
> 2f10c4d6901e7a4c4ad294cc5bb8ece6547f4f62 as well as ld.so from glibc
> 2.15-0ubuntu10.5-ppa1 on my Ubuntu 12.04 LTS system:
>
> Inconsistency detected by ld.so: dl-version.c: 224: _dl_check_map_version
s:
> Assertion `needed != ((void *)0)' failed!
>
> This may be related to bugs #15149 and #12549. Also relevant is Debian bug
> #728529.
>
> This appears to be a regression in ld (though there may be a bug in ld.so
as
> well). I bisected binutils using this reproduction test case to try to na
rrow
> down the commit(s) responsible for this regression. Interestingly, ld fai
ls to
> link the test executable in a commit range between ToT master and
> binutils_2.22, with the following error messages:
>
> /home/brnguyen/build/binutils//ld/ld: /tmp/cc3K1rHK.o: undefined referenc
e to
> symbol 'pthread_create@@GLIBC_2.2.5'
> /home/brnguyen/build/binutils//ld/ld: note: 'pthread_create@@GLIBC_2.2.5'
is
> defined in DSO //lib/x86_64-linux-gnu/libpthread.so.0 so try adding it to
the
> linker command line
>
> It appears this link error was introduced by commit
> b64fb44af4f416fbbbda3de03fcfff61d80c841c ("Also track weak references") a
nd
> later removed by commit 879707c642925947e156b7ae2169b89f844532cd ("Exclud
e weak
> refs when considering whether an --as-needed library is needed"), at which
> point ld produces an executable which triggers the assertion.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>
> ___
> bug-binutils mailing list
> bug-binutils@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-binutils
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
ld bug when self-referential variables are used as output section addresses ?
Hi,
I have the following linker script:
TOTO = 1024;
TOTO += 1024;
SECTIONS
{
.rodataTOTO :
{
__toto_symbol_abs = ABSOLUTE(TOTO);
*(.rodata)
*(.rodata.*)
}
}
When I link this example with the latest ld, the section ".rodata" is
placed at 1024, whereas I would have expected 2048. __toto_symbol_abs
gets the value 2048.
With ld 2.22.52 .rodata is placed at 2048. I believe this commit by Alan
Modra changed ld's behaviour: 4194268f43623a5f893b9a92b0456d3cb43ab915.
My understanding of the patch is that it delays the evaluation of
self-referential expressions until section sizing has been completed. We
depended on the previous behaviour for correct placement of output
sections (mostly calculating alignment constraints).
Is what I observe expected behaviour? If so is there any way to achieve
what I want apart from using static single assignment? And why the change?
I used the following command:
ld -T test.ld main.o -o main
where main.o is simply:
int main(void){return 0;}
compiled with:
gcc -c main.c
I'd be very grateful for any information on this issue.
Best Regards,
Samuel Jones
Kalray SA - www.kalray.eu
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/16417] executable linked with gold segfaults before main
https://sourceware.org/bugzilla/show_bug.cgi?id=16417 --- Comment #2 from Alex Turbov --- Created attachment 7358 --> https://sourceware.org/bugzilla/attachment.cgi?id=7358&action=edit compiled object file -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
