www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Link Problem

reply Qian Xu <quian.xu stud.tu-ilmenau.de> writes:
Hi All,

Someone has reported the issue here
(http://d.puremagic.com/issues/show_bug.cgi?id=1508)

Someone pointed, that the problem can be solved by changing the order of
object files. And this issue has been fixed in dmd.

I have the same problem by linking an executable using gdc.
Because my project cannot migrate to dmd immediately. 
So I want to change the order of object files. 
I have tried serveral combinations. But not get it done. (I have 380 object
files)

Can someone explain, what kind of a problem with compiler is this
specificly?


Best regards
--Qian
Apr 02 2009
parent reply davidl <davidl 126.com> writes:
在 Thu, 02 Apr 2009 19:16:10 +0800，Qian Xu <quian.xu stud.tu-ilmenau.de>  
写道:


 Hi All,

 Someone has reported the issue here
 (http://d.puremagic.com/issues/show_bug.cgi?id=1508)

 Someone pointed, that the problem can be solved by changing the order of
 object files. And this issue has been fixed in dmd.

 I have the same problem by linking an executable using gdc.
 Because my project cannot migrate to dmd immediately.
 So I want to change the order of object files.
 I have tried serveral combinations. But not get it done. (I have 380  
 object
 files)

 Can someone explain, what kind of a problem with compiler is this
 specificly?


 Best regards
 --Qian


You're sure that's a linking problem?
GDC only use DMD frontend, so if it's a linking problem it should be ld's.

LD seems to behave absurdly that it expects to resolve symbols.
e.g.
a.o provides symbol c, and b.o needs symbol c
you'd better feed ld with: b.o a.o not a.o b.o

Though you have that amount of files, the effort of tweaking orders just  
wastes your time. Try to make your code dmd compatible and try dmd!
Apr 02 2009
next sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
davidl wrote:

 ...
 
 Though you have that amount of files, the effort of tweaking orders just
 wastes your time. Try to make your code dmd compatible and try dmd!


I believe DMD on linux uses gcc (and by extension, ld) to link object files.

  -- Daniel
Apr 02 2009
prev sibling next sibling parent Qian Xu <quian.xu stud.tu-ilmenau.de> writes:
davidl wrote:


 You're sure that's a linking problem?
 GDC only use DMD frontend, so if it's a linking problem it should be ld's.
 
 LD seems to behave absurdly that it expects to resolve symbols.
 e.g.
 a.o provides symbol c, and b.o needs symbol c
 you'd better feed ld with: b.o a.o not a.o b.o
 


If I change the order of the object files, I might see different error
messages. But all of them are about "undefined reference to ..."



 Though you have that amount of files, the effort of tweaking orders just
 wastes your time. Try to make your code dmd compatible and try dmd!


We are migrating. But it takes time :)
Apr 02 2009
prev sibling parent reply TomD <t_demmer nospam.web.de> writes:
davidl Wrote:

[...]

 You're sure that's a linking problem?
 GDC only use DMD frontend, so if it's a linking problem it should be ld's.
 
 LD seems to behave absurdly that it expects to resolve symbols.
 e.g.
 a.o provides symbol c, and b.o needs symbol c
 you'd better feed ld with: b.o a.o not a.o b.o


dmd also uses gcc (and hence ld) as linker, so if it is an ld
problem, it'll stay. The behavior you mention above is only
true for library files, AFAIK, not for objects. You should have
all objects before the libraries, though.

Ciao
TomD
Apr 02 2009
parent reply Fawzi Mohamed <fmohamed mac.com> writes:
On 2009-04-02 14:52:40 +0200, TomD <t_demmer nospam.web.de> said:


 davidl Wrote:
 
 [...]

 You're sure that's a linking problem?
 GDC only use DMD frontend, so if it's a linking problem it should be ld's.
 
 LD seems to behave absurdly that it expects to resolve symbols.
 e.g.
 a.o provides symbol c, and b.o needs symbol c
 you'd better feed ld with: b.o a.o not a.o b.o


 
 dmd also uses gcc (and hence ld) as linker, so if it is an ld
 problem, it'll stay. The behavior you mention above is only
 true for library files, AFAIK, not for objects. You should have
 all objects before the libraries, though.
 
 Ciao
 TomD


simply put ld scans for symbols in libraries in the order they appear, 
if liba uases symbolsy from libb you should like them as -L-la -L-lb.
Normally it is not difficult to achieve this, but as workaround you dan 
also tell the linker to recursively search also in the previous 
libraries, this slows the linking, but will allow any order in the 
libraries, even circular dependencies (that you would otherwise need to 
break liking libraries more than once).

Simply pass --start-group *all the libs* --end-group to the linker 
(i.e. -L--start-group to the compiler)
and (if your problem really came from this) it will go away

Fawzi
Apr 02 2009
parent reply Qian Xu <quian.xu stud.tu-ilmenau.de> writes:
Fawzi Mohamed wrote:

 
 simply put ld scans for symbols in libraries in the order they appear,
 if liba uases symbolsy from libb you should like them as -L-la -L-lb.
 Normally it is not difficult to achieve this, but as workaround you dan
 also tell the linker to recursively search also in the previous
 libraries, this slows the linking, but will allow any order in the
 libraries, even circular dependencies (that you would otherwise need to
 break liking libraries more than once).
 
 Simply pass --start-group *all the libs* --end-group to the linker
 (i.e. -L--start-group to the compiler)
 and (if your problem really came from this) it will go away
 



I tried the following command
"gdc  -Wl,--start-group  Foo.o Foo2.o Bar/Foo3.o Bar/Foo4.o  -Wl,--end-group 
-o main -Ltango/lib -lgtango"

But it still does not work. The same problem.

The following is a dump of the actual error message

----------------------
build_trunk_build_1926/build_componenttest.out-`.text._D5tango4util10collection4impl16AbstractIterator80__T16AbstractIteratorTC9timetable6common3src10controller6entity7Vehicle7VehicleZ16AbstractIterator9remainingMFZk'
referenced in section
`.text.__t24__D5tango4util10collection4impl16AbstractIterator80__T16AbstractIteratorTC9timetable6common3src10controller6entity7Vehicle7VehicleZ16AbstractIterator9remainingMFZk[__t24__D5tango4util10collection4impl16AbstractIterator80__T16AbstractIteratorTC9timetable6common3src10controller6entity7Vehicle7VehicleZ16AbstractIterator9remainingMFZk]'
of
build/boost/timetable/common/src/controller/importer/ImportVehicleController_1.o:
defined in discarded section
`.text._D5tango4util10collection4impl16AbstractIterator80__T16AbstractIteratorTC9timetable6common3src10controller6entity7Vehicle7VehicleZ16AbstractIterator9remainingMFZk[_D5tango4util10collection4impl16AbstractIterator80__T16AbstractIteratorTC9timetable6common3src10controller6entity7Vehicle7VehicleZ16AbstractIterator9remainingMFZk]'
of
build/boost/timetable/common/src/controller/importer/ImportVehicleController_1.o
build_trunk_build_1926/build_componenttest.out:collect2: ld returned 1 exit
status
----------------------
Apr 02 2009
parent reply TomD <t_demmer nospam.web.de> writes:
Qian Xu Wrote:

[...]

 I tried the following command
 "gdc  -Wl,--start-group  Foo.o Foo2.o Bar/Foo3.o Bar/Foo4.o  -Wl,--end-group 
 -o main -Ltango/lib -lgtango"
 
 But it still does not work. The same problem.
 
 The following is a dump of the actual error message
 
 ----------------------
 build_trunk_build_1926/build_componenttest.out-`.text._D5tango4util10collection4impl16AbstractIterator80__T16AbstractIteratorTC9timetable6common3src10controller6entity7Vehicle7VehicleZ16AbstractIterator9remainingMFZk'
 referenced in section
 `.text.__t24__D5tango4util10collection4impl16AbstractIterator80__T16AbstractIteratorTC9timetable6common3src10controller6entity7Vehicle7VehicleZ16AbstractIterator9remainingMFZk[__t24__D5tango4util10collection4impl16AbstractIterator80__T16AbstractIteratorTC9timetable6common3src10controller6entity7Vehicle7VehicleZ16AbstractIterator9remainingMFZk]'
 of
 build/boost/timetable/common/src/controller/importer/ImportVehicleController_1.o:
 defined in discarded section
 `.text._D5tango4util10collection4impl16AbstractIterator80__T16AbstractIteratorTC9timetable6common3src10controller6entity7Vehicle7VehicleZ16AbstractIterator9remainingMFZk[_D5tango4util10collection4impl16AbstractIterator80__T16AbstractIteratorTC9timetable6common3src10controller6entity7Vehicle7VehicleZ16AbstractIterator9remainingMFZk]'
 of
 build/boost/timetable/common/src/controller/importer/ImportVehicleController_1.o
 build_trunk_build_1926/build_componenttest.out:collect2: ld returned 1 exit
 status
 ----------------------


As far as I can say from the error, ld discards a section. I just cannot
understand why. 

The info file of ld says:

***
3.6.7 Output Section Discarding
-------------------------------

The linker will not create output sections with no contents.  This is
for convenience when referring to input sections that may or may not be
present in any of the input files.  For example:
     .foo : { *(.foo) }
   will only create a `.foo' section in the output file if there is a
`.foo' section in at least one input file, and if the input sections
are not all empty.  Other link script directives that allocate space in
an output section will also create the output section.
****
Somehow, section ._D5tango4util10collection4impl16AbstractIterator80
(tango.util.collection.impl.AbstractIterator timetable.commonSource...)
get discarded.

Is there anything weird with this thing, e.g. inlined but referenced
in an external modulue? Can you rebuild all without optimization?

Ciao
TomD
(PS: Thanks to Fawzi, I did not know the grouping command
of ld)
Apr 02 2009
parent reply Qian Xu <quian.xu stud.tu-ilmenau.de> writes:
TomD wrote:


 As far as I can say from the error, ld discards a section. I just cannot
 understand why.
 



If my project is compiled with "--debug" flag, and then there is no
link-problem.
Apr 03 2009
parent reply TomD <t_demmer nospam.web.de> writes:
After a couple of miniutes googling around this seems
to be a bug in ld. Some aritlcles from 2007 or so 
recommend to downgrade to binutils 2.15 from 2.16.
*If* your installed binutils is 2.16, you may give it a try.

Ciao
Tom
Apr 03 2009
parent TomD <t_demmer nospam.web.de> writes:
TomD Wrote:


 After a couple of miniutes googling around this seems
 to be a bug in ld. Some aritlcles from 2007 or so 
 recommend to downgrade to binutils 2.15 from 2.16.
 *If* your installed binutils is 2.16, you may give it a try.
 
 Ciao
 Tom


After a bit harder googling I found 
http://www.cygwin.com/ml/binutils/2007-09/msg00096.html
******
On Wed, Sep 05, 2007 at 12:19:05PM -0500, Albert Chin wrote:
[about references to local symbols in discarded sections causing a
link error]

 Is the behavior in binutils-2.17+ correct?


Well, the linker can't guarantee to fix up the reference to point to
the proper location in the kept section.  Just considering the linker
in isolation, I think it warrants an error.  However, I thought this
gcc bug had been fixed long ago, but if this is occurring with 4.0.2,
perhaps we ought to downgrade the error to a warning again.  (I'm
assuming that the reference was from C++ code rather than assembly,
and that your .a was actually compiled with 4.0.2)


 If so, how do we work around this issue?


Pass --noinhibit-exec to the linker.
****

HTH,
Ciao
TomD
Apr 04 2009