MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » September 2014

Re: Dependency hell with cURL and libiconv.a



fixed

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.






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact