On 19 Jun 2017, at 17:25, Russel Winder via digitalmars-d-ldc wrote:
> On Linux, both DMD and LDC appear to handle rpath with the option:
>
> 	-L-rpath=/path/to/location/of/shared/object.so
>
> on OSX (El Capitan) I have LDC working but only by using:
>
> 	-L-Wl,rpath,/path/to/location/of/shared/object.so
>
> However nothing I have tried works for DMD. Anyone any suggestions?

LDC recognises options starting with "-Wl," and passes them to the gcc driver rather than prefixing them with -Xlinker. However, this should be equivalent to just leaving off the -Wl, entirely like in your first example. Have a look at the linker command line (ldc2/dmd -v) to see what is going on; there is no magic involved in invoking the linker. Similarly, you can have the gcc driver display the ld command invoked.

Just as a general hint in case you don't know them already, `otool -L` and `install_name_tool` are also useful for dealing with shared libraries on OS X. Also note that D shared libraries are not supported by DMD on OS X yet, if that is what you are after.

 — David

On Mon, 2017-06-19 at 18:05 +0100, David Nadlinger via digitalmars-d- ldc wrote:
> […]
> LDC recognises options starting with "-Wl," and passes them to the
> gcc
> driver rather than prefixing them with -Xlinker. However, this should
> be
> equivalent to just leaving off the -Wl, entirely like in your first
> example. Have a look at the linker command line (ldc2/dmd -v) to see
> what is going on; there is no magic involved in invoking the linker.
> Similarly, you can have the gcc driver display the ld command
> invoked.

I am in a bad position to continue proper testing as I have somewhat suddenly switched form MacPorts to Homebrew – I am not sure when I tried this, I fear in the MacPorts period which I can no longer test.

> Just as a general hint in case you don't know them already, `otool
> -L`
> and `install_name_tool` are also useful for dealing with shared
> libraries on OS X. Also note that D shared libraries are not
> supported
> by DMD on OS X yet, if that is what you are after.

I had thought shared libraries on OSX were supported by DMD now, but clearly the rpath stuff is not. I am guessing gdc 6.3.0 doesn't have shared library support on OSX.

Whilst I don't actually use OSX by choice, yay for LDC. :-)

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Mon, 2017-06-19 at 18:05 +0100, David Nadlinger via digitalmars-d- ldc wrote:
> […]
> LDC recognises options starting with "-Wl," and passes them to the
> gcc
> driver rather than prefixing them with -Xlinker. However, this should
> be
> equivalent to just leaving off the -Wl, entirely like in your first
> example. Have a look at the linker command line (ldc2/dmd -v) to see
> what is going on; there is no magic involved in invoking the linker.
> Similarly, you can have the gcc driver display the ld command
> invoked.

I am in a bad position to continue proper testing as I have somewhat suddenly switched form MacPorts to Homebrew – I am not sure when I tried this, I fear in the MacPorts period which I can no longer test.

> Just as a general hint in case you don't know them already, `otool
> -L`
> and `install_name_tool` are also useful for dealing with shared
> libraries on OS X. Also note that D shared libraries are not
> supported
> by DMD on OS X yet, if that is what you are after.

I had thought shared libraries on OSX were supported by DMD now, but clearly the rpath stuff is not. I am guessing gdc 6.3.0 doesn't have shared library support on OSX.

Whilst I don't actually use OSX by choice, yay for LDC. :-)

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Hi Russel,

On 19 Jun 2017, at 20:09, Russel Winder via digitalmars-d-ldc wrote:
> I had thought shared libraries on OSX were supported by DMD now, but
> clearly the rpath stuff is not.

With rpath being a linker concept, there isn't really such a thing as a compiler not supporting "rpath stuff". Proper shared library support in D needs support code in druntime to integrate with the garbage collector, thread initialization, etc. To my knowledge, DMD currently doesn't do any of that on OS X.

What has changed somewhat recently is the way DMD implements TLS on OS X. Now it uses the default system facilities for it, which makes it easier to integrate with shared libraries (but requires 10.7+). Basically, all that is needed is somebody to sit down and port my work for LDC to DMD.

> I am guessing gdc 6.3.0 doesn't have shared library support on OSX.

To my knowledge, it doesn't, and hasn't been developed or tested for OS X for a while now.

> Whilst I don't actually use OSX by choice, yay for LDC. :-)

Indeed – if you are after full platform support, LDC is probably the compiler of choice.

Best regards,
David

On Tuesday, 20 June 2017 at 15:27:37 UTC, David Nadlinger wrote:

> Indeed – if you are after full platform support, LDC is probably the compiler of choice.

Does LDC now have support for Windows shared libraries? If so, I must have been doing something wrong when I failed.

On 20 Jun 2017, at 18:44, bachmeier via digitalmars-d-ldc wrote:
> On Tuesday, 20 June 2017 at 15:27:37 UTC, David Nadlinger wrote:
>
>> Indeed – if you are after full platform support, LDC is probably the compiler of choice.
>
> Does LDC now have support for Windows shared libraries? If so, I must have been doing something wrong when I failed.

As far as I am aware, no compiler has seamless support for DLLs right now (see e.g. Benjamin Thaut's talk from last year's DConf). If the current half-baked DLL support is harder to use from LDC than from DMD, it's certainly something that can be fixed quite easily – the question is just whether it's worth it.

 — David

On Wednesday, 21 June 2017 at 21:19:44 UTC, David Nadlinger wrote:

> As far as I am aware, no compiler has seamless support for DLLs right now (see e.g. Benjamin Thaut's talk from last year's DConf). If the current half-baked DLL support is harder to use from LDC than from DMD, it's certainly something that can be fixed quite easily – the question is just whether it's worth it.
>
>  — David

It's easy enough to create a DLL with LDC, but C programs can't find those functions. I don't use Windows so not a problem for me. Life will be easier for folks using Docker.

On Thursday, 22 June 2017 at 11:00:52 UTC, bachmeier wrote:
> On Wednesday, 21 June 2017 at 21:19:44 UTC, David Nadlinger wrote:
>
>> As far as I am aware, no compiler has seamless support for DLLs right now (see e.g. Benjamin Thaut's talk from last year's DConf). If the current half-baked DLL support is harder to use from LDC than from DMD, it's certainly something that can be fixed quite easily – the question is just whether it's worth it.
>>
>>  — David
>
> It's easy enough to create a DLL with LDC, but C programs can't find those functions.

Nope, that should definitely work (exporting/importing functions via `export` visibility). Just verified with LDC 1.3-beta2 on Win64:

D:
import core.stdc.stdio;
export extern(C) void exportedFoo() { printf("exportedFoo()\n"); }

C:
extern "C" void exportedFoo();
int main(int argc, char** argv)
{
    exportedFoo();
    return 0;
}

ldc2 -shared dmodule.d => generates dmodule.{dll,lib,exp}
cl cppmodule.cpp dmodule.lib => generates cppmodule.exe relying on dmodule.dll

Produces the expected output.

As David mentioned, being able to use a single shared runtime (druntime/Phobos DLLs) for multiple D binary modules and getting full C++ DLL interop to work is a whole different beast, requiring among other things a language change (`export`: from visibility to stand-alone attribute).

On Thursday, 22 June 2017 at 18:18:29 UTC, kinke wrote:

> Nope, that should definitely work (exporting/importing functions via `export` visibility). Just verified with LDC 1.3-beta2 on Win64:
>
> D:
> import core.stdc.stdio;
> export extern(C) void exportedFoo() { printf("exportedFoo()\n"); }
>
> C:
> extern "C" void exportedFoo();
> int main(int argc, char** argv)
> {
>     exportedFoo();
>     return 0;
> }
>
> ldc2 -shared dmodule.d => generates dmodule.{dll,lib,exp}
> cl cppmodule.cpp dmodule.lib => generates cppmodule.exe relying on dmodule.dll
>
> Produces the expected output.
>
> As David mentioned, being able to use a single shared runtime (druntime/Phobos DLLs) for multiple D binary modules and getting full C++ DLL interop to work is a whole different beast, requiring among other things a language change (`export`: from visibility to stand-alone attribute).

Thanks! Turns out it was user error: I didn't know about the need for export. I added it and now everything works. What a pleasant surprise.

On Thursday, 22 June 2017 at 19:19:51 UTC, bachmeier wrote:
> Thanks! Turns out it was user error: I didn't know about the need for export. I added it and now everything works. What a pleasant surprise.

It's needed on Windows in general, for DMD too. Support has been added in LDC v1.1 and mentioned in the release notes. https://github.com/ldc-developers/ldc/releases/tag/v1.1.0