www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Linux linker errors with binutils >= 2.27

reply Marco Leise <Marco.Leise gmx.de> writes:
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.
=46rom 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.

--=20
Marco
Jul 05 2017
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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.
Jul 05 2017
parent reply Marco Leise <Marco.Leise gmx.de> writes:
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
Jul 05 2017
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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).
Jul 05 2017
parent Marco Leise <Marco.Leise gmx.de> writes:
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
Jul 05 2017