February 26, 2016
On Thu, 2016-02-25 at 19:36 +0100, David Nadlinger via digitalmars-d- ldc wrote:
> 
[…]

> Doing that wouldn't be difficult in itself. For example, we do
> something
> like the former already for the binary releases where we need to
> find
> the libconfig .so, but can't be sure of the install path:
> https://github.com/ldc-developers/ldc-scripts/blob/987fe9d4abccd48fd4
> 5f1c3112b8faf6bfc82aeb/ldc2-packaging/2-build-ldc.sh#L41
> And for the latter, one could just add the appropriate linker flag
> to
> ldc2.conf.

OK, so at least it isn't total "pie in the sky" thinking on my part. 
> We should definitely do something like that if/when we ship Linux
> binary
> packages with shared libraries included. However, I'm not so sure
> whether it should be the default. Trying to play cute tricks instead
> of
> relying on the standard way of doing things tends not to end all
> that
> well. And it seems as if we'd need to exclude builds standard
> installation directories even if we did always hard-code the rpath,
> as
> that is for example forbidden in the Fedora packaging guidelines.

I guess this is going to end up being a judgement call based on cost/benefit.

If 98% of builds do not use CMAKE_INSTALL_PREFIX then taking a while to satisfy the 2% could be seen as lacking in sufficient benefit. My gut reaction though is that if it isn't masses of effort, then covering this 2% case is likely to have sufficient "it all works out of the box" positive vibes to be worth it.

I'll see if I can do some research on this over the weekend. No promises though, it is a Six Nations weekend.

-- 
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



February 26, 2016
Hi Russel,

On 26 Feb 2016, at 11:55, Russel Winder via digitalmars-d-ldc wrote:
> I guess this is going to end up being a judgement call based on
> cost/benefit.
> […]
> I'll see if I can do some research on this over the weekend.

That would be great! My worry is not so much the (small) bit of extra engineering effort, it's that adding rpaths might have unintended consequences or cause more confusion among users than it resolves. This is merely based on the observation that I can't recall ever using a development toolchain that would set rpaths by default (apart from old libtooled projects, but it was done there only as part of the install step).

On another note, it's not just a question of setting CMAKE_INSTALL_PREFIX vs. not setting it. For example, setting any rpaths on -DCMAKE_INSTALL_PREFIX=/usr would be pretty unexpected, and from the looks of it would also break the Fedora packages.

I suppose one way to find out how to go about this would be to just add the rpath and see if anybody complains. How does DMD handle this?

 — David
February 26, 2016
On Friday, 26 February 2016 at 18:19:39 UTC, David Nadlinger wrote:
> I suppose one way to find out how to go about this would be to just add the rpath and see if anybody complains. How does DMD handle this?

Looks like ddmd statically links against druntime/phobos, probably best for ldc with the ddmd frontend to do the same.


February 26, 2016
On 26 Feb 2016, at 20:16, Joakim via digitalmars-d-ldc wrote:
> Looks like ddmd statically links against druntime/phobos, probably best for ldc with the ddmd frontend to do the same.

That's certainly the thing to do, but I was more wondering about how they are shipping a shared druntime/Phobos, i.e. if/how they deal with the path issue for client code linked against a shared standard library.

 — David
February 27, 2016
On Friday, 26 February 2016 at 20:01:24 UTC, David Nadlinger wrote:
> On 26 Feb 2016, at 20:16, Joakim via digitalmars-d-ldc wrote:
>> Looks like ddmd statically links against druntime/phobos, probably best for ldc with the ddmd frontend to do the same.
>
> That's certainly the thing to do, but I was more wondering about how they are shipping a shared druntime/Phobos, i.e. if/how they deal with the path issue for client code linked against a shared standard library.

It appears they don't handle it, ie it's up to you to specify an rpath for shared phobos, as ddmd statically links against phobos by default:

https://dlang.org/dll-linux.html#dso7

I just tried it out locally and can confirm the additional rpath flag was necessary, it only built and ran like this with a local ddmd 2.070:

./dmd/linux/bin64/dmd -defaultlib=libphobos2.so -L-rpath=./dmd/linux/lib64/ dmd/samples/d/sieve.d
March 11, 2016
Am Fri, 26 Feb 2016 21:01:24 +0100
schrieb David Nadlinger via digitalmars-d-ldc
<digitalmars-d-ldc@puremagic.com>:

> On 26 Feb 2016, at 20:16, Joakim via digitalmars-d-ldc wrote:
> > Looks like ddmd statically links against druntime/phobos, probably best for ldc with the ddmd frontend to do the same.
> 
> That's certainly the thing to do, but I was more wondering about how they are shipping a shared druntime/Phobos, i.e. if/how they deal with the path issue for client code linked against a shared standard library.
> 
>   — David

On Gentoo, I setup -rpath in dmd.conf during installation. It
is necessary anyways if multiple installations of DMD are to
coexist on the same system, because the ABI is not really set
in stone. That way I can painlessly install shared GtkD
libraries for both dmd-2.069 and dmd-2.070 for example.
That dmd.conf also contains flags to link with a shared Phobos2
by default. --gc-sections does not work yet in that setup, but
I have not noticed any other issues. I consider shared
libraries important going forward with the C++ replacement
idea that Dlang started with.

-- 
Marco

March 12, 2016
On 11 Mar 2016, at 19:17, Marco Leise via digitalmars-d-ldc wrote:
> I consider shared
> libraries important going forward with the C++ replacement
> idea that Dlang started with.

I certainly agree with that.

The only question is how to make the experience as smooth as possible for all users. Our current plan would be to add an rpath to the config file generated by the install target then? We could provide a CMake switch to disable that to make life easy for distro packagers, where an explicit rpath would be undesirable.

 — David

April 29, 2016
Am Sat, 12 Mar 2016 16:18:00 +0000
schrieb David Nadlinger via digitalmars-d-ldc
<digitalmars-d-ldc@puremagic.com>:

> On 11 Mar 2016, at 19:17, Marco Leise via digitalmars-d-ldc wrote:
> > I consider shared
> > libraries important going forward with the C++ replacement
> > idea that Dlang started with.
> 
> I certainly agree with that.
> 
> The only question is how to make the experience as smooth as possible for all users. Our current plan would be to add an rpath to the config file generated by the install target then? We could provide a CMake switch to disable that to make life easy for distro packagers, where an explicit rpath would be undesirable.
> 
>   — David

I did it that way for dmd on Gentoo. And for ldc there is
already /opt/ldc2-<version>/lib{32,64}/
For distributions on which you can only install one system
wide D compiler at a time the rpath is not needed. On those
you'd have either a dmd, gdc or ldc environment with a
specific compiler and phobos version for all D software.

-- 
Marco

1 2
Next ›   Last »