[KLUG Members] Migration from Redhat 7 to turbolinux 6

[members@kalamazoolinux.org]

okay: Here's a pisser:

ldd foo.exe (this is in linux, of course)
ldd: warning: you do not have execution permission for `./foo.exe'
        libpq++.so.2.0 => /usr/lib/libpq++.so.2.0 (0x2aab1000)
        libpq.so.2.0 => /usr/lib/libpq.so.2.0 (0x2aac8000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x2aad4000)
        libm.so.6 => /lib/libm.so.6 (0x2ab02000)
        libc.so.6 => /lib/libc.so.6 (0x2ab1c000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x55555000)
These are all okay.  However:

./foo.exe
foo.exe: error in loading shared libraries
libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file or
directory

Okay.. Anyway, I've pored over the code, and found out what it is.  If I
remove the ios::app | ios::in | ios::out  I can compile and run the program just
fine and dandy (like sour candy).    Now, I need to find a replacement for
ios::app (since ios::in and ios::out are mostly redundant). that will fix it,
I believe.

Adam

> >>>>You'll have to compile it on the TurboLinux box or download a
> >>>>binary package that was compiled for a similar release of TurboLinux.
> >>>Yeah,I did that on the TL box, but it still yells. This is quite the
> >>>pickle. You can run "ldd" on the binary to see what libraries it
> requires
> >>>and make sure the library paths are in /etc/ld.so.conf .
> >>>If you modify /etc/ld.so.conf you'll have to run ldconfig or reboot.
> >All true, but I'm more interested in what libraries are missing and why
> >it's "impossible" to put them on the system.....Maybe I should ask....
> 
> Yes, the output of ldd is critical here.  Usually an application only uses
> a
> library if it needs it, so if your using libgssrpc.so.3.0 it is because
> the
> developer needed the GSSAPI.  
> 
> You can relink the application --static and create a huge binary with very
> few
> dependencies.
> 
> You can install the requesite libraries on the system.
> 
> You can cheat.  Put the libraries you need, but the over-yonder system may
> not
> have,  in with the tar ball.  Then make a short script that does a
> LD_LIBRARY_PATH={app install dir/lib} then executes your program.  The
> loader
> will look in LD_LIBRARY_PATH when it trundles about looking for libraries,
>  find
> them there and happily slap them in.  Only caveat is that if new/better
> libraries get loaded on the system subsequently your app won't see them
> and will
> continue to use the old/buggy libraries.  Not to mention it "wastes" disk
> space.  But this is not a bad method with critical applications as it
> insulates
> them from spurious library updates.  Basically the diffrence between
> putting a
> Win32 DLL in the program's directory or windows/system.
> 
> Morrison Industries
> 1825 Monroe Ave NW
> Grand Rapids, MI. 49505
> _______________________________________________
> Members mailing list
> Members@kalamazoolinux.org
> 
> 

-- 
Adam Bultman

adam_bultman@bigfoot.com

Sent through GMX FreeMail - http://www.gmx.net