×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Matt,
When it says something like 'libidn.a(libidn.so.11)', the file that ends
in .a is an "archive" file. Conceptually, it's similar to something
like a .ZIP file, except that it's designed to hold shared object files
(similar to service programs or DLLs). So it's looking for a
'libidn.so.11' inside of the 'libidn.a' file. For compatibility
purposes, a shared object file (libidn.so) will often have the version
number added on to it's name, that way if you have different software
that requires different versions, you can have both working, since they
have different filenmaes (libidn.so.11 would be version 11 of the
libidn.so file)
Anyway, in this case, it says that libidn.a(libidn.so.11) is found, but
cannot be loaded because it was compiled against
libiconv.a(libiconv.so.2), which isn't found.
libiconv is a very common dependency, so IBM probably did supply one,
but it might not be libiconv.so.2. You could use the 'ar' utility to
find out what's in the archive.
This sort of thing is a common problem when installing a precompiled
binary (program) because it was compiled against a specific version of
the dependent libraries. In open source environments (such as Linux,
etc) you typically have the source code for everything, so you can
normally solve these problems just by recompiling, assuming you have
some version of the dependencies available, it'll compile against the
ones you have.
Otherwise, if you want it to work wtihout compiling, you would need to
get the dependencies it needs and put them in your IFS somewhere. The
"safest" way is probably to put them in a nonstandard location. You can
tell the program to search for libraries in other directories (besides
the standard ones like /usr/lib) by putting the directory names
(separated by a colon if more than one) in the LIBPATH environment
variable. It'll look in the directories in your LIBPATH, and hopefully
find the needed libraries there... assuming, of course, that you can
find precompiled versions for some AIX version that's compatible with
PASE...
I know this is a bit long-winded, but I'm hoping that this background
info (instead of just saying "do X, Y and Z") will help you understand
what's going on.
On 9/3/2014 3:00 PM, Matt Lavinder wrote:
I have been playing on and off with getting several common Unix commands
working on the system. Many seem to be working, but I get this when I
try to use cURL (which impacts many other commands and scripts):
exec(): 0509-036 Cannot load program curl because of the following errors:
0509-022 Cannot load module
/opt/freeware/lib/libidn.a(libidn.so.11).
0509-150 Dependent module
/usr/lib/libiconv.a(libiconv.so.2) could not be loaded.
0509-152 Member libiconv.so.2 is not found in archive
0509-022 Cannot load module curl.
0509-150 Dependent module
/opt/freeware/lib/libidn.a(libidn.so.11) could not be
loaded.
0509-022 Cannot load module.
What bothers me is I think this means that libidn.a is looking at
/usr/lib for libiconv.a and is finding the wrong version. I believe
/usr/lib contains the libraries and dependencies provided by IBM, so I
don't think I want to mess with any thing there.
What is the safest way to get libidn.a the right version of libiconv.a?
I want my cURL command to work without breaking stuff. I sort of get
Unix dependencies and such, but not well enough (yet) to know a way to
fix this. Every suggestion I see online from AIX gurus involves
recompiling.
I hope there is an easier solution.
As an Amazon Associate we earn from qualifying purchases.