Re: Dependency hell with cURL and libiconv.a

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.

--

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.