solaris/linux admins/rookie_develope rs that battle with this error are
probably all frustrated when it happens. i bet you're also somehow
frustrated by this seemingly unsolvable error :-) ...take it easy,
it'll go away once u've learned how to play around with a few things
on your system and reorganised. i'm particulary a solaris junkie, but
linux is my admiration. the issue here is Not the OS/Software, but
rather the concept. first of all , i've learned that people who
normally hit this error are those that somehow DOWNLOADED some
packages (so-called free/open-source) from the internet with a hope of
using the package to solve some inhouse problem. normally the package
installs FINE but just when you try to run it... BOMB!! and then u
spend 5 days battling with it and NOTHING good comes out of it and
finally, you come here ...still frustrated :-( chill ..it happened to
me plenty of times too. nuff said...
here's a typical extract of the ghost you've seen. you've probably
been battling with this for quite a while...
ld.so.1: fatal
No such file or directory
ImportError: ld.so.1
first you have to appreciate something about dynamic objects. dynamic
objects is a fancy term for programs that use DLLs (both windows and
unix programs can have DLLs). if you're Not familiar with dynamic
objects, then pls read section-3 which is right at the END of this
post. otherwise start with section-1 right here below...
section-1 (John Hunter's opinion)
############### ############### ############### ############
This problem typically arises when the program was compiled and
installed in one environment and executed in another. When it was
compiled, the compiler could find libgcc_s.so.1, but when it is
executed, the shared library is not in your LD_LIBRARY_PATH .
You probably do not need to recompile your program (unless it was
compiled on another system or with a cross compiler). First try and
find the dir on your system in which libgcc_s.so.1 resides. Three
suggestions:
If you have gnu findutils, just do 'locate libgcc_s.so.1'. Otherwise,
try:
# ldd /path/to/your_program
This will list the shared libraries that your_program needs and where
they are. If you can't find it that way, try:
# find /usr -name libgcc_s.so.1
or
# find /opt -name libgcc_s.so.1
you've GOT to finnd the missing file! if you still can't find it, I'll
guess that it's not on your system and your_program was compiled on
another machine. If you do find it here's how to modify
LD_LIBRARY_PATH so you can see it when you execute your_program.
Suppose you found it in /some/dir/lib
If you are a csh/tcsh user
# setenv LD_LIBRARY_PATH /some/dir/lib:$LD_LIBRARY _PATH
the line above is One long line, it's NOT two lines, it might be
wrapping on this newsgroup screen, so make sure you type it in as One
long line!..and also same applies to the other ones below.
If you are a bash/bourne/ksh user
# export LD_LIBRARY_PATH =$LD_LIBRARY_PA TH:/some/dir/lib
This command above should go in your rc file, eg, ~/.tcshrc, ~/.cshrc,
or ~/.bashrc, ~/.kshrc. Now open up a new shell/xterm, and try typing
your_program again. just run it without any parameters.
If you are still having trouble, make sure that your environment
variable are set correctly with:
If you are a csh/tcsh user
# setenv | grep LD |more
If you are a bash/bourne/ksh/zsh user
# echo $LD_LIBRARY_PAT H
You should see the dirs you entered in for LD_LIBRARY_PATH .
Good luck,
John Hunter
section-2 (my opinion)
############### ############### ############### ############
in addition to john's stuff above, there is a trick about unix's
symbolic links which i'm gonna base my opinion on. my opinion
therefore applies in the case where the xx.so.x file is actually THERE
on your system but the error still says that
'No such file or directory' even when LD_LIBRARY_PATH is properly set
and exported.
what you have to do is to run the ldd command again (as above in
john's post) and look carefully at what it reports. Not ALL of the
xx.so files should be reported problematic, ONLY SOME of them will be
reported as 'Not found'. now my opinion revolves around the idea of
finding the place/directory where the GOOD ones are sitting. once
you're in this directory, u can then make a symbolic link to the xx.so
that's giving you a problem. NB: the link must be in the
place/directory where the good xx.so files are sitting. this will fool
the OS/ld into thinking that your missing xx.so file is actually now
in the right place. NB: DON'T move your troublesome/missing xx.so file
into the place/directory where the good xx.so files are sitting
....just create a symbolic link in the good directory, the link will
just point to the troublesome/missing file whereever it is sitting.
let's say for instance that the '/etc/maria.so.1' file is giving you
trouble and is being reported as 'No such file found' and u've tried
everything such as setting LD_LIBRARY_PATH and you're tired. now let's
be explicit and say that you get the error when you run the 'python'
command. the command you're running does Not matter, it could be
'openssl' or 'samba' or 'ssh' or 'wget' or 'apache' or even 'java'
itself, the error is the most interesting thing here cuz it's likely
to always be the same (ld.so.1: fatal No such file or directory).
let's assume that u're running the 'python' command. what you would
then do is
# ldd /full/path/to/python_binary
now observer carefuully what the ldd command above reports to you.
it'll show that SOME of the xx.so.x files are Not found. good. now
FORGET the missing one, now look at those that are OK. use the find
command to find onne/more of those ones that are OK, go to the
directory where you found one of them (let's say it's /usr/lib), once
you're there, create a symbolic link to your missing file
(/etc/maria.so.1). i hope you know where your missing xx.so file is
sitting (/etc/maria.so.1), cuz you've probably confirmed taht it DOES
EXIST indeed and you know exactly where it is. so create the link to
it as follows...
# cd /usr/lib
in this case above, /usr/lib is our directory with good xx.so files.
# ln -s /etc/maria.so.1 maria.so.1
in this command above, it might be necessary to use FULL paths.
now make sure that your LD_LIBRARY_PATH is set properly and EXPORTED.
now fire up your 'python' or 'samba' or 'apache' or whatever command
that complained about the missing xx.so.x. what does it say NOW??
it might now complain about ANOTHER xx.so.x (Not the same one as the
first one anymore), well... i guess u've figured out how we've solved
the problem for the first one. do the same for the second one and the
third one and so on. just create a link for it in the directory with
good xx.so files just like the first one. repeat this process for all
your missing xx.so.x (as long as you know that you have them on your
system). yeah, that's all about my suggestion.
should my suggestion fail, well, then you have a lot to read about ld,
etc. Listen, i know man pages are Not the most exciting thing to
read, but you have to read them with an open mind (Don't try to rush
into finding quick answers cuz that's gonna frustrate you more) ...
try section-3 below, but then you're on your own. i'm Not gonna
comment on anything about section-3 below. after you read, hopefully
something will click in your mind about what's happening on your
specific system.
as a semi-final Note: DONT clutter your system, when u make the links
above, do them one-by-one, DON'T use a shell script. DON'T create
links for any xx.so.x files that are NOT causing you trouble. a rule
of thumb is to always keep a text file (Notepad) so that you have a
log of ALL the links you've made cuz this process of creating symbolic
links for UNresolved xx.so.x files will have FUTURE consequences and
you DON'T wonna be caught by suprise in the future when something that
WAS working in the past is NO LONGER working ..while the new stuff is
WORKING just ok :-) it's therefore important to REMEMBER that you once
created an override link for a troublesome library file and this
override link could be the cause of trouble with something else in the
FUTURE, with a clear mindset (keeping logs of ALL previous/original
settings) you could easily reverse the system's config and walk away
clean. so it's important for you to be able to REVERT even when the
problem gets solved today and things seem to be working ok!!
as a final-FINAL Note: i'm not responsible for any files that get
deleted or that disappear from your system when you use my advice cuz
they way i see it, when u use my advice you're somehow
hacking/overriding your system's config. u do this solely at your own
discretion/risk. you came here without my invitation, and you're
reading this without my invitation either. i did Not send u this info
by email, etc. so just keep me out of it.
section-3 (general info on ld)
############### ############### ############### ############
_______________ _______________ _____________
Moses Motlhale - Solutions Architect
24th Century Solutions, South Africa.
probably all frustrated when it happens. i bet you're also somehow
frustrated by this seemingly unsolvable error :-) ...take it easy,
it'll go away once u've learned how to play around with a few things
on your system and reorganised. i'm particulary a solaris junkie, but
linux is my admiration. the issue here is Not the OS/Software, but
rather the concept. first of all , i've learned that people who
normally hit this error are those that somehow DOWNLOADED some
packages (so-called free/open-source) from the internet with a hope of
using the package to solve some inhouse problem. normally the package
installs FINE but just when you try to run it... BOMB!! and then u
spend 5 days battling with it and NOTHING good comes out of it and
finally, you come here ...still frustrated :-( chill ..it happened to
me plenty of times too. nuff said...
here's a typical extract of the ghost you've seen. you've probably
been battling with this for quite a while...
ld.so.1: fatal
No such file or directory
ImportError: ld.so.1
first you have to appreciate something about dynamic objects. dynamic
objects is a fancy term for programs that use DLLs (both windows and
unix programs can have DLLs). if you're Not familiar with dynamic
objects, then pls read section-3 which is right at the END of this
post. otherwise start with section-1 right here below...
section-1 (John Hunter's opinion)
############### ############### ############### ############
This problem typically arises when the program was compiled and
installed in one environment and executed in another. When it was
compiled, the compiler could find libgcc_s.so.1, but when it is
executed, the shared library is not in your LD_LIBRARY_PATH .
You probably do not need to recompile your program (unless it was
compiled on another system or with a cross compiler). First try and
find the dir on your system in which libgcc_s.so.1 resides. Three
suggestions:
If you have gnu findutils, just do 'locate libgcc_s.so.1'. Otherwise,
try:
# ldd /path/to/your_program
This will list the shared libraries that your_program needs and where
they are. If you can't find it that way, try:
# find /usr -name libgcc_s.so.1
or
# find /opt -name libgcc_s.so.1
you've GOT to finnd the missing file! if you still can't find it, I'll
guess that it's not on your system and your_program was compiled on
another machine. If you do find it here's how to modify
LD_LIBRARY_PATH so you can see it when you execute your_program.
Suppose you found it in /some/dir/lib
If you are a csh/tcsh user
# setenv LD_LIBRARY_PATH /some/dir/lib:$LD_LIBRARY _PATH
the line above is One long line, it's NOT two lines, it might be
wrapping on this newsgroup screen, so make sure you type it in as One
long line!..and also same applies to the other ones below.
If you are a bash/bourne/ksh user
# export LD_LIBRARY_PATH =$LD_LIBRARY_PA TH:/some/dir/lib
This command above should go in your rc file, eg, ~/.tcshrc, ~/.cshrc,
or ~/.bashrc, ~/.kshrc. Now open up a new shell/xterm, and try typing
your_program again. just run it without any parameters.
If you are still having trouble, make sure that your environment
variable are set correctly with:
If you are a csh/tcsh user
# setenv | grep LD |more
If you are a bash/bourne/ksh/zsh user
# echo $LD_LIBRARY_PAT H
You should see the dirs you entered in for LD_LIBRARY_PATH .
Good luck,
John Hunter
section-2 (my opinion)
############### ############### ############### ############
in addition to john's stuff above, there is a trick about unix's
symbolic links which i'm gonna base my opinion on. my opinion
therefore applies in the case where the xx.so.x file is actually THERE
on your system but the error still says that
'No such file or directory' even when LD_LIBRARY_PATH is properly set
and exported.
what you have to do is to run the ldd command again (as above in
john's post) and look carefully at what it reports. Not ALL of the
xx.so files should be reported problematic, ONLY SOME of them will be
reported as 'Not found'. now my opinion revolves around the idea of
finding the place/directory where the GOOD ones are sitting. once
you're in this directory, u can then make a symbolic link to the xx.so
that's giving you a problem. NB: the link must be in the
place/directory where the good xx.so files are sitting. this will fool
the OS/ld into thinking that your missing xx.so file is actually now
in the right place. NB: DON'T move your troublesome/missing xx.so file
into the place/directory where the good xx.so files are sitting
....just create a symbolic link in the good directory, the link will
just point to the troublesome/missing file whereever it is sitting.
let's say for instance that the '/etc/maria.so.1' file is giving you
trouble and is being reported as 'No such file found' and u've tried
everything such as setting LD_LIBRARY_PATH and you're tired. now let's
be explicit and say that you get the error when you run the 'python'
command. the command you're running does Not matter, it could be
'openssl' or 'samba' or 'ssh' or 'wget' or 'apache' or even 'java'
itself, the error is the most interesting thing here cuz it's likely
to always be the same (ld.so.1: fatal No such file or directory).
let's assume that u're running the 'python' command. what you would
then do is
# ldd /full/path/to/python_binary
now observer carefuully what the ldd command above reports to you.
it'll show that SOME of the xx.so.x files are Not found. good. now
FORGET the missing one, now look at those that are OK. use the find
command to find onne/more of those ones that are OK, go to the
directory where you found one of them (let's say it's /usr/lib), once
you're there, create a symbolic link to your missing file
(/etc/maria.so.1). i hope you know where your missing xx.so file is
sitting (/etc/maria.so.1), cuz you've probably confirmed taht it DOES
EXIST indeed and you know exactly where it is. so create the link to
it as follows...
# cd /usr/lib
in this case above, /usr/lib is our directory with good xx.so files.
# ln -s /etc/maria.so.1 maria.so.1
in this command above, it might be necessary to use FULL paths.
now make sure that your LD_LIBRARY_PATH is set properly and EXPORTED.
now fire up your 'python' or 'samba' or 'apache' or whatever command
that complained about the missing xx.so.x. what does it say NOW??
it might now complain about ANOTHER xx.so.x (Not the same one as the
first one anymore), well... i guess u've figured out how we've solved
the problem for the first one. do the same for the second one and the
third one and so on. just create a link for it in the directory with
good xx.so files just like the first one. repeat this process for all
your missing xx.so.x (as long as you know that you have them on your
system). yeah, that's all about my suggestion.
should my suggestion fail, well, then you have a lot to read about ld,
etc. Listen, i know man pages are Not the most exciting thing to
read, but you have to read them with an open mind (Don't try to rush
into finding quick answers cuz that's gonna frustrate you more) ...
try section-3 below, but then you're on your own. i'm Not gonna
comment on anything about section-3 below. after you read, hopefully
something will click in your mind about what's happening on your
specific system.
as a semi-final Note: DONT clutter your system, when u make the links
above, do them one-by-one, DON'T use a shell script. DON'T create
links for any xx.so.x files that are NOT causing you trouble. a rule
of thumb is to always keep a text file (Notepad) so that you have a
log of ALL the links you've made cuz this process of creating symbolic
links for UNresolved xx.so.x files will have FUTURE consequences and
you DON'T wonna be caught by suprise in the future when something that
WAS working in the past is NO LONGER working ..while the new stuff is
WORKING just ok :-) it's therefore important to REMEMBER that you once
created an override link for a troublesome library file and this
override link could be the cause of trouble with something else in the
FUTURE, with a clear mindset (keeping logs of ALL previous/original
settings) you could easily reverse the system's config and walk away
clean. so it's important for you to be able to REVERT even when the
problem gets solved today and things seem to be working ok!!
as a final-FINAL Note: i'm not responsible for any files that get
deleted or that disappear from your system when you use my advice cuz
they way i see it, when u use my advice you're somehow
hacking/overriding your system's config. u do this solely at your own
discretion/risk. you came here without my invitation, and you're
reading this without my invitation either. i did Not send u this info
by email, etc. so just keep me out of it.
section-3 (general info on ld)
############### ############### ############### ############
_______________ _______________ _____________
Moses Motlhale - Solutions Architect
24th Century Solutions, South Africa.
Comment