February 26, 2016 Re: Bootstrapping build | ||||
---|---|---|---|---|
| ||||
Attachments:
| 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 Re: Bootstrapping build | ||||
---|---|---|---|---|
| ||||
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 Re: Bootstrapping build | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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 Re: Bootstrapping build | ||||
---|---|---|---|---|
| ||||
Posted in reply to Joakim | 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 Re: Bootstrapping build | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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 Re: Bootstrapping build | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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 Re: Bootstrapping build | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marco Leise | 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 Re: Bootstrapping build | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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 |
Copyright © 1999-2021 by the D Language Foundation