How does this program statically link to a .so in a non-default path

Clash Royale CLAN TAG#URR8PPP up vote
0
down vote
favorite
A program I am using can only be installed with a custom installer (IDA Freeware Demo). I have installed it in my home dir, it all works fine.
Now I noticed when checking the program with ldd: it ships with its own Qt libraries, which is places as shared libraries in its install dir (so the same directory its main executable file resides in, not /usr/lib or similar).
$ ldd ida64
linux-vdso.so.1 => (0x00007ffec5fb9000)
libida64.so => /home/asdf/idafree-7.0/./libida64.so
libQt5PrintSupport.so.5 => /home/asdf/idafree-7.0/./libQt5PrintSupport.so.5
libQt5Widgets.so.5 => /home/asdf/idafree-7.0/./libQt5Widgets.so.5
....
(install dir = /home/asdf/idafree-7.0/)
Now I wonder: How does it do that? I execute the program directly without any LD_LIB_PATH magic.
libraries shared-library dynamic-linking ld
add a comment |Â
up vote
0
down vote
favorite
A program I am using can only be installed with a custom installer (IDA Freeware Demo). I have installed it in my home dir, it all works fine.
Now I noticed when checking the program with ldd: it ships with its own Qt libraries, which is places as shared libraries in its install dir (so the same directory its main executable file resides in, not /usr/lib or similar).
$ ldd ida64
linux-vdso.so.1 => (0x00007ffec5fb9000)
libida64.so => /home/asdf/idafree-7.0/./libida64.so
libQt5PrintSupport.so.5 => /home/asdf/idafree-7.0/./libQt5PrintSupport.so.5
libQt5Widgets.so.5 => /home/asdf/idafree-7.0/./libQt5Widgets.so.5
....
(install dir = /home/asdf/idafree-7.0/)
Now I wonder: How does it do that? I execute the program directly without any LD_LIB_PATH magic.
libraries shared-library dynamic-linking ld
I guess the executable is hard coded to know where to look for "its own libraries".
â Knud Larsen
May 13 at 22:24
How does that work?
â bernd feinman
May 14 at 1:21
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
A program I am using can only be installed with a custom installer (IDA Freeware Demo). I have installed it in my home dir, it all works fine.
Now I noticed when checking the program with ldd: it ships with its own Qt libraries, which is places as shared libraries in its install dir (so the same directory its main executable file resides in, not /usr/lib or similar).
$ ldd ida64
linux-vdso.so.1 => (0x00007ffec5fb9000)
libida64.so => /home/asdf/idafree-7.0/./libida64.so
libQt5PrintSupport.so.5 => /home/asdf/idafree-7.0/./libQt5PrintSupport.so.5
libQt5Widgets.so.5 => /home/asdf/idafree-7.0/./libQt5Widgets.so.5
....
(install dir = /home/asdf/idafree-7.0/)
Now I wonder: How does it do that? I execute the program directly without any LD_LIB_PATH magic.
libraries shared-library dynamic-linking ld
A program I am using can only be installed with a custom installer (IDA Freeware Demo). I have installed it in my home dir, it all works fine.
Now I noticed when checking the program with ldd: it ships with its own Qt libraries, which is places as shared libraries in its install dir (so the same directory its main executable file resides in, not /usr/lib or similar).
$ ldd ida64
linux-vdso.so.1 => (0x00007ffec5fb9000)
libida64.so => /home/asdf/idafree-7.0/./libida64.so
libQt5PrintSupport.so.5 => /home/asdf/idafree-7.0/./libQt5PrintSupport.so.5
libQt5Widgets.so.5 => /home/asdf/idafree-7.0/./libQt5Widgets.so.5
....
(install dir = /home/asdf/idafree-7.0/)
Now I wonder: How does it do that? I execute the program directly without any LD_LIB_PATH magic.
libraries shared-library dynamic-linking ld
asked May 13 at 19:44
bernd feinman
133
133
I guess the executable is hard coded to know where to look for "its own libraries".
â Knud Larsen
May 13 at 22:24
How does that work?
â bernd feinman
May 14 at 1:21
add a comment |Â
I guess the executable is hard coded to know where to look for "its own libraries".
â Knud Larsen
May 13 at 22:24
How does that work?
â bernd feinman
May 14 at 1:21
I guess the executable is hard coded to know where to look for "its own libraries".
â Knud Larsen
May 13 at 22:24
I guess the executable is hard coded to know where to look for "its own libraries".
â Knud Larsen
May 13 at 22:24
How does that work?
â bernd feinman
May 14 at 1:21
How does that work?
â bernd feinman
May 14 at 1:21
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
0
down vote
Simple explanation how to run an executable requiring a unique LD_LIBRARY_PATH, e.g. a path to libs in the current directory/ :
Short : export LD_LIBRARY_PATH=. where the dot ( . ) means 'the current directory'
Usually also the system LD_LIBRARY_PATH will (have to) be included : export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
"Hard coding" of e.g. ida64 : The function in the executable to be run first is setting the unique LD_LIBRARY_PATH . ... Other example : firefox .
So unlike in windows, elf imports are resolved lazily?
â bernd feinman
May 14 at 12:09
I never use Windows©. .... .... »»elf imports are resolved lazily«« : Please elaborate.
â Knud Larsen
May 14 at 12:14
In windows, launching an executable fails if not all imports/libraries can be located by the loader before handing control to the executable. Here you say the linux executable itself can adjust LD_LIBRARY_PATH after its launch, so it would seem the loader only looks for and load those libraries when one of their exports is actually called. Correct?
â bernd feinman
May 14 at 12:19
The first call could be a "file.ini".ida64may useida64.intor something else. But usually the 'path' is part the code in the executable. If you open the executableida64with an editor you will see a word like/lib64/ld-linux-x86-64.so.2in plain text.
â Knud Larsen
May 14 at 13:17
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
Simple explanation how to run an executable requiring a unique LD_LIBRARY_PATH, e.g. a path to libs in the current directory/ :
Short : export LD_LIBRARY_PATH=. where the dot ( . ) means 'the current directory'
Usually also the system LD_LIBRARY_PATH will (have to) be included : export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
"Hard coding" of e.g. ida64 : The function in the executable to be run first is setting the unique LD_LIBRARY_PATH . ... Other example : firefox .
So unlike in windows, elf imports are resolved lazily?
â bernd feinman
May 14 at 12:09
I never use Windows©. .... .... »»elf imports are resolved lazily«« : Please elaborate.
â Knud Larsen
May 14 at 12:14
In windows, launching an executable fails if not all imports/libraries can be located by the loader before handing control to the executable. Here you say the linux executable itself can adjust LD_LIBRARY_PATH after its launch, so it would seem the loader only looks for and load those libraries when one of their exports is actually called. Correct?
â bernd feinman
May 14 at 12:19
The first call could be a "file.ini".ida64may useida64.intor something else. But usually the 'path' is part the code in the executable. If you open the executableida64with an editor you will see a word like/lib64/ld-linux-x86-64.so.2in plain text.
â Knud Larsen
May 14 at 13:17
add a comment |Â
up vote
0
down vote
Simple explanation how to run an executable requiring a unique LD_LIBRARY_PATH, e.g. a path to libs in the current directory/ :
Short : export LD_LIBRARY_PATH=. where the dot ( . ) means 'the current directory'
Usually also the system LD_LIBRARY_PATH will (have to) be included : export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
"Hard coding" of e.g. ida64 : The function in the executable to be run first is setting the unique LD_LIBRARY_PATH . ... Other example : firefox .
So unlike in windows, elf imports are resolved lazily?
â bernd feinman
May 14 at 12:09
I never use Windows©. .... .... »»elf imports are resolved lazily«« : Please elaborate.
â Knud Larsen
May 14 at 12:14
In windows, launching an executable fails if not all imports/libraries can be located by the loader before handing control to the executable. Here you say the linux executable itself can adjust LD_LIBRARY_PATH after its launch, so it would seem the loader only looks for and load those libraries when one of their exports is actually called. Correct?
â bernd feinman
May 14 at 12:19
The first call could be a "file.ini".ida64may useida64.intor something else. But usually the 'path' is part the code in the executable. If you open the executableida64with an editor you will see a word like/lib64/ld-linux-x86-64.so.2in plain text.
â Knud Larsen
May 14 at 13:17
add a comment |Â
up vote
0
down vote
up vote
0
down vote
Simple explanation how to run an executable requiring a unique LD_LIBRARY_PATH, e.g. a path to libs in the current directory/ :
Short : export LD_LIBRARY_PATH=. where the dot ( . ) means 'the current directory'
Usually also the system LD_LIBRARY_PATH will (have to) be included : export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
"Hard coding" of e.g. ida64 : The function in the executable to be run first is setting the unique LD_LIBRARY_PATH . ... Other example : firefox .
Simple explanation how to run an executable requiring a unique LD_LIBRARY_PATH, e.g. a path to libs in the current directory/ :
Short : export LD_LIBRARY_PATH=. where the dot ( . ) means 'the current directory'
Usually also the system LD_LIBRARY_PATH will (have to) be included : export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
"Hard coding" of e.g. ida64 : The function in the executable to be run first is setting the unique LD_LIBRARY_PATH . ... Other example : firefox .
answered May 14 at 11:55
Knud Larsen
1,451157
1,451157
So unlike in windows, elf imports are resolved lazily?
â bernd feinman
May 14 at 12:09
I never use Windows©. .... .... »»elf imports are resolved lazily«« : Please elaborate.
â Knud Larsen
May 14 at 12:14
In windows, launching an executable fails if not all imports/libraries can be located by the loader before handing control to the executable. Here you say the linux executable itself can adjust LD_LIBRARY_PATH after its launch, so it would seem the loader only looks for and load those libraries when one of their exports is actually called. Correct?
â bernd feinman
May 14 at 12:19
The first call could be a "file.ini".ida64may useida64.intor something else. But usually the 'path' is part the code in the executable. If you open the executableida64with an editor you will see a word like/lib64/ld-linux-x86-64.so.2in plain text.
â Knud Larsen
May 14 at 13:17
add a comment |Â
So unlike in windows, elf imports are resolved lazily?
â bernd feinman
May 14 at 12:09
I never use Windows©. .... .... »»elf imports are resolved lazily«« : Please elaborate.
â Knud Larsen
May 14 at 12:14
In windows, launching an executable fails if not all imports/libraries can be located by the loader before handing control to the executable. Here you say the linux executable itself can adjust LD_LIBRARY_PATH after its launch, so it would seem the loader only looks for and load those libraries when one of their exports is actually called. Correct?
â bernd feinman
May 14 at 12:19
The first call could be a "file.ini".ida64may useida64.intor something else. But usually the 'path' is part the code in the executable. If you open the executableida64with an editor you will see a word like/lib64/ld-linux-x86-64.so.2in plain text.
â Knud Larsen
May 14 at 13:17
So unlike in windows, elf imports are resolved lazily?
â bernd feinman
May 14 at 12:09
So unlike in windows, elf imports are resolved lazily?
â bernd feinman
May 14 at 12:09
I never use Windows©. .... .... »»elf imports are resolved lazily«« : Please elaborate.
â Knud Larsen
May 14 at 12:14
I never use Windows©. .... .... »»elf imports are resolved lazily«« : Please elaborate.
â Knud Larsen
May 14 at 12:14
In windows, launching an executable fails if not all imports/libraries can be located by the loader before handing control to the executable. Here you say the linux executable itself can adjust LD_LIBRARY_PATH after its launch, so it would seem the loader only looks for and load those libraries when one of their exports is actually called. Correct?
â bernd feinman
May 14 at 12:19
In windows, launching an executable fails if not all imports/libraries can be located by the loader before handing control to the executable. Here you say the linux executable itself can adjust LD_LIBRARY_PATH after its launch, so it would seem the loader only looks for and load those libraries when one of their exports is actually called. Correct?
â bernd feinman
May 14 at 12:19
The first call could be a "file.ini".
ida64 may use ida64.int or something else. But usually the 'path' is part the code in the executable. If you open the executable ida64 with an editor you will see a word like /lib64/ld-linux-x86-64.so.2 in plain text.â Knud Larsen
May 14 at 13:17
The first call could be a "file.ini".
ida64 may use ida64.int or something else. But usually the 'path' is part the code in the executable. If you open the executable ida64 with an editor you will see a word like /lib64/ld-linux-x86-64.so.2 in plain text.â Knud Larsen
May 14 at 13:17
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
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%2faskubuntu.com%2fquestions%2f1035831%2fhow-does-this-program-statically-link-to-a-so-in-a-non-default-path%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
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');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
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');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
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
I guess the executable is hard coded to know where to look for "its own libraries".
â Knud Larsen
May 13 at 22:24
How does that work?
â bernd feinman
May 14 at 1:21