rpath usage

if I want to embed two directory /dir1 and /dir2 as rpath, shall I
use:

  1. gcc -Wl,-rpath,/dir1,/dir2
  2. gcc -Wl,-rpath=/dir1:/dir2
  3. gcc -Wl,-rpath,/dir1:/dir2
    or something else?

thanks!

anybody?
master Colin? David? cdm?

fliu@mail.vipstage.com wrote:

if I want to embed two directory /dir1 and /dir2 as rpath, shall I
use:

  1. gcc -Wl,-rpath,/dir1,/dir2
  2. gcc -Wl,-rpath=/dir1:/dir2
  3. gcc -Wl,-rpath,/dir1:/dir2
    or something else?

thanks!

I could test but I got bitten in the past :slight_smile:
test showing it works doesn’t necessarily means that’s correct and the
program may fail in the next release :slight_smile: cough mm cough map …


Kris Warkentin <kewarken@qnx.com> wrote:

Well, you could probably test it fairly easily and let the rest of us
know… > :wink:

If I were going to guess, I’d think ‘:’ since that’s your standard pathsep
character on unix but for all we know, it may even be system dependent.

cheers,

Kris

fliu@mail.vipstage.com> > wrote in message news:bae2h6$5nf$> 1@inn.qnx.com> …
anybody?
master Colin? David? cdm?

fliu@mail.vipstage.com > wrote:
if I want to embed two directory /dir1 and /dir2 as rpath, shall I
use:

  1. gcc -Wl,-rpath,/dir1,/dir2
  2. gcc -Wl,-rpath=/dir1:/dir2
  3. gcc -Wl,-rpath,/dir1:/dir2
    or something else?

thanks!

Well, you could probably test it fairly easily and let the rest of us
know… :wink:

If I were going to guess, I’d think ‘:’ since that’s your standard pathsep
character on unix but for all we know, it may even be system dependent.

cheers,

Kris

<fliu@mail.vipstage.com> wrote in message news:bae2h6$5nf$1@inn.qnx.com

anybody?
master Colin? David? cdm?

fliu@mail.vipstage.com > wrote:
if I want to embed two directory /dir1 and /dir2 as rpath, shall I
use:

  1. gcc -Wl,-rpath,/dir1,/dir2
  2. gcc -Wl,-rpath=/dir1:/dir2
  3. gcc -Wl,-rpath,/dir1:/dir2
    or something else?

thanks!

Experimentally, both
-Wl,-rpath,"/dir1:/dir2"
and
-Wl,-rpath,/dir1 -Wl,-rpath,/dir2

appear to work. You can check the result by looking into ELF header of the
executable.

– igor

<fliu@mail.vipstage.com> wrote in message news:bae3kv$6q1$1@inn.qnx.com

I could test but I got bitten in the past > :slight_smile:
test showing it works doesn’t necessarily means that’s correct and the
program may fail in the next release > :slight_smile: > cough mm cough map …


Kris Warkentin <> kewarken@qnx.com> > wrote:
Well, you could probably test it fairly easily and let the rest of us
know… > :wink:

If I were going to guess, I’d think ‘:’ since that’s your standard
pathsep
character on unix but for all we know, it may even be system dependent.

cheers,

Kris

fliu@mail.vipstage.com> > wrote in message
news:bae2h6$5nf$> 1@inn.qnx.com> …
anybody?
master Colin? David? cdm?

fliu@mail.vipstage.com > wrote:
if I want to embed two directory /dir1 and /dir2 as rpath, shall I
use:

  1. gcc -Wl,-rpath,/dir1,/dir2
  2. gcc -Wl,-rpath=/dir1:/dir2
  3. gcc -Wl,-rpath,/dir1:/dir2
    or something else?

thanks!

I read the document and it mentioned “-Wl,-rpath,/dir1 -Wl,-rpath,/dir2” will work.
I just want to avoid doing -Wl,-rpath twice.
for
-Wl,-rpath,"/dir1:/dir2"
are you sure the quote is necessary?

Igor Kovalenko <kovalenko@attbi.com> wrote:

Experimentally, both
-Wl,-rpath,"/dir1:/dir2"
and
-Wl,-rpath,/dir1 -Wl,-rpath,/dir2

appear to work. You can check the result by looking into ELF header of the
executable.

– igor

fliu@mail.vipstage.com> > wrote in message news:bae3kv$6q1$> 1@inn.qnx.com> …

I could test but I got bitten in the past > :slight_smile:
test showing it works doesn’t necessarily means that’s correct and the
program may fail in the next release > :slight_smile: > cough mm cough map …


Kris Warkentin <> kewarken@qnx.com> > wrote:
Well, you could probably test it fairly easily and let the rest of us
know… > :wink:

If I were going to guess, I’d think ‘:’ since that’s your standard
pathsep
character on unix but for all we know, it may even be system dependent.

cheers,

Kris

fliu@mail.vipstage.com> > wrote in message
news:bae2h6$5nf$> 1@inn.qnx.com> …
anybody?
master Colin? David? cdm?

fliu@mail.vipstage.com > wrote:
if I want to embed two directory /dir1 and /dir2 as rpath, shall I
use:

  1. gcc -Wl,-rpath,/dir1,/dir2
  2. gcc -Wl,-rpath=/dir1:/dir2
  3. gcc -Wl,-rpath,/dir1:/dir2
    or something else?

thanks!

Kris Warkentin <kewarken@qnx.com> wrote:

Well, you could probably test it fairly easily and let the rest of us
know… > :wink:

my test shows the following three all embeds /dir1 and /dir2 into
the RPATH of the executable:
-Wl,-rpath=/dir1:/dir2
-Wl,-rpath,/dir1:/dir2
-Wl,-rpath,/dir1 -Wl,-rpath,/dir2

Colin, you there?

Well, all rpath does is embed the string into the elf dynamic section. Use
the double -Wl and look at what string the linker is putting into the binary
with objdump -x. If the linker is using ‘:’ as a separator, you can take
that as being authoritative. As far as changing in the future, don’t count
on it. These are pretty standard tools that go back a long way and there’s
certainly no way anyone would change that. This is gnu ld and if they
changed, then every dynamic linker on every system it supports would have to
change as well as their native linkers. That would seem to be unlikely.

cheers,

Kris

<fliu@mail.vipstage.com> wrote in message news:baeoe6$s0b$1@inn.qnx.com

Kris Warkentin <> kewarken@qnx.com> > wrote:
Well, you could probably test it fairly easily and let the rest of us
know… > :wink:

my test shows the following three all embeds /dir1 and /dir2 into
the RPATH of the executable:
-Wl,-rpath=/dir1:/dir2
-Wl,-rpath,/dir1:/dir2
-Wl,-rpath,/dir1 -Wl,-rpath,/dir2

Colin, you there?

Incidentally, if you look at our libc (under ldd) you can find the code that
searches the path for libs. The order is rpath, ld_library_path, and the
system libpath. The separator is ‘:’.

cheers,

Kris

“Kris Warkentin” <kewarken@qnx.com> wrote in message
news:bafppr$eo$1@nntp.qnx.com

Well, all rpath does is embed the string into the elf dynamic section.
Use
the double -Wl and look at what string the linker is putting into the
binary
with objdump -x. If the linker is using ‘:’ as a separator, you can take
that as being authoritative. As far as changing in the future, don’t
count
on it. These are pretty standard tools that go back a long way and
there’s
certainly no way anyone would change that. This is gnu ld and if they
changed, then every dynamic linker on every system it supports would have
to
change as well as their native linkers. That would seem to be unlikely.

cheers,

Kris

fliu@mail.vipstage.com> > wrote in message news:baeoe6$s0b$> 1@inn.qnx.com> …
Kris Warkentin <> kewarken@qnx.com> > wrote:
Well, you could probably test it fairly easily and let the rest of us
know… > :wink:

my test shows the following three all embeds /dir1 and /dir2 into
the RPATH of the executable:
-Wl,-rpath=/dir1:/dir2
-Wl,-rpath,/dir1:/dir2
-Wl,-rpath,/dir1 -Wl,-rpath,/dir2

Colin, you there?

ldd uses DT_RPATH the same was as LD_LIBRARY_PATH, so the standard
‘:’ separator is correct.

fliu@mail.vipstage.com wrote:

Kris Warkentin <> kewarken@qnx.com> > wrote:
Well, you could probably test it fairly easily and let the rest of us
know… > :wink:

my test shows the following three all embeds /dir1 and /dir2 into
the RPATH of the executable:
-Wl,-rpath=/dir1:/dir2
-Wl,-rpath,/dir1:/dir2
-Wl,-rpath,/dir1 -Wl,-rpath,/dir2

Colin, you there?


cburgess@qnx.com

I don’t think that version of ldd properly supported rpath.

Kris Warkentin <kewarken@qnx.com> wrote:

Incidentally, if you look at our libc (under ldd) you can find the code that
searches the path for libs. The order is rpath, ld_library_path, and the
system libpath. The separator is ‘:’.

cheers,

Kris

“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:bafppr$eo$> 1@nntp.qnx.com> …
Well, all rpath does is embed the string into the elf dynamic section.
Use
the double -Wl and look at what string the linker is putting into the
binary
with objdump -x. If the linker is using ‘:’ as a separator, you can take
that as being authoritative. As far as changing in the future, don’t
count
on it. These are pretty standard tools that go back a long way and
there’s
certainly no way anyone would change that. This is gnu ld and if they
changed, then every dynamic linker on every system it supports would have
to
change as well as their native linkers. That would seem to be unlikely.

cheers,

Kris

fliu@mail.vipstage.com> > wrote in message news:baeoe6$s0b$> 1@inn.qnx.com> …
Kris Warkentin <> kewarken@qnx.com> > wrote:
Well, you could probably test it fairly easily and let the rest of us
know… > :wink:

my test shows the following three all embeds /dir1 and /dir2 into
the RPATH of the executable:
-Wl,-rpath=/dir1:/dir2
-Wl,-rpath,/dir1:/dir2
-Wl,-rpath,/dir1 -Wl,-rpath,/dir2

Colin, you there?


cburgess@qnx.com

Colin Burgess <cburgess@qnx.com> wrote:

ldd uses DT_RPATH the same was as LD_LIBRARY_PATH, so the standard
‘:’ separator is correct.

my test showed both
-Wl,-rpath=/dir1:/dir2
-Wl,-rpath,/dir1:/dir2
worked. can I assume = or , are correct?


fliu@mail.vipstage.com > wrote:
Kris Warkentin <> kewarken@qnx.com> > wrote:
Well, you could probably test it fairly easily and let the rest of us
know… > :wink:

my test shows the following three all embeds /dir1 and /dir2 into
the RPATH of the executable:
-Wl,-rpath=/dir1:/dir2
-Wl,-rpath,/dir1:/dir2
-Wl,-rpath,/dir1 -Wl,-rpath,/dir2

Colin, you there?


cburgess@qnx.com

fliu@mail.vipstage.com wrote:

Colin Burgess <> cburgess@qnx.com> > wrote:
ldd uses DT_RPATH the same was as LD_LIBRARY_PATH, so the standard
‘:’ separator is correct.

my test showed both
-Wl,-rpath=/dir1:/dir2
-Wl,-rpath,/dir1:/dir2
worked. can I assume = or , are correct?

Yes. Isn’t GNU ld wonderful? You can tell it almost anything… ;v)

fliu@mail.vipstage.com > wrote:
Kris Warkentin <> kewarken@qnx.com> > wrote:
Well, you could probably test it fairly easily and let the rest of us
know… > :wink:

my test shows the following three all embeds /dir1 and /dir2 into
the RPATH of the executable:
-Wl,-rpath=/dir1:/dir2
-Wl,-rpath,/dir1:/dir2
-Wl,-rpath,/dir1 -Wl,-rpath,/dir2

Colin, you there?


cburgess@qnx.com


cburgess@qnx.com