Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
July 05, 2017 Linux linker errors with binutils >= 2.27 | ||||
---|---|---|---|---|
| ||||
Since binutils 2.27 I can not compile dmd with the `gold` linker any more. On my Gentoo Linux amd64 host, when linking the 32-bit version of druntime the following error is repeatedly output for all kinds of symbols: libdruntime.so.a(libdruntime.so.o): relocation R_386_GOTOFF against preemptible symbol <some mangled name> cannot be used when making a shared object Now starting with binutils 2.28 - in addition to the above - dynamically linked Dlang executables error out in druntime with an error message of this type: Fatal Error while loading '/usr/lib64/libphobos2.so.0.74': The module '<some module>' is already defined in '<executable>'. Does anyone have solutions to one or both of these issues at hand? For Gentoo packages I made shared linking the default and unless my configuration is a unique snowflake this is right now affecting all DMD users there. From reading `checkModuleCollisions()` [https://github.com/dlang/druntime/blob/master/src/rt/sections_elf_shared.d#L891] it would seem that changes in copy-relocations have something to do with the second issue it. -- Marco |
July 05, 2017 Re: Linux linker errors with binutils >= 2.27 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marco Leise | Marco Leise wrote:
> Since binutils 2.27 I can not compile dmd with the `gold`
> linker any more. On my Gentoo Linux amd64 host, when linking
> the 32-bit version of druntime the following error is
> repeatedly output for all kinds of symbols:
>
> libdruntime.so.a(libdruntime.so.o):
> relocation R_386_GOTOFF against preemptible symbol <some
> mangled name> cannot be used when making a shared object
>
> Now starting with binutils 2.28 - in addition to the above -
> dynamically linked Dlang executables error out in druntime
> with an error message of this type:
>
> Fatal Error while loading '/usr/lib64/libphobos2.so.0.74':
> The module '<some module>' is already defined in '<executable>'.
>
> Does anyone have solutions to one or both of these issues at
> hand? For Gentoo packages I made shared linking the default
> and unless my configuration is a unique snowflake this is
> right now affecting all DMD users there.
> From reading `checkModuleCollisions()`
> [https://github.com/dlang/druntime/blob/master/src/rt/sections_elf_shared.d#L891]
> it would seem that changes in copy-relocations have something
> to do with the second issue it.
1. patch your compiler to use old ELF_COMDAT hack in elfobj.c:
#define ELF_COMDAT TARGET_LINUX
+#undef ELF_COMDAT
+#define ELF_COMDAT 0
2. downgrade to old binutils, new binutils are not working with dmd .so's.
step "2" is essential. alas.
|
July 05, 2017 Re: Linux linker errors with binutils >= 2.27 | ||||
---|---|---|---|---|
| ||||
Posted in reply to ketmar | Am Wed, 5 Jul 2017 22:14:47 +0300 schrieb ketmar <ketmar@ketmar.no-ip.org>: > Marco Leise wrote: > > > Since binutils 2.27 I can not compile dmd with the `gold` linker any more. On my Gentoo Linux amd64 host, when linking the 32-bit version of druntime the following error is repeatedly output for all kinds of symbols: > > > > libdruntime.so.a(libdruntime.so.o): > > relocation R_386_GOTOFF against preemptible symbol <some > > mangled name> cannot be used when making a shared object > > > > Now starting with binutils 2.28 - in addition to the above - dynamically linked Dlang executables error out in druntime with an error message of this type: > > > > Fatal Error while loading '/usr/lib64/libphobos2.so.0.74': > > The module '<some module>' is already defined in '<executable>'. > > > > Does anyone have solutions to one or both of these issues at > > hand? For Gentoo packages I made shared linking the default > > and unless my configuration is a unique snowflake this is > > right now affecting all DMD users there. > > From reading `checkModuleCollisions()` > > [https://github.com/dlang/druntime/blob/master/src/rt/sections_elf_shared.d#L891] > > it would seem that changes in copy-relocations have something > > to do with the second issue it. > > 1. patch your compiler to use old ELF_COMDAT hack in elfobj.c: > #define ELF_COMDAT TARGET_LINUX > +#undef ELF_COMDAT > +#define ELF_COMDAT 0 > > 2. downgrade to old binutils, new binutils are not working with dmd .so's. > > step "2" is essential. alas. That information is gold, ketmar! -- Marco |
July 05, 2017 Re: Linux linker errors with binutils >= 2.27 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marco Leise | Marco Leise wrote:
> That information is gold, ketmar!
sorry for not helping much, tho. i hit this issue some time ago, and the only way i found (which solves *all* problems) is downgrading binutils. without that, COMDAT trick won't help (but it helps with other cases, like duplicate identifiers -- this case is partially patched in new dmd, tho).
|
July 05, 2017 Re: Linux linker errors with binutils >= 2.27 | ||||
---|---|---|---|---|
| ||||
Posted in reply to ketmar | This is the bug report for binutils 2.28 and the "module is already defined in" error: https://issues.dlang.org/show_bug.cgi?id=17375 Basically you need to add -fPIC to the command line for the executable when linking against shared objects. One way to do so is to add that switch to dmd.conf. Now that x86 32-bit is dying I feel that's acceptable in most situations. -- Marco |
Copyright © 1999-2021 by the D Language Foundation