Thread overview |
---|
April 02, 2009 Link Problem | ||||
---|---|---|---|---|
| ||||
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 |
April 02, 2009 Re: Link Problem | ||||
---|---|---|---|---|
| ||||
Posted in reply to Qian Xu | 在 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!
|
April 02, 2009 Re: Link Problem | ||||
---|---|---|---|---|
| ||||
Posted in reply to davidl |
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
|
April 02, 2009 Re: Link Problem | ||||
---|---|---|---|---|
| ||||
Posted in reply to davidl | 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 :) |
April 02, 2009 Re: Link Problem | ||||
---|---|---|---|---|
| ||||
Posted in reply to davidl | 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
|
April 02, 2009 Re: Link Problem | ||||
---|---|---|---|---|
| ||||
Posted in reply to TomD | 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
|
April 02, 2009 Re: Link Problem | ||||
---|---|---|---|---|
| ||||
Posted in reply to Fawzi Mohamed | 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 ---------------------- |
April 02, 2009 Re: Link Problem | ||||
---|---|---|---|---|
| ||||
Posted in reply to Qian Xu | 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) |
April 03, 2009 Re: Link Problem | ||||
---|---|---|---|---|
| ||||
Posted in reply to TomD | 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.
|
April 03, 2009 Re: Link Problem | ||||
---|---|---|---|---|
| ||||
Posted in reply to Qian Xu | 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 |
Copyright © 1999-2021 by the D Language Foundation