• BBasile (33/33) Aug 26 2015 let's say i have 'libA', 'libB' and 'Project'
• BBasile (2/3) Aug 26 2015 the win OMF & linux COFF "thing" maybe ?
• Mike Parker (13/16) Aug 26 2015 If I understand your problem description correctly, the culprit
• Adam D. Ruppe (4/5) Aug 26 2015 Yes, it is a feature the Windows format supports but the Linux
• BBasile (7/12) Aug 27 2015 This is a bit what i wanted to hear, so I hope that your answer

"BBasile" <basile.burg gmx.com> writes:

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.

"BBasile" <bb.temp gmx.com> writes:

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 ?

"Mike Parker" <aldacron gmail.com> writes:

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.

"Adam D. Ruppe" <destructionator gmail.com> writes:

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.

"BBasile" <bb.temp gmx.com> writes:

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.