Is RPATH being ignored? - SGI

This is a discussion on Is RPATH being ignored? - SGI ; I'm attempting to compile OpenSSH 3.7.1p2 under IRIX 6.5.17f. Yes, I know it exists on freeware.sgi.com, but that's beside the point. Anyhow, I'm compiling it with -rpath to specify the location of OpenSSL on the machine. This seems to work; ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Is RPATH being ignored?

  1. Is RPATH being ignored?


    I'm attempting to compile OpenSSH 3.7.1p2 under IRIX 6.5.17f. Yes, I know
    it exists on freeware.sgi.com, but that's beside the point. Anyhow, I'm
    compiling it with -rpath to specify the location of OpenSSL on the machine.
    This seems to work; according to an elfdump -L, the resulting binary
    contains the requested path. Here's a snippet from ssh-keygen:

    [28] NEEDED libcrypto.so.0.9.6
    [29] NEEDED libc.so.1
    [30] SYMLIB 0x10003b24
    [31] RPATH /usr/local/ssl/lib
    [32] TIMSTAMP Nov 1 02:20:26 2003

    However, when I attempt to run the binary I get a "Cannot Successfully map
    soname blah blah blah" error. The weird thing is, I have old (3.5p1)
    binaries compiled the same way that work just fine. Again, snippet from
    ssh-keygen:

    [28] NEEDED libcrypto.so.0.9.6
    [29] NEEDED libc.so.1
    [30] SYMLIB 0x100038dc
    [31] RPATH /usr/local/ssl/lib
    [32] TIMSTAMP Mar 2 02:41:01 2003

    The old binary works just fine, the new one croaks. But I can't see
    what's different, or what would have changed... is there something else I
    should be checking to get to the bottom of this? LD_LIBRARY_PATH isn't
    set (hence the reason for using RPATH in the first place), and I'd rather
    not resort to that even though it would fix it. Also, I know copying the
    needed library (libcrypto in this case) to someplace like /usr/lib32 would
    do it as well, but again I want to have RPATH heeded at runtime. Compiler
    version is 7.3.1.3m. Also this is on an R5000 O2, though I doubt any of
    that matters.

    Any suggestions/pointers/advice in this matter would be greatly
    appreciated. Thanks!

    Bryan


  2. Re: Is RPATH being ignored?

    The Hurdy Gurdy Man wrote:
    >
    > I'm attempting to compile OpenSSH 3.7.1p2 under IRIX 6.5.17f. Yes, I know
    > it exists on freeware.sgi.com, but that's beside the point. Anyhow, I'm
    > compiling it with -rpath to specify the location of OpenSSL on the machine.
    > This seems to work; according to an elfdump -L, the resulting binary
    > contains the requested path. Here's a snippet from ssh-keygen:
    >
    > [28] NEEDED libcrypto.so.0.9.6
    > [29] NEEDED libc.so.1
    > [30] SYMLIB 0x10003b24
    > [31] RPATH /usr/local/ssl/lib
    > [32] TIMSTAMP Nov 1 02:20:26 2003
    >
    > However, when I attempt to run the binary I get a "Cannot Successfully map
    > soname blah blah blah" error.


    Does the SONAME field of your /usr/local/ssl/lib/libcrypto.so match
    "libcrypto.so.0.9.6"?

    --
    albert chin

  3. Re: Is RPATH being ignored?

    Albert Chin-A-Young wrote:

    > Does the SONAME field of your /usr/local/ssl/lib/libcrypto.so match
    > "libcrypto.so.0.9.6"?


    Looks like it does:

    [26] NEEDED libc.so.1
    [27] SYMLIB 0x5ff23dd0
    [28] SONAME libcrypto.so.0.9.6
    [29] TIMSTAMP Oct 25 05:23:48 2002
    [30] CHECKSUM 0x8897ac3f

    So it's probably not that... I'm way stumped by this one. It just doesn't
    make sense. I hope I can get to the bottom of this... I'd hate to see it
    crop up on another, more critical system. Thanks for the suggestion,
    though.

    Bryan

  4. Re: Is RPATH being ignored?

    In article ,
    The Hurdy Gurdy Man wrote:
    >
    >I'm attempting to compile OpenSSH 3.7.1p2 under IRIX 6.5.17f. Yes, I know
    >it exists on freeware.sgi.com, but that's beside the point. Anyhow, I'm
    >compiling it with -rpath to specify the location of OpenSSL on the machine.
    >This seems to work; according to an elfdump -L, the resulting binary
    >contains the requested path. Here's a snippet from ssh-keygen:
    >
    >[28] NEEDED libcrypto.so.0.9.6
    >[29] NEEDED libc.so.1
    >[30] SYMLIB 0x10003b24
    >[31] RPATH /usr/local/ssl/lib
    >[32] TIMSTAMP Nov 1 02:20:26 2003
    >
    >However, when I attempt to run the binary I get a "Cannot Successfully map
    >soname blah blah blah" error. The weird thing is, I have old (3.5p1)
    >binaries compiled the same way that work just fine. Again, snippet from
    >ssh-keygen:
    >
    >[28] NEEDED libcrypto.so.0.9.6
    >[29] NEEDED libc.so.1
    >[30] SYMLIB 0x100038dc
    >[31] RPATH /usr/local/ssl/lib
    >[32] TIMSTAMP Mar 2 02:41:01 2003
    >
    >The old binary works just fine, the new one croaks. But I can't see
    >what's different, or what would have changed... is there something else I
    >should be checking to get to the bottom of this? LD_LIBRARY_PATH isn't
    >set (hence the reason for using RPATH in the first place), and I'd rather
    >not resort to that even though it would fix it. Also, I know copying the
    >needed library (libcrypto in this case) to someplace like /usr/lib32 would
    >do it as well, but again I want to have RPATH heeded at runtime. Compiler
    >version is 7.3.1.3m. Also this is on an R5000 O2, though I doubt any of
    >that matters.


    >Any suggestions/pointers/advice in this matter would be greatly
    >appreciated. Thanks!


    RPATH is honored. Even in setuid apps (not that ssh would be setuid).

    While I have no idea what the problem is, I would suggest
    setenv __RLDN32_PATH /usr/lib32/rld.debug
    setenv _RLD_ARGS "-v -log /tmp/rldlog"
    (assuming the app is n32, hence __RLDN32_PATH suggested).
    and rerun the failing test. You will get additional details
    like the list of paths tried using rld.debug.

    Regards,
    David B. Anderson davea@sgi.com http://reality.sgiweb.org/davea

  5. Re: Is RPATH being ignored?

    In article , The Hurdy Gurdy Man writes:
    |>
    |> However, when I attempt to run the binary I get a "Cannot Successfully map
    |> soname blah blah blah" error.

    Which soname can it not map?


    --
    --------- Gordon Lack --------------- gml4410@ggr.co.uk ------------
    This message *may* reflect my personal opinion. It is *not* intended
    to reflect those of my employer, or anyone else.

  6. Re: Is RPATH being ignored?

    Lack Mr G M wrote:

    > Which soname can it not map?


    Sorry, I guess I didn't make that explicitly clear in my original posting,
    although other people seemed to understand what I was getting at. The
    library in question that it cannot seem to find is libcrypto.so.0.9.6,
    part of the OpenSSL distribution, and the only library being used by the
    application (OpenSSH) that does not reside in a default location, hence
    the usage of RPATH.

    Bryan

  7. Re: Is RPATH being ignored?

    David Anderson wrote:
    > While I have no idea what the problem is, I would suggest
    > setenv __RLDN32_PATH /usr/lib32/rld.debug
    > setenv _RLD_ARGS "-v -log /tmp/rldlog"
    > (assuming the app is n32, hence __RLDN32_PATH suggested).
    > and rerun the failing test. You will get additional details
    > like the list of paths tried using rld.debug.


    Aha! Thank you! This is the nudge I needed. Turns out that what was
    going on was that ssh-keygen wasn't the binary generating the message... it
    was calling a second binary, ssh-rand-helper, which was the thing not able
    to find the library. And the reason it couldn't find the library was
    because apparently ssh-keygen has an interesting way of picking out where
    it gets the path for ssh-rand-helper, and for some reason or another it was
    calling one of the other test versions I had lying around in trying to
    decipher this that was not compiled with RPATH set to the library location.
    So after learning that it was this other binary having the problem, it
    became easier to figure out the nature of the error. Thank you very much
    for tossing a clue my way, it enabled me to solve the mystery!

    Bryan

  8. Re: Is RPATH being ignored?

    "The Hurdy Gurdy Man" wrote in message
    news:RFJpb.3246$n6.1225@nwrddc03.gnilink.net...
    > Lack Mr G M wrote:
    >
    > > Which soname can it not map?

    >
    > Sorry, I guess I didn't make that explicitly clear in my original posting,
    > although other people seemed to understand what I was getting at. The
    > library in question that it cannot seem to find is libcrypto.so.0.9.6,
    > part of the OpenSSL distribution, and the only library being used by the
    > application (OpenSSH) that does not reside in a default location, hence
    > the usage of RPATH.
    >
    > Bryan


    Did you try to just use the configure
    switch --with-ssl-dir=/usr/local/ssl/lib? This would seem to be the simpler
    solution.

    --
    Ryan Curtis
    rcurtis@kistleraero.com



  9. Re: Is RPATH being ignored?

    Ryan Curtis wrote:

    > Did you try to just use the configure switch
    > --with-ssl-dir=/usr/local/ssl/lib? This would seem to be the simpler
    > solution.


    It would seem that way, but in my experience it isn't. I did specify that
    option during compilation... the distribution won't even compile if you
    don't specify it (unless of course it can find the required OpenSSL
    libraries and includes in a standard location, which it won't in this
    case). However, just specifying that command line option won't do it.
    It'll compile just fine, but after you install the binaries and attempt to
    run them they'll choke when they are unable to locate the shared libraries
    required for execution as proven by the other compiled versions I had
    lying around for testing which caused the problem I encountered. You need
    to either specify the path to the libraries (if they aren't in a standard
    location, which in this case they aren't) using the -rpath flag or else
    you need to have LD_LIBRARY_PATH or one of its relatives set in your
    environment to point to the libraries. Personally I find the -rpath flag
    to be a cleaner solution, and so I go with that. But again, the
    --with-ssl-dir flag alone isn't sufficient... that'll just add some paths
    to locate include files and libraries necessary for compilation. It'd be
    nice if the configuration tool were smart enough to determine if you are
    compiling using libraries outside the normal search path and add the
    -rpath flag as required, but I've never seen that happen before. Granted
    I don't compile tons of software these days, but whenever I do I seem to
    run into this problem.

    Bryan


+ Reply to Thread