Invoking a script with ld-linux.so?
Clash Royale CLAN TAG#URR8PPP
up vote
3
down vote
favorite
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:
- What does the first script do?
- Why do I get different results across these three attempts? and why can't I just add
$pwd/lib
toLD_LIBRARY_PATH
and then runsome_binary
directly?
shell scripting libraries dynamic-linking
add a comment |Â
up vote
3
down vote
favorite
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:
- What does the first script do?
- Why do I get different results across these three attempts? and why can't I just add
$pwd/lib
toLD_LIBRARY_PATH
and then runsome_binary
directly?
shell scripting libraries dynamic-linking
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
add a comment |Â
up vote
3
down vote
favorite
up vote
3
down vote
favorite
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:
- What does the first script do?
- Why do I get different results across these three attempts? and why can't I just add
$pwd/lib
toLD_LIBRARY_PATH
and then runsome_binary
directly?
shell scripting libraries dynamic-linking
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:
- What does the first script do?
- Why do I get different results across these three attempts? and why can't I just add
$pwd/lib
toLD_LIBRARY_PATH
and then runsome_binary
directly?
shell scripting libraries dynamic-linking
shell scripting libraries dynamic-linking
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
add a comment |Â
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
add a comment |Â
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" "$@"
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
add a comment |Â
up vote
-1
down vote
Use patchelf
to set the interpreter.
patchelf --set-interpreter /lib/ld-linux-x86-64.so.2 <path-to-clang>
New contributor
add a comment |Â
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" "$@"
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
add a comment |Â
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" "$@"
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
add a comment |Â
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" "$@"
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" "$@"
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
add a comment |Â
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
add a comment |Â
up vote
-1
down vote
Use patchelf
to set the interpreter.
patchelf --set-interpreter /lib/ld-linux-x86-64.so.2 <path-to-clang>
New contributor
add a comment |Â
up vote
-1
down vote
Use patchelf
to set the interpreter.
patchelf --set-interpreter /lib/ld-linux-x86-64.so.2 <path-to-clang>
New contributor
add a comment |Â
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>
New contributor
Use patchelf
to set the interpreter.
patchelf --set-interpreter /lib/ld-linux-x86-64.so.2 <path-to-clang>
New contributor
edited Oct 1 at 13:05
Goro
7,02252965
7,02252965
New contributor
answered Oct 1 at 12:49
bashi-bazouk
1
1
New contributor
New contributor
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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