Jump to page: 1 2
Thread overview
Re: Bootstrapping build
Feb 23, 2016
Russel Winder
Feb 23, 2016
Johan Engelen
Feb 23, 2016
David Nadlinger
Feb 24, 2016
Russel Winder
Feb 25, 2016
Joakim
Feb 25, 2016
David Nadlinger
Feb 25, 2016
Russel Winder
Feb 25, 2016
David Nadlinger
Feb 25, 2016
Russel Winder
Feb 25, 2016
David Nadlinger
Feb 26, 2016
Russel Winder
Feb 26, 2016
David Nadlinger
Feb 26, 2016
Joakim
Feb 26, 2016
David Nadlinger
Feb 27, 2016
Joakim
Mar 11, 2016
Marco Leise
Mar 12, 2016
David Nadlinger
Apr 29, 2016
Marco Leise
February 23, 2016
On Tue, 2016-02-23 at 09:55 +0000, Russel Winder wrote:
> For the last few days I have been building LDC with the previous version of LDC which seemed to work well. However I just ######## things up. This means I need to do a full rebuild from scratch, which necessitates a bootstrap. I suspect:
> 
> http://wiki.dlang.org/Building_LDC_from_source
> 
> is a wee bit out of date. Are there notes somewhere I can follow and report back on?

Less panic now :-) I went back to backups and rebuilt from there.

I can report that the 2.070 branch builds fine and the compiler does a great job.

The only downside is the lack of path processing in linking which means you have to set LD_LIBRARY_PATH all the time.

-- 
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 23, 2016
On Tuesday, 23 February 2016 at 10:25:41 UTC, Russel Winder wrote:
> On Tue, 2016-02-23 at 09:55 +0000, Russel Winder wrote:
>> For the last few days I have been building LDC with the previous version of LDC which seemed to work well. However I just ######## things up. This means I need to do a full rebuild from scratch, which necessitates a bootstrap. I suspect:
>> 
>> http://wiki.dlang.org/Building_LDC_from_source
>> 
>> is a wee bit out of date. Are there notes somewhere I can follow and report back on?
>
> Less panic now :-) I went back to backups and rebuilt from there.
>
> I can report that the 2.070 branch builds fine and the compiler does a great job.

:-)
Perhaps you can help updating
http://wiki.dlang.org/Building_LDC_from_source
a little?  ;) :P
Thanks!

February 23, 2016
On 23 Feb 2016, at 11:25, Russel Winder via digitalmars-d-ldc wrote:
> The only downside is the lack of path processing in linking which means
> you have to set LD_LIBRARY_PATH all the time.

I don't think this would be an LDC issue, though, as we just forward the arguments to the system gcc – or is it?

As I'm sure you know, to avoid this issue you can either specify an rpath during linking or put the shared libraries into a well-known directory (/lib, /usr/lib or one listed in ld.so.conf).

 — David
February 24, 2016
On Tue, 2016-02-23 at 20:14 +0100, David Nadlinger via digitalmars-d- ldc wrote:
> […]
> 
> As I'm sure you know, to avoid this issue you can either specify an rpath during linking or put the shared libraries into a well-known directory (/lib, /usr/lib or one listed in ld.so.conf).

The /lib and /usr/lib solution are not feasible in my context as those directories are reserved for package managed things. All my personally build stuff goes into ~/Built. To add this to the ld.so paths seems a bit wrong somehow as the directory /etc/ld.so.conf.d is not really a place for per user things.

I think my point was really that since the LDC build knows where it is going to install ldc2 and the shared objects, it should put the rpath into the installed compiler automatically so as to avoid LD_LIBRARY_PATH being needed to run ldc2.

-- 
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 25, 2016
On Wednesday, 24 February 2016 at 08:05:49 UTC, Russel Winder wrote:
> On Tue, 2016-02-23 at 20:14 +0100, David Nadlinger via digitalmars-d- ldc wrote:
>> […]
>> 
>> As I'm sure you know, to avoid this issue you can either specify an rpath during linking or put the shared libraries into a well-known directory (/lib, /usr/lib or one listed in ld.so.conf).
>
> The /lib and /usr/lib solution are not feasible in my context as those directories are reserved for package managed things. All my personally build stuff goes into ~/Built. To add this to the ld.so paths seems a bit wrong somehow as the directory /etc/ld.so.conf.d is not really a place for per user things.
>
> I think my point was really that since the LDC build knows where it is going to install ldc2 and the shared objects, it should put the rpath into the installed compiler automatically so as to avoid LD_LIBRARY_PATH being needed to run ldc2.

The issue, which David might have missed, is that the ldc binary itself is linked against the phobos shared library that comes with the D compiler that compiles the ddmd frontend in 2.069+, really the druntime portion I guess.  If that shared library is not in a standard path, ie if you just downloaded the dmd tar for linux, ldc won't know where to find it and will fail with a strange error when building druntime.

The solution is to add some logic to the cmake module that finds the D compiler to build ddmd and add that rpath if necessary when linking the ldc executable.  Otherwise, I followed your workaround and defined LD_LIBRARY_PATH.

Good thing you wrote about this as the error is tough to figure out otherwise.
February 25, 2016
On 25 Feb 2016, at 12:05, Joakim via digitalmars-d-ldc wrote:
> The issue, which David might have missed, is that the ldc binary itself is linked against the phobos shared library that comes with the D compiler that compiles the ddmd frontend in 2.069+, really the druntime portion I guess.  If that shared library is not in a standard path, ie if you just downloaded the dmd tar for linux, ldc won't know where to find it and will fail with a strange error when building druntime.

There may be multiple issues here. If I understand Russel correctly, his problem was that he needs to set the library path for executables compiled with LDC. In your case, if I understand correctly, the issue is that the LDC binary itself does not load correctly.

The latter might be a consequence of the fact that the initial D build setup Johan rigged up for us does not actually use the D compiler for linking, but instead tries to guess the library to use. What we should be doing instead is to use the D compiler for the final linking step. Then, all we require is that there is a D compiler installed for which `echo "void main() {}" > foo.d && $DMD foo.d && ./foo` works. If that is not the case, the user needs to fix their setup. We should probably also put that test into the CMake scripts as a sanity check.

 — David
February 25, 2016
On Thu, 2016-02-25 at 17:28 +0100, David Nadlinger via digitalmars-d- ldc wrote:
> […]
> There may be multiple issues here. If I understand Russel correctly,
> his
> problem was that he needs to set the library path for executables
> compiled with LDC. In your case, if I understand correctly, the issue
> is
> that the LDC binary itself does not load correctly.
[…]

Those are indeed the two cases, my grumble was that the ldc2 executable didn't know where it's dependencies were, so very much the second case. The former case is also irritating but much less so.

General executables compiled with ldc2 are one thing but when ldc2 is
compiled with ldc2 and doesn't know where it's libraries are you get
serious "throwing toys out of pram"!

-- 
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 25, 2016
On 25 Feb 2016, at 18:13, Russel Winder via digitalmars-d-ldc wrote:
> General executables compiled with ldc2 are one thing but when ldc2 is
> compiled with ldc2 and doesn't know where it's libraries are you get
> serious "throwing toys out of pram"!

So this is coming back to the dynamic libraries not being on the path after you do "cmake -DBUILD_SHARED_LIBS=ON -DCMAKE_INSTALL_PREFIX=… <ldc>; make install", and is not in any way specific to LDC also being the executable being built?

What would your suggested solution be? I'm not sure what the correct way to address this is, since unless I'm mistaken, exactly the same issue occurs also for any C++ shared library produced by GCC, etc.

 — David

February 25, 2016
On Thu, 2016-02-25 at 18:20 +0100, David Nadlinger via digitalmars-d- ldc wrote:
> […]
> So this is coming back to the dynamic libraries not being on the
> path
> after you do "cmake -DBUILD_SHARED_LIBS=ON -DCMAKE_INSTALL_PREFIX=…
> <ldc>; make install", and is not in any way specific to LDC also
> being
> the executable being built?
> 
> What would your suggested solution be? I'm not sure what the correct
> way
> to address this is, since unless I'm mistaken, exactly the same
> issue
> occurs also for any C++ shared library produced by GCC, etc.

I appreciate this is a non-trivial issue/problem, hopefully my attempt at humour has not implied I believe otherwise.

My thinking is that if the CMAKE_INSTALL_PREFIX has been set then the build should be able to add this with '/lib' as the rpath into the final link of ldc2 and ldmd2. Moreover, ldc2 and ldmd2 themselves could add this as an rpath in the link of any created executables.

However my CMake and ld skills are not great, so this may be "pie in the sky".

-- 
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 25, 2016
Hi Russel,

On 25 Feb 2016, at 18:37, Russel Winder via digitalmars-d-ldc wrote:
> I appreciate this is a non-trivial issue/problem, hopefully my attempt
> at humour has not implied I believe otherwise.

No worries, I definitely didn't pick up any such vibes. In turn, I was just trying to make sure I understand what the problem is in the first place.

> My thinking is that if the CMAKE_INSTALL_PREFIX has been set then the
> build should be able to add this with '/lib' as the rpath into the
> final link of ldc2 and ldmd2. Moreover, ldc2 and ldmd2 themselves could
> add this as an rpath in the link of any created executables.
>
> However my CMake and ld skills are not great, so this may be "pie in
> the sky".

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/987fe9d4abccd48fd45f1c3112b8faf6bfc82aeb/ldc2-packaging/2-build-ldc.sh#L41
And for the latter, one could just add the appropriate linker flag to ldc2.conf.

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.

 — David

« First   ‹ Prev
1 2