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

The name of the pictureThe name of the pictureThe name of the pictureClash 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.







share|improve this question




















  • 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














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.







share|improve this question




















  • 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












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.







share|improve this question












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.









share|improve this question











share|improve this question




share|improve this question










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
















  • 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










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 .






share|improve this answer




















  • 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". 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










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "89"
;
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: true,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
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%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






























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 .






share|improve this answer




















  • 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". 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














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 .






share|improve this answer




















  • 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". 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












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 .






share|improve this answer












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 .







share|improve this answer












share|improve this answer



share|improve this answer










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". 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
















  • 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". 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















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












 

draft saved


draft discarded


























 


draft saved


draft discarded














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













































































Popular posts from this blog

Which professions warranted travel in Medieval times?

How do so many people here on Academia.SE, and in general, afford lavish higher education programs?

Trouble downloading packages list due to a “Hash sum mismatch” error