let's say i have 'libA', 'libB' and 'Project'
- libB uses libA
- Project uses libB

under Windows (32 bit, OMF objects, Digital Mars linker, so the standard setup):
-------------

* libA is compiled with: dmd sourceA.d -lib
* libB is compiled with: dmd sourceB.d -lib -I<pathToSourceA>
* Project is compiled with: dmd sourceProject.d libA.lib libB.lib -I<pathToSourceA> -I<pathToSourceB>

and it just works fine

under Linux (64 bit, also the standard setup):
-----------

The same procedure fails with some messages ("undefined this and that...") but
if i link "incrementaly" (so i link libA in libB) it works:

* libA is compiled with: dmd sourceA.d -lib
* libB is compiled with: dmd sourceB.d libA.a -lib -I<pathToSourceA>
* Project is compiled with: dmd sourceProject.d libA.a libB.a -I<pathToSourceA> -I<pathToSourceB>


So the Q: Is this difference normal ?


Why I ask this ?
The problem is that I've made a change to Coedit recently that is based on the way it works on Windows:
https://github.com/BBasile/Coedit/blob/master/src/ce_nativeproject.pas#L373
That does that: libraries files are only passed when the output binary must contain everything (so an executable). The problem is verified with a lib which uses two Derelict libs that use themselves DerelictUtil...I could just put a compiler switch in the .pas source to have the right behaviour according to the platform but i'd like an explanation...this difference looks weird.

On Thursday, 27 August 2015 at 02:50:58 UTC, BBasile wrote:
> So the Q: Is this difference normal ?
the win OMF & linux COFF "thing" maybe ?

On Thursday, 27 August 2015 at 03:17:57 UTC, BBasile wrote:
> On Thursday, 27 August 2015 at 02:50:58 UTC, BBasile wrote:
>> So the Q: Is this difference normal ?
> the win OMF & linux COFF "thing" maybe ?

If I understand your problem description correctly, the culprit is likely the order in which the libraries are passed to the linker. The way the GNU linker works requires any library X that depends on any library Y to be placed before library Y on the command line.

So, given your example, if libB uses symbols from libA, then it needs to come before libA on the command line.

dmd sourceProject.d -L-lB -L-lA -I<pathToSourceA> -I<pathToSourceB>

You can also see this when you use the pragma(lib) feature, as dmd passes the libraries to the linker in the order in which it found the pragmas.

On Thursday, 27 August 2015 at 02:50:58 UTC, BBasile wrote:
> So the Q: Is this difference normal ?

Yes, it is a feature the Windows format supports but the Linux one doesn't. On Linux, you need to list the libraries on the command line again.

On Thursday, 27 August 2015 at 04:57:14 UTC, Adam D. Ruppe wrote:
> On Thursday, 27 August 2015 at 02:50:58 UTC, BBasile wrote:
>> So the Q: Is this difference normal ?
>
> Yes, it is a feature the Windows format supports but the Linux one doesn't. On Linux, you need to list the libraries on the command line again.

This is a bit what i wanted to hear, so I hope that your answer is not pernicious.

Strangely, I've forgot to tell that in the original post, if I use the procedure that works for Linux but on Windows, I get some "multiple definition of ..." error messages. Because in this case the *.lib are really linked at each step.