richard.c.ji@gmail.com wrote:

> But I can see /unix on the second box and it's identical to the first.
> ls -al /unix
> lrwxrwxrwx 1 root system 21 Mar 05 2007 /unix -> /usr/
> lib/boot/unix_64

check the hard-coded library-path in the executable
(the best way I know to do this is 'strings sqlextr')

On 8 Nov., 22:17, richard.c...@gmail.com wrote:
> Hi All,
>
> I am new to AIX, I have been primarily a Linux/Solaris person.
>
> I have compiled a program on one of my box and when transferred to
> another it doesn't run.
>
> Here is ldd on the box that works:
>
> ldd sqlextr
> sqlextr needs:
> /usr/lib/libc.a(shr.o)
> /unix
> /usr/lib/libcrypt.a(shr.o)
> /usr/lib/libpthreads.a(shr_xpg5.o)
> /usr/lib/libdl.a(shr.o)
> /usr/lib/libodm.a(shr.o)
> /usr/lib/libperfstat.a(shr.o)
> /usr/lib/libpthreads.a(shr_comm.o)
> /usr/lib/libcfg.a(shr.o)
> /usr/lib/liblvm.a(shr.o)
>
> Here is ldd on the box that doesn't work:
>
> ldd sqlextr
> sqlextr needs:
> /usr/lib/libc.a(shr.o)
> Cannot find /unix
> /usr/lib/libcrypt.a(shr.o)
>
> But I can see /unix on the second box and it's identical to the first.
> ls -al /unix
> lrwxrwxrwx 1 root system 21 Mar 05 2007 /unix -> /usr/
> lib/boot/unix_64
>
> I would really appreciate any advises/pointers. I am stuck at this
> moment.
>
> Regards

Determine if /usr/lib/libcrypt.a exist at all
If not install the package which contains /usr/lib/libcrypt.a
To determine the package run
$ which_fileset /usr/lib/libcrypt.a
or on the box where /usr/lib/libcrypt.a exist
$ lslpp -w /usr/lib/libcrypt.a # From memory - might be " -f"
Install the missing package.

hth
Hajo

richard.c.ji@gmail.com writes:

> Here is ldd on the box that doesn't work:
>
> ldd sqlextr
> sqlextr needs:
> /usr/lib/libc.a(shr.o)
> Cannot find /unix
> /usr/lib/libcrypt.a(shr.o)

The ldd doesn't tell you what you need to know.
Just run the application, and the loader will say something like:

Symbol foo not exported from dependent module /path/to/libfoo.a(shr.o)

That sould give you a clue about what's missing on the second box.

>
> But I can see /unix on the second box and it's identical to the first.

You see that /unix is a symlink to the same place on both boxes.
What you didn't check is whether /usr/lib/boot/unix_64 is identical
on both machines.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

On Nov 9, 2:04 pm, Lõrinczy Zsigmond wrote:
> richard.c...@gmail.com wrote:
> > But I can see /unix on the second box and it's identical to the first.
> > ls -al /unix
> > lrwxrwxrwx 1 root system 21 Mar 05 2007 /unix -> /usr/
> > lib/boot/unix_64
>
> check the hard-coded library-path in the executable
> (the best way I know to do this is 'strings sqlextr')

Thanks, you are right on. The problem is because some of the .so
files are under two different locations on two boxes. When compiled
on the first box, it remembers the full path where the .so files
resides. So when I move to the second box, it couldn't locate it,
even though I tried to set the LIBPATH.

Now, how can I get rid of the hard coded LIBPATH that ended up in the
binary itself? So, when I move to the second box, it will go look for
wherever the new LIBPATH on the second box points to? I am using GCC
4.

Thanks.

Richard

On Nov 13, 9:23 am, Paul Pluzhnikov
wrote:
> richard.c...@gmail.com writes:
> > Here islddon the box that doesn't work:
>
> > lddsqlextr
> > sqlextr needs:
> > /usr/lib/libc.a(shr.o)
> > Cannot find /unix
> > /usr/lib/libcrypt.a(shr.o)
>
> Theldddoesn't tell you what you need to know.
> Just run the application, and the loader will say something like:
>
> Symbol foo not exported from dependent module /path/to/libfoo.a(shr.o)
>
> That sould give you a clue about what's missing on the second box.
>
>
>
> > But I can see /unix on the second box and it's identical to the first.
>
> You see that /unix is a symlink to the same place on both boxes.
> What you didn't check is whether /usr/lib/boot/unix_64 is identical
> on both machines.
>
> Cheers,
> --
> In order to understand recursion you must first understand recursion.
> Remove /-nsp/ for email.

Paul, sorry that I didn't mention that, the real file which the
symbolic link points to does exist. The problem was the library path
got hard coded into the binary itself. It became clear to me after I
ran strings on the binary as the other poster pointed out.

Thanks for your help.

Richard

On Nov 21, 12:11 pm, richard.c...@gmail.com wrote:
> On Nov 9, 2:04 pm, Lõrinczy Zsigmond wrote:
>
> > richard.c...@gmail.com wrote:
> > > But I can see /unix on the second box and it's identical to the first.
> > > ls -al /unix
> > > lrwxrwxrwx 1 root system 21 Mar 05 2007 /unix -> /usr/
> > > lib/boot/unix_64
>
> > check the hard-coded library-path in the executable
> > (the best way I know to do this is 'strings sqlextr')
>
> Thanks, you are right on. The problem is because some of the .so
> files are under two different locations on two boxes. Whencompiled
> on the first box, it remembers the full path where the .so files
> resides. So when I move to the second box, it couldn't locate it,
> even though I tried to set the LIBPATH.
>
> Now, how can I get rid of the hard coded LIBPATH that ended up in the
> binary itself? So, when I move to the second box, it will go look for
> wherever the new LIBPATH on the second box points to? I am using GCC
> 4.
>
> Thanks.
>
> Richard

OK, I made some progress. Using dump, I saw that the index 2, the
shared library has a path associated with it. That's the one I need
to get rid of. I don't know how to compile it so that path doesn't
show up in that place.

dump -Hv sqlextr

sqlextr:

***Loader Section***
Loader Header Information
VERSION# #SYMtableENT #RELOCent LENidSTR
0x00000001 0x00000018 0x0000009d 0x000001f1

#IMPfilID OFFidSTR LENstrTBL OFFstrTBL
0x00000003 0x000009bc 0x0000006a 0x00000bad


***Import File Strings***
INDEX PATH BASE
MEMBER
0 /d00/app/oracle/product/10.2.0/lib32:/d00/app/oracle/product/
10.2.0/rdbms/lib32:/:/app/oracle/product/10.2/db/lib32:/app/oracle/
product/10.2/db/rdbms/lib32:/usr/local/bin/../lib/gcc/powerpc-ibm-
aix5.3.0.0/4.0.0:/usr/local/bin/../lib/gcc:/opt/freeware/lib/gcc/
powerpc-ibm-aix5.3.0.0/4.0.0:/usr/local/bin/../lib/gcc/powerpc-ibm-
aix5.3.0.0/4.0.0/../../..:/opt/freeware/lib/gcc/powerpc-ibm-
aix5.3.0.0/4.0.0/../../..:/usr/lib:/
lib
1 libc.a
shr.o
2 /d00/app/oracle/product/10.2.0/lib32 libclntsh.a
shr.o

richard.c.ji@gmail.com writes:

> Now, how can I get rid of the hard coded LIBPATH that ended up in the
> binary itself?

Don't do this:

gcc main.o ... /d00/app/oracle/product/10.2.0/lib32/libclntsh.a ...

Do this instead:

gcc main.o ... -L/d00/app/oracle/product/10.2.0/lib32 -lclntsh ...


Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

On Nov 21, 10:56 pm, Paul Pluzhnikov
wrote:
> richard.c...@gmail.com writes:
> > Now, how can I get rid of the hard coded LIBPATH that ended up in the
> > binary itself?
>
> Don't do this:
>
> gcc main.o ... /d00/app/oracle/product/10.2.0/lib32/libclntsh.a ...
>
> Do this instead:
>
> gcc main.o ... -L/d00/app/oracle/product/10.2.0/lib32 -lclntsh ...
>
> Cheers,
> --
> In order to understand recursion you must first understand recursion.
> Remove /-nsp/ for email.

Paul,

That does it. Thanks a lot. Have a Happy Thanksgiving.

Richard

richard.c.ji@gmail.com wrote:
> On Nov 21, 10:56 pm, Paul Pluzhnikov
> wrote:
>> Do this instead:
>>
>> gcc main.o ... -L/d00/app/oracle/product/10.2.0/lib32 -lclntsh ...
>>
>
> That does it. Thanks a lot. Have a Happy Thanksgiving.

You'll also find -bnoipath and -blibpath to be useful linker options.

--
-------------------------------------
http://www.photo.net/photos/garyrhook
Vocatus atque non vocatus deus aderit