Question for Multi-OS Unix gurus

[Kevin Bingham]

I have previously had great success with finding answers for my HP-UX problems here, and am now struggling with another problem concerning a different "flavour of Unix. I tried to post a direct message concerning the problem on this forum, but it was deleted by the Moderator, presumably due to it being non-HP related.

I can't find any forums anywhere near as good as this for the other flavour of Unix:

The problem is as follows: an AIX loadmodule has been linked with the ld flag of -bnolibpath, which effectively means that the LIBPATH env variable gets ignored at runtime, instead the ld flags of -L and "link time" LIBPATH values are stored inside the load module. (This is 3rd party software, for which I don't have the source.)

I need to get the runtime LIBPATH to be used... what commands do I need to run against the load module to open it up to use the runtime LIBPATH. E.g. is there a way to call ld with flags to strip the -bnolibpath setting? I need to do this since the "dump -H loadmodule" shows an "index 0" path containing stuff that I don't have, and the things I need to be included are ignored...

Thanks in advance.

Kevin

[Kevin Bingham]

P.S. If you reply to that thread in this forum, I can award the points here... ;)

[Olivier Decorse]

ok,
so your loadmodule don't use the LIBPATH var, but an other directory for the librairy, for example /other_lib.
A possibility is to make a link from this other_lib directory, to a librairy that is stored in the $LIBPATH, and verify that it is loaded.

Olivier.

[Kevin Bingham]

Hi,

the point is that in this flavour of Unix, the LIBPATH that exists at "build time" is stored inside the loadmodule, and no other directories are even considered.

The ideal solution would be run some kind of command against the load module, which strips this "build time" LIBPATH from the loadmodule, and replaces it with an instruction to use the "current" LIBPATH instead...

Thanks in advance.

Kevin

[Olivier Decorse]

I understand your problem.

The ideal solution is better to have the code source of this module, and direct change the program !!!

But you don't have the code, and i think the command which strips the "build time" LIBPATH does not exist.
So can you simply try the link i explain, to see if it works ?
Olivier.

PS : you said you can award points here ?

[Fred Ruffet]

You can maybe use ldd (exists on linux and HP-UX) to determine what Library in wich PATH it is looking for and then make symbolic links...

If you want to modify the binary file to put the correct PATH, you will have at least problems of stirng length.

Regards,

Fred

[Kevin Bingham]

I have the command that is similar to ldd/chatr, it is "dump -H" as in dump headers I think...

It clearly shows the "build time" LIBPATH... I appreciate that editing a binary would have string length issues, that's why I am after the "magic" command that achieves my desired result...

With respect to the idea of using a symbolic link, I have two issues with this... firstly, I don't really want create spurious directory references on my system, and secondly, if the referenced directory does exist and there is a file with the same name, but different content to the one which is required, then I get other problems... E.g. Load Module loadmod1 has a built-in reference to directory /home/user1/lib, which at build time contained libMyLib.so... I get a copy of loadmod1 installed on my system, which happens to have a valid directory called /home/user1/lib, which also contains a file called libMyLib.so, but this file is completely different to the one which is needed by loadmod1, so I get a runtime "can't resolve symbol inside libMyLib.so" error... hence the need to change the LIBPATH that is built in to loadmod1 so that I can point the runtime LIBPATH to the directory where the valid libMyLib.so exists...

I hope this is clear.

Kevin

[Fred Ruffet]

I understand and agree with you don't want to create those link, but consider that having such a library with static lib path will force a dirty situation on the server.

If there are not too much libs, you can also link .so files instead of directories...

Regards,

Fred

[Kevin Bingham]

I agree the symbolic link solution will remove some of the problem, but it does not cater for the situation described in my last reply, where the symbolic link solution is not an option...

[Kevin Bingham]

Does anyone else have any suggestions?

[Kevin Bingham]

I guess from the lack of further responses, this must be impossible...