Adding default RUNPATH to compiled binaries

Adding default RUNPATH to compiled binaries

[Maciej (Matchek) Bliziński]

I've seen this topic discussed many times. The problem seems to come
up every time gcc is compiled with prefix != /usr/bin. The way to
reproduce it is simple:

echo "int main() {}" > t.c; g++ -o t t.c ; ./t

The result:

ld.so.1: t: fatal: libstdc++.so.6: open failed: No such file or directory
Killed

I just had a bug filed against my gcc packages[1].  I did some
research, and I found information about a number of approaches, which
aren't really consistent and none of them is explained or
self-explanatory.

In some instances GCC sources were patched[2], in other the spec
information was dumped, modified and placed where it would be taken as
the default[3].

What's the recommended way of doing it?

Maciej

[1] https://www.opencsw.org/mantis/view.php?id=4875
[2] http://tinyurl.com/cvbt6e9 [pkgbuild.svn.sourceforge.net]
[3] http://www.mingw.org/wiki/SpecsFileHOWTO

Re: Adding default RUNPATH to compiled binaries

[Jonathan Wakely]

2011/12/11 Maciej (Matchek) Bliziński:
> What's the recommended way of doing it?

There's no single best option suitable for everyone.

There are some alternatives listed in the documentation:

http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dynamic_or_shared.html#manual.intro.using.linkage.dynamic

http://gcc.gnu.org/faq.html#rpath

Personally I usually ensure my makefiles will use -Wl,-rpath during
linking to set RPATH in the executables.

Re: Adding default RUNPATH to compiled binaries

[Marc Glisse]

On Sun, 11 Dec 2011, Maciej (Matchek) BliziĂąski wrote:

> I've seen this topic discussed many times. The problem seems to come
> up every time gcc is compiled with prefix != /usr/bin. The way to
> reproduce it is simple:
>
> echo "int main() {}" > t.c; g++ -o t t.c ; ./t
>
> The result:
>
> ld.so.1: t: fatal: libstdc++.so.6: open failed: No such file or directory
> Killed
>
> I just had a bug filed against my gcc packages[1].  I did some
> research, and I found information about a number of approaches, which
> aren't really consistent and none of them is explained or
> self-explanatory.
>
> In some instances GCC sources were patched[2], in other the spec
> information was dumped, modified and placed where it would be taken as
> the default[3].
>
> What's the recommended way of doing it?

Whether you patch the builtin specs or provide a specs file that overrides 
them doesn't really matter, it is roughly equivalent. What does matter and 
requires some thought is what you want to put in there. Make sure you 
handle -m32/-m64. Determine if you always want to do something or only 
when -lgcc_s is there. Chose between passing ld a -R flag or a -c flag. 
etc.

-- 
Marc Glisse

Re: Adding default RUNPATH to compiled binaries

[Ian Lance Taylor]

"Maciej (Matchek) Bliziński" <maciej@opencsw.org> writes:

> I've seen this topic discussed many times. The problem seems to come
> up every time gcc is compiled with prefix != /usr/bin. The way to
> reproduce it is simple:
>
> echo "int main() {}" > t.c; g++ -o t t.c ; ./t
>
> The result:
>
> ld.so.1: t: fatal: libstdc++.so.6: open failed: No such file or directory
> Killed
>
> I just had a bug filed against my gcc packages[1].  I did some
> research, and I found information about a number of approaches, which
> aren't really consistent and none of them is explained or
> self-explanatory.
>
> In some instances GCC sources were patched[2], in other the spec
> information was dumped, modified and placed where it would be taken as
> the default[3].
>
> What's the recommended way of doing it?


It depends.  One good approach is to add the appropriate directory to
/etc/ld.so.conf and run ldconfig.

Ian

Re: Adding default RUNPATH to compiled binaries

[Marc Glisse]

On Sun, 11 Dec 2011, Ian Lance Taylor wrote:

> "Maciej (Matchek) Bliziński" <maciej@opencsw.org> writes:
>
>> I've seen this topic discussed many times. The problem seems to come
>> up every time gcc is compiled with prefix != /usr/bin. The way to
>> reproduce it is simple:
>>
>> echo "int main() {}" > t.c; g++ -o t t.c ; ./t
>>
>> The result:
>>
>> ld.so.1: t: fatal: libstdc++.so.6: open failed: No such file or directory
>> Killed
>>
>> I just had a bug filed against my gcc packages[1].  I did some
>> research, and I found information about a number of approaches, which
>> aren't really consistent and none of them is explained or
>> self-explanatory.
>>
>> In some instances GCC sources were patched[2], in other the spec
>> information was dumped, modified and placed where it would be taken as
>> the default[3].
>>
>> What's the recommended way of doing it?
>
>
> It depends.  One good approach is to add the appropriate directory to
> /etc/ld.so.conf and run ldconfig.

Well it is solaris, so the equivalent is described in the manpage for 
crle(1).

-- 
Marc Glisse

Re: Adding default RUNPATH to compiled binaries

[Jonathan Wakely]

2011/12/11 Marc Glisse:
> On Sun, 11 Dec 2011, Maciej (Matchek) Bliziński wrote:
>
>> I've seen this topic discussed many times. The problem seems to come
>> up every time gcc is compiled with prefix != /usr/bin. The way to
>> reproduce it is simple:
>>
>> echo "int main() {}" > t.c; g++ -o t t.c ; ./t
>>
>> The result:
>>
>> ld.so.1: t: fatal: libstdc++.so.6: open failed: No such file or directory
>> Killed
>>
>> I just had a bug filed against my gcc packages[1].  I did some
>> research, and I found information about a number of approaches, which
>> aren't really consistent and none of them is explained or
>> self-explanatory.
>>
>> In some instances GCC sources were patched[2], in other the spec
>> information was dumped, modified and placed where it would be taken as
>> the default[3].
>>
>> What's the recommended way of doing it?
>
>
> Whether you patch the builtin specs or provide a specs file that overrides
> them doesn't really matter, it is roughly equivalent. What does matter and
> requires some thought is what you want to put in there. Make sure you handle
> -m32/-m64. Determine if you always want to do something or only when -lgcc_s
> is there. Chose between passing ld a -R flag or a -c flag. etc.

Right, that's partly why the best solution for a single-user system
(where any sane choice is reasonable and can be changed at will) is
different to the best solution for a firm-wide rollout for hundreds of
users across multiple continents (where consistency matters and it's
harder to change once hundreds of makefiles are relying on a certain
behavour) and different again to a packager distributing GCC to a wide
variety of users (where noone knows what everyone wants or how they'll
use it.)

I tend to install it with the default behaviour and leave it to users
to decide how to link, as that gives the most flexibility, but you
have to be prepared to repeatedly explain how to solve the runtime
problems.

Re: Adding default RUNPATH to compiled binaries

[Maciej (Matchek) Bliziński]

2011/12/12 Jonathan Wakely <jwakely.gcc@gmail.com>:
> Right, that's partly why the best solution for a single-user system
> (where any sane choice is reasonable and can be changed at will) is
> different to the best solution for a firm-wide rollout for hundreds of
> users across multiple continents (where consistency matters and it's
> harder to change once hundreds of makefiles are relying on a certain
> behavour) and different again to a packager distributing GCC to a wide
> variety of users (where noone knows what everyone wants or how they'll
> use it.)

This is a good point.  In this case, I'm working on GCC packages, so I
need to find the balance between flexibility for users, and usability in
a simple case.

> I tend to install it with the default behaviour and leave it to users
> to decide how to link, as that gives the most flexibility, but you
> have to be prepared to repeatedly explain how to solve the runtime
> problems.

The GCC distributed from GCC so far did not set the -R flag by
default.  All our package build recipes add -R/opt/csw/lib to the
RPATH.  Occasionally, there's a software project with a build system
ignoring LDFLAGS, so we need to resort to LD_OPTIONS.

Let's say that what we want, is that --prefix=/opt/csw, and that the
following example works (without making any modifications to the
invocations), meaning that the program finds libstdc++.

echo "int main() {}" > t.c; g++ -o t t.c ; ./t

...and that we don't use crle.  I just polled my peers at #opencsw on
Freenode, and this kind of system-wide modification is a recipe for
things ranging from annoyances to disasters.  I can write more about
this, for now let's just say that this isn't one of the options.

What options do we have now, and what's the best way of implementing them?

Maciej