Invoking a script with ld-linux.so?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
3
down vote

favorite
2












I just downloaded a tar file that is supposed to include everything required to run a program that we can call some_binary. I extracted it's contents, and I see the following:



  • A binary (let's call it some_binary)

  • A lib folder with various dynamic libraries (.so files) such as /lib/ld-linux-x86-64.so

  • and a shell script called some_binary.sh

The script has the following contents:



#!/bin/bash
`dirname "$0"`/lib/ld-linux-x86-64.so.2 `dirname "$0"`/some_binary "$@"


and running it as ./some_binary.sh some arguments seems to run ./some_binary correctly. Oddly enough, running the following script:



#!/bin/bash
LD_LIBRARY_PATH=$CWD/LIB:$LD_LIBRARY_PATH
./some_binary "$@"


as ./my_script.sh some arguments does not work. It results in relocation errors (undefined symbols), presumably from incorrectly loading the libraries under ./lib



Moreover, running the following two statements from the command line results in segmentation fault:



> LD_LIBRARY_PATH=$CWD/LIB:$LD_LIBRARY_PATH
> ./some_binary some arguments


With this, my questions are:



  1. What does the first script do?

  2. Why do I get different results across these three attempts? and why can't I just add $pwd/lib to LD_LIBRARY_PATH and then run some_binary directly?









share|improve this question























  • Is it a backslash before that second backtick?
    – Runium
    Apr 24 '13 at 2:06










  • @Sukminder. Good catch. Thanks. I had problems typing embedding the command within a code block in the post.
    – Amelio Vazquez-Reina
    Apr 24 '13 at 3:00














up vote
3
down vote

favorite
2












I just downloaded a tar file that is supposed to include everything required to run a program that we can call some_binary. I extracted it's contents, and I see the following:



  • A binary (let's call it some_binary)

  • A lib folder with various dynamic libraries (.so files) such as /lib/ld-linux-x86-64.so

  • and a shell script called some_binary.sh

The script has the following contents:



#!/bin/bash
`dirname "$0"`/lib/ld-linux-x86-64.so.2 `dirname "$0"`/some_binary "$@"


and running it as ./some_binary.sh some arguments seems to run ./some_binary correctly. Oddly enough, running the following script:



#!/bin/bash
LD_LIBRARY_PATH=$CWD/LIB:$LD_LIBRARY_PATH
./some_binary "$@"


as ./my_script.sh some arguments does not work. It results in relocation errors (undefined symbols), presumably from incorrectly loading the libraries under ./lib



Moreover, running the following two statements from the command line results in segmentation fault:



> LD_LIBRARY_PATH=$CWD/LIB:$LD_LIBRARY_PATH
> ./some_binary some arguments


With this, my questions are:



  1. What does the first script do?

  2. Why do I get different results across these three attempts? and why can't I just add $pwd/lib to LD_LIBRARY_PATH and then run some_binary directly?









share|improve this question























  • Is it a backslash before that second backtick?
    – Runium
    Apr 24 '13 at 2:06










  • @Sukminder. Good catch. Thanks. I had problems typing embedding the command within a code block in the post.
    – Amelio Vazquez-Reina
    Apr 24 '13 at 3:00












up vote
3
down vote

favorite
2









up vote
3
down vote

favorite
2






2





I just downloaded a tar file that is supposed to include everything required to run a program that we can call some_binary. I extracted it's contents, and I see the following:



  • A binary (let's call it some_binary)

  • A lib folder with various dynamic libraries (.so files) such as /lib/ld-linux-x86-64.so

  • and a shell script called some_binary.sh

The script has the following contents:



#!/bin/bash
`dirname "$0"`/lib/ld-linux-x86-64.so.2 `dirname "$0"`/some_binary "$@"


and running it as ./some_binary.sh some arguments seems to run ./some_binary correctly. Oddly enough, running the following script:



#!/bin/bash
LD_LIBRARY_PATH=$CWD/LIB:$LD_LIBRARY_PATH
./some_binary "$@"


as ./my_script.sh some arguments does not work. It results in relocation errors (undefined symbols), presumably from incorrectly loading the libraries under ./lib



Moreover, running the following two statements from the command line results in segmentation fault:



> LD_LIBRARY_PATH=$CWD/LIB:$LD_LIBRARY_PATH
> ./some_binary some arguments


With this, my questions are:



  1. What does the first script do?

  2. Why do I get different results across these three attempts? and why can't I just add $pwd/lib to LD_LIBRARY_PATH and then run some_binary directly?









share|improve this question















I just downloaded a tar file that is supposed to include everything required to run a program that we can call some_binary. I extracted it's contents, and I see the following:



  • A binary (let's call it some_binary)

  • A lib folder with various dynamic libraries (.so files) such as /lib/ld-linux-x86-64.so

  • and a shell script called some_binary.sh

The script has the following contents:



#!/bin/bash
`dirname "$0"`/lib/ld-linux-x86-64.so.2 `dirname "$0"`/some_binary "$@"


and running it as ./some_binary.sh some arguments seems to run ./some_binary correctly. Oddly enough, running the following script:



#!/bin/bash
LD_LIBRARY_PATH=$CWD/LIB:$LD_LIBRARY_PATH
./some_binary "$@"


as ./my_script.sh some arguments does not work. It results in relocation errors (undefined symbols), presumably from incorrectly loading the libraries under ./lib



Moreover, running the following two statements from the command line results in segmentation fault:



> LD_LIBRARY_PATH=$CWD/LIB:$LD_LIBRARY_PATH
> ./some_binary some arguments


With this, my questions are:



  1. What does the first script do?

  2. Why do I get different results across these three attempts? and why can't I just add $pwd/lib to LD_LIBRARY_PATH and then run some_binary directly?






shell scripting libraries dynamic-linking






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 24 '13 at 3:00

























asked Apr 23 '13 at 23:47









Amelio Vazquez-Reina

11.9k51124228




11.9k51124228











  • Is it a backslash before that second backtick?
    – Runium
    Apr 24 '13 at 2:06










  • @Sukminder. Good catch. Thanks. I had problems typing embedding the command within a code block in the post.
    – Amelio Vazquez-Reina
    Apr 24 '13 at 3:00
















  • Is it a backslash before that second backtick?
    – Runium
    Apr 24 '13 at 2:06










  • @Sukminder. Good catch. Thanks. I had problems typing embedding the command within a code block in the post.
    – Amelio Vazquez-Reina
    Apr 24 '13 at 3:00















Is it a backslash before that second backtick?
– Runium
Apr 24 '13 at 2:06




Is it a backslash before that second backtick?
– Runium
Apr 24 '13 at 2:06












@Sukminder. Good catch. Thanks. I had problems typing embedding the command within a code block in the post.
– Amelio Vazquez-Reina
Apr 24 '13 at 3:00




@Sukminder. Good catch. Thanks. I had problems typing embedding the command within a code block in the post.
– Amelio Vazquez-Reina
Apr 24 '13 at 3:00










2 Answers
2






active

oldest

votes

















up vote
3
down vote



accepted










The program comes with its own dynamic loader. It's quite rare for programs to need their own dynamic loader: usually the one on your system will work too. This may be necessary if the program was linked against a standard library other than GNU libc or if it was linked against a GNU libc compiled with strange settings.



It may be enough to tell the loader where to find the program's preferred libraries. Your attempt almost does that, but not quite. If LD_LIBRARY_PATH is not already in the environment, then the assignment LD_LIBRARY_PATH=$CWD/LIB:$LD_LIBRARY_PATH only defines a shell variable, not an environment variable, so the program doesn't see a thing. Furthermore, $CWD usually expands to the empty string, you probably meant $PWD or better $(dirname "$0") (i.e. the directory containing the script). Also beware that you used lib and LIB inconsistently in your question. Try



#!/bin/sh
export LD_LIBRARY_PATH="$(dirname "$0")/lib:$LD_LIBRARY_PATH"
exec "$(dirname "$0")/some_binary" "$@"


or better, to avoid having an empty entry at the end of LD_LIBRARY_PATH if it wasn't defined before (this can be bad because an empty entry stands for the current directory, though at the end of the path it's only harmful if a library isn't found where it should be):



#!/bin/sh
export LD_LIBRARY_PATH="$(dirname "$0")/lib:$LD_LIBRARY_PATH"
case "$LD_LIBRARY_PATH" in *:) LD_LIBRARY_PATH=$LD_LIBRARY_PATH%:;; esac
exec "$(dirname "$0")/some_binary" "$@"





share|improve this answer




















  • export LD_LIBRARY_PATH="..." is a BASHISM!!1
    – nodakai
    Sep 12 '16 at 8:51










  • @nodakai No, there's nothing bash-specific (or even ksh/bash/zsh-specific) about it. The scripts in my answer use only POSIX features.
    – Gilles
    Sep 12 '16 at 8:53










  • Hmm. I stand corrected... It seems it's been a part of POSIX for quite a while pubs.opengroup.org/onlinepubs/009696799/utilities/export.html This guy had the same misunderstanding unix.stackexchange.com/questions/193095/…
    – nodakai
    Sep 12 '16 at 9:03

















up vote
-1
down vote













Use patchelf to set the interpreter.



patchelf --set-interpreter /lib/ld-linux-x86-64.so.2 <path-to-clang>





share|improve this answer










New contributor




bashi-bazouk is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

















    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













     

    draft saved


    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f73480%2finvoking-a-script-with-ld-linux-so%23new-answer', 'question_page');

    );

    Post as a guest






























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    3
    down vote



    accepted










    The program comes with its own dynamic loader. It's quite rare for programs to need their own dynamic loader: usually the one on your system will work too. This may be necessary if the program was linked against a standard library other than GNU libc or if it was linked against a GNU libc compiled with strange settings.



    It may be enough to tell the loader where to find the program's preferred libraries. Your attempt almost does that, but not quite. If LD_LIBRARY_PATH is not already in the environment, then the assignment LD_LIBRARY_PATH=$CWD/LIB:$LD_LIBRARY_PATH only defines a shell variable, not an environment variable, so the program doesn't see a thing. Furthermore, $CWD usually expands to the empty string, you probably meant $PWD or better $(dirname "$0") (i.e. the directory containing the script). Also beware that you used lib and LIB inconsistently in your question. Try



    #!/bin/sh
    export LD_LIBRARY_PATH="$(dirname "$0")/lib:$LD_LIBRARY_PATH"
    exec "$(dirname "$0")/some_binary" "$@"


    or better, to avoid having an empty entry at the end of LD_LIBRARY_PATH if it wasn't defined before (this can be bad because an empty entry stands for the current directory, though at the end of the path it's only harmful if a library isn't found where it should be):



    #!/bin/sh
    export LD_LIBRARY_PATH="$(dirname "$0")/lib:$LD_LIBRARY_PATH"
    case "$LD_LIBRARY_PATH" in *:) LD_LIBRARY_PATH=$LD_LIBRARY_PATH%:;; esac
    exec "$(dirname "$0")/some_binary" "$@"





    share|improve this answer




















    • export LD_LIBRARY_PATH="..." is a BASHISM!!1
      – nodakai
      Sep 12 '16 at 8:51










    • @nodakai No, there's nothing bash-specific (or even ksh/bash/zsh-specific) about it. The scripts in my answer use only POSIX features.
      – Gilles
      Sep 12 '16 at 8:53










    • Hmm. I stand corrected... It seems it's been a part of POSIX for quite a while pubs.opengroup.org/onlinepubs/009696799/utilities/export.html This guy had the same misunderstanding unix.stackexchange.com/questions/193095/…
      – nodakai
      Sep 12 '16 at 9:03














    up vote
    3
    down vote



    accepted










    The program comes with its own dynamic loader. It's quite rare for programs to need their own dynamic loader: usually the one on your system will work too. This may be necessary if the program was linked against a standard library other than GNU libc or if it was linked against a GNU libc compiled with strange settings.



    It may be enough to tell the loader where to find the program's preferred libraries. Your attempt almost does that, but not quite. If LD_LIBRARY_PATH is not already in the environment, then the assignment LD_LIBRARY_PATH=$CWD/LIB:$LD_LIBRARY_PATH only defines a shell variable, not an environment variable, so the program doesn't see a thing. Furthermore, $CWD usually expands to the empty string, you probably meant $PWD or better $(dirname "$0") (i.e. the directory containing the script). Also beware that you used lib and LIB inconsistently in your question. Try



    #!/bin/sh
    export LD_LIBRARY_PATH="$(dirname "$0")/lib:$LD_LIBRARY_PATH"
    exec "$(dirname "$0")/some_binary" "$@"


    or better, to avoid having an empty entry at the end of LD_LIBRARY_PATH if it wasn't defined before (this can be bad because an empty entry stands for the current directory, though at the end of the path it's only harmful if a library isn't found where it should be):



    #!/bin/sh
    export LD_LIBRARY_PATH="$(dirname "$0")/lib:$LD_LIBRARY_PATH"
    case "$LD_LIBRARY_PATH" in *:) LD_LIBRARY_PATH=$LD_LIBRARY_PATH%:;; esac
    exec "$(dirname "$0")/some_binary" "$@"





    share|improve this answer




















    • export LD_LIBRARY_PATH="..." is a BASHISM!!1
      – nodakai
      Sep 12 '16 at 8:51










    • @nodakai No, there's nothing bash-specific (or even ksh/bash/zsh-specific) about it. The scripts in my answer use only POSIX features.
      – Gilles
      Sep 12 '16 at 8:53










    • Hmm. I stand corrected... It seems it's been a part of POSIX for quite a while pubs.opengroup.org/onlinepubs/009696799/utilities/export.html This guy had the same misunderstanding unix.stackexchange.com/questions/193095/…
      – nodakai
      Sep 12 '16 at 9:03












    up vote
    3
    down vote



    accepted







    up vote
    3
    down vote



    accepted






    The program comes with its own dynamic loader. It's quite rare for programs to need their own dynamic loader: usually the one on your system will work too. This may be necessary if the program was linked against a standard library other than GNU libc or if it was linked against a GNU libc compiled with strange settings.



    It may be enough to tell the loader where to find the program's preferred libraries. Your attempt almost does that, but not quite. If LD_LIBRARY_PATH is not already in the environment, then the assignment LD_LIBRARY_PATH=$CWD/LIB:$LD_LIBRARY_PATH only defines a shell variable, not an environment variable, so the program doesn't see a thing. Furthermore, $CWD usually expands to the empty string, you probably meant $PWD or better $(dirname "$0") (i.e. the directory containing the script). Also beware that you used lib and LIB inconsistently in your question. Try



    #!/bin/sh
    export LD_LIBRARY_PATH="$(dirname "$0")/lib:$LD_LIBRARY_PATH"
    exec "$(dirname "$0")/some_binary" "$@"


    or better, to avoid having an empty entry at the end of LD_LIBRARY_PATH if it wasn't defined before (this can be bad because an empty entry stands for the current directory, though at the end of the path it's only harmful if a library isn't found where it should be):



    #!/bin/sh
    export LD_LIBRARY_PATH="$(dirname "$0")/lib:$LD_LIBRARY_PATH"
    case "$LD_LIBRARY_PATH" in *:) LD_LIBRARY_PATH=$LD_LIBRARY_PATH%:;; esac
    exec "$(dirname "$0")/some_binary" "$@"





    share|improve this answer












    The program comes with its own dynamic loader. It's quite rare for programs to need their own dynamic loader: usually the one on your system will work too. This may be necessary if the program was linked against a standard library other than GNU libc or if it was linked against a GNU libc compiled with strange settings.



    It may be enough to tell the loader where to find the program's preferred libraries. Your attempt almost does that, but not quite. If LD_LIBRARY_PATH is not already in the environment, then the assignment LD_LIBRARY_PATH=$CWD/LIB:$LD_LIBRARY_PATH only defines a shell variable, not an environment variable, so the program doesn't see a thing. Furthermore, $CWD usually expands to the empty string, you probably meant $PWD or better $(dirname "$0") (i.e. the directory containing the script). Also beware that you used lib and LIB inconsistently in your question. Try



    #!/bin/sh
    export LD_LIBRARY_PATH="$(dirname "$0")/lib:$LD_LIBRARY_PATH"
    exec "$(dirname "$0")/some_binary" "$@"


    or better, to avoid having an empty entry at the end of LD_LIBRARY_PATH if it wasn't defined before (this can be bad because an empty entry stands for the current directory, though at the end of the path it's only harmful if a library isn't found where it should be):



    #!/bin/sh
    export LD_LIBRARY_PATH="$(dirname "$0")/lib:$LD_LIBRARY_PATH"
    case "$LD_LIBRARY_PATH" in *:) LD_LIBRARY_PATH=$LD_LIBRARY_PATH%:;; esac
    exec "$(dirname "$0")/some_binary" "$@"






    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Apr 24 '13 at 2:05









    Gilles

    512k12010151547




    512k12010151547











    • export LD_LIBRARY_PATH="..." is a BASHISM!!1
      – nodakai
      Sep 12 '16 at 8:51










    • @nodakai No, there's nothing bash-specific (or even ksh/bash/zsh-specific) about it. The scripts in my answer use only POSIX features.
      – Gilles
      Sep 12 '16 at 8:53










    • Hmm. I stand corrected... It seems it's been a part of POSIX for quite a while pubs.opengroup.org/onlinepubs/009696799/utilities/export.html This guy had the same misunderstanding unix.stackexchange.com/questions/193095/…
      – nodakai
      Sep 12 '16 at 9:03
















    • export LD_LIBRARY_PATH="..." is a BASHISM!!1
      – nodakai
      Sep 12 '16 at 8:51










    • @nodakai No, there's nothing bash-specific (or even ksh/bash/zsh-specific) about it. The scripts in my answer use only POSIX features.
      – Gilles
      Sep 12 '16 at 8:53










    • Hmm. I stand corrected... It seems it's been a part of POSIX for quite a while pubs.opengroup.org/onlinepubs/009696799/utilities/export.html This guy had the same misunderstanding unix.stackexchange.com/questions/193095/…
      – nodakai
      Sep 12 '16 at 9:03















    export LD_LIBRARY_PATH="..." is a BASHISM!!1
    – nodakai
    Sep 12 '16 at 8:51




    export LD_LIBRARY_PATH="..." is a BASHISM!!1
    – nodakai
    Sep 12 '16 at 8:51












    @nodakai No, there's nothing bash-specific (or even ksh/bash/zsh-specific) about it. The scripts in my answer use only POSIX features.
    – Gilles
    Sep 12 '16 at 8:53




    @nodakai No, there's nothing bash-specific (or even ksh/bash/zsh-specific) about it. The scripts in my answer use only POSIX features.
    – Gilles
    Sep 12 '16 at 8:53












    Hmm. I stand corrected... It seems it's been a part of POSIX for quite a while pubs.opengroup.org/onlinepubs/009696799/utilities/export.html This guy had the same misunderstanding unix.stackexchange.com/questions/193095/…
    – nodakai
    Sep 12 '16 at 9:03




    Hmm. I stand corrected... It seems it's been a part of POSIX for quite a while pubs.opengroup.org/onlinepubs/009696799/utilities/export.html This guy had the same misunderstanding unix.stackexchange.com/questions/193095/…
    – nodakai
    Sep 12 '16 at 9:03












    up vote
    -1
    down vote













    Use patchelf to set the interpreter.



    patchelf --set-interpreter /lib/ld-linux-x86-64.so.2 <path-to-clang>





    share|improve this answer










    New contributor




    bashi-bazouk is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.





















      up vote
      -1
      down vote













      Use patchelf to set the interpreter.



      patchelf --set-interpreter /lib/ld-linux-x86-64.so.2 <path-to-clang>





      share|improve this answer










      New contributor




      bashi-bazouk is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.



















        up vote
        -1
        down vote










        up vote
        -1
        down vote









        Use patchelf to set the interpreter.



        patchelf --set-interpreter /lib/ld-linux-x86-64.so.2 <path-to-clang>





        share|improve this answer










        New contributor




        bashi-bazouk is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.









        Use patchelf to set the interpreter.



        patchelf --set-interpreter /lib/ld-linux-x86-64.so.2 <path-to-clang>






        share|improve this answer










        New contributor




        bashi-bazouk is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.









        share|improve this answer



        share|improve this answer








        edited Oct 1 at 13:05









        Goro

        7,02252965




        7,02252965






        New contributor




        bashi-bazouk is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.









        answered Oct 1 at 12:49









        bashi-bazouk

        1




        1




        New contributor




        bashi-bazouk is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.





        New contributor





        bashi-bazouk is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.






        bashi-bazouk is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.



























             

            draft saved


            draft discarded















































             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f73480%2finvoking-a-script-with-ld-linux-so%23new-answer', 'question_page');

            );

            Post as a guest













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Bahrain

            Postfix configuration issue with fips on centos 7; mailgun relay