Hi,

So I got this working, I would just like to see if I have done this correctly or if it's just working out of a fluke. I am using Visual D. Lets say I have four projects:

Library 1: Common Library
Library 2: Base Service Library - Dependent on the Common Library.
Library 3: More Specified Service Library - Dependent on the base service library.
Final Exe - Dependent on Library 3.

^^^

That's how I set up the linking in Visual D. Everything builds. But should the final exe try to link against all 3 libraries, library 3 link to library 1 & 2 and library 2 link to library 1 (also builds)? Or is the single dependence chain I created work without quirks?

Is there a functional difference at the end of the day?

On Saturday, 25 November 2017 at 22:18:52 UTC, A Guy With a Question wrote:

>
> That's how I set up the linking in Visual D. Everything builds. But should the final exe try to link against all 3 libraries, library 3 link to library 1 & 2 and library 2 link to library 1 (also builds)? Or is the single dependence chain I created work without quirks?
>
> Is there a functional difference at the end of the day?

You don't link static libraries with each other. They're just collections of object files intended to be linked with an executable or a DLL. Order doesn't matter for optlink or the MS linker, but other linkers, such as ld (which is commonly used with GCC) require the libraries be passed in according to dependencies, e.g. dependent libraries come before their dependencies. Not sure if the LLVM linker retains that behavior.

On Saturday, 25 November 2017 at 22:31:10 UTC, Mike Parker wrote:
> On Saturday, 25 November 2017 at 22:18:52 UTC, A Guy With a Question wrote:
>
>>
>> That's how I set up the linking in Visual D. Everything builds. But should the final exe try to link against all 3 libraries, library 3 link to library 1 & 2 and library 2 link to library 1 (also builds)? Or is the single dependence chain I created work without quirks?
>>
>> Is there a functional difference at the end of the day?
>
> You don't link static libraries with each other. They're just collections of object files intended to be linked with an executable or a DLL. Order doesn't matter for optlink or the MS linker, but other linkers, such as ld (which is commonly used with GCC) require the libraries be passed in according to dependencies, e.g. dependent libraries come before their dependencies. Not sure if the LLVM linker retains that behavior.

Yes. That also worked when I tried it.

On Saturday, 25 November 2017 at 22:36:32 UTC, A Guy With a Question wrote:
> On Saturday, 25 November 2017 at 22:31:10 UTC, Mike Parker wrote:
>> On Saturday, 25 November 2017 at 22:18:52 UTC, A Guy With a Question wrote:
>>
>>>
>>> That's how I set up the linking in Visual D. Everything builds. But should the final exe try to link against all 3 libraries, library 3 link to library 1 & 2 and library 2 link to library 1 (also builds)? Or is the single dependence chain I created work without quirks?
>>>
>>> Is there a functional difference at the end of the day?
>>
>> You don't link static libraries with each other. They're just collections of object files intended to be linked with an executable or a DLL. Order doesn't matter for optlink or the MS linker, but other linkers, such as ld (which is commonly used with GCC) require the libraries be passed in according to dependencies, e.g. dependent libraries come before their dependencies. Not sure if the LLVM linker retains that behavior.
>
> Yes. That also worked when I tried it.

Also when I said library, I'm actually talking about the dlls that are produced. I essentially have four projects in Visual D. Each produces a binary. 3 produce dlls and the final created the end exe.

On Saturday, 25 November 2017 at 22:40:49 UTC, A Guy With a Question wrote:
> On Saturday, 25 November 2017 at 22:36:32 UTC, A Guy With a Question wrote:
>> On Saturday, 25 November 2017 at 22:31:10 UTC, Mike Parker wrote:
>>> On Saturday, 25 November 2017 at 22:18:52 UTC, A Guy With a Question wrote:
>>>
>>>>
>>>> That's how I set up the linking in Visual D. Everything builds. But should the final exe try to link against all 3 libraries, library 3 link to library 1 & 2 and library 2 link to library 1 (also builds)? Or is the single dependence chain I created work without quirks?
>>>>
>>>> Is there a functional difference at the end of the day?
>>>
>>> You don't link static libraries with each other. They're just collections of object files intended to be linked with an executable or a DLL. Order doesn't matter for optlink or the MS linker, but other linkers, such as ld (which is commonly used with GCC) require the libraries be passed in according to dependencies, e.g. dependent libraries come before their dependencies. Not sure if the LLVM linker retains that behavior.
>>
>> Yes. That also worked when I tried it.
>
> Also when I said library, I'm actually talking about the dlls that are produced. I essentially have four projects in Visual D. Each produces a binary. 3 produce dlls and the final created the end exe.

Actually ignore that last comment, they are producing libs not dlls. Funny how all three ways of linking work...

On Saturday, 25 November 2017 at 22:43:30 UTC, A Guy With a Question wrote:

> Actually ignore that last comment, they are producing libs not dlls. Funny how all three ways of linking work...

On Windows, when building a DLL, compilers typically produce an "import library" alongside it, which has a .lib extension like static libraries. The executable links with the import library, but needs to have the DLL on the system path at runtime.

On 2017-11-25 23:31, Mike Parker wrote:

> You don't link static libraries with each other. They're just collections of object files intended to be linked with an executable or a DLL. Order doesn't matter for optlink or the MS linker, but other linkers, such as ld (which is commonly used with GCC) require the libraries be passed in according to dependencies, e.g. dependent libraries come before their dependencies. Not sure if the LLVM linker retains that behavior.

For completeness:

For "ld" on macOS the order does not matter. For "ld" on Linux the order does matter, but, if necessary, the following flags can be used to link libraries in any order: "--start-group" and "--end-group". Those flag will cause the linker to search the libraries repeatedly to resolve undefined symbols.

-- 
/Jacob Carlborg

On Sunday, 26 November 2017 at 11:15:58 UTC, Jacob Carlborg wrote:
> On 2017-11-25 23:31, Mike Parker wrote:
>
> For "ld" on macOS the order does not matter. For "ld" on Linux the order does matter, but, if necessary, the following flags can be used to link libraries in any order: "--start-group" and "--end-group". Those flag will cause the linker to search the libraries repeatedly to resolve undefined symbols.

These flags should be  passed to ld by DMD i think

On Sunday, 11 February 2018 at 01:38:41 UTC, b2.temp wrote:
> On Sunday, 26 November 2017 at 11:15:58 UTC, Jacob Carlborg wrote:
>> On 2017-11-25 23:31, Mike Parker wrote:
>>
>> For "ld" on macOS the order does not matter. For "ld" on Linux the order does matter, but, if necessary, the following flags can be used to link libraries in any order: "--start-group" and "--end-group". Those flag will cause the linker to search the libraries repeatedly to resolve undefined symbols.
>
> These flags should be  passed to ld by DMD i think

The flags could be put before and after this loop:
https://github.com/dlang/dmd/blob/master/src/dmd/link.d#L602