[freetds] sqsh won't run
James K. Lowden
jklowden at schemamania.org
Wed May 4 22:34:31 EDT 2005
James McGowan wrote:
> Thanks for the massive reply (I get the feeling you've been asked this
> question before.)
You're right. I'm practicing. :-) It's almost a faq, because dynamic
linking is pretty mysterious to most people.
> I set LD_LIBRARY_PATH as you suggested and tried to
For the record, that's not what I suggest. I'm sorry if I wasn't clear.
LD_LIBRARY_PATH is used by the run-time linker to search for .so objects.
You would just have to set it before running sqsh, no rebuilding
Instead, though, I suggest you use the static linker to add rpath
information to the sqsh executable. The run-time linker will consult the
rpath before looking at things like LD_LIBRARY_PATH, so you won't have to
worry about environment variables. It's also more secure.
> recompile sqsh version 2.1. This time gcc gags as follows:
> /opt/sybase/lib/libintl.so: undefined reference to `__ctype_b'
> collect2: ld returned 1 exit status
> make: *** [sqsh] Error 1
> make: Leaving directory `/usr/src/sqsh-2.1.3/src'
> make: *** [build-subdirs] Error 2
Something else changed. Setting LD_LIBRARY_PATH doesn't affect your build
afaik. Adding rpath information to the ELF binary wouldn't cause ld(1)
(the static linker) to change *its* search path. Did you change
src/Makefile? Could you post a diff?
You should be able to revert to known point, where the build completes but
ldd(1) tells you it can't find libct. Then try to add
"-Wl,-R/opt/sybase/lib" (I believe) to SYBASE_LIBDIR. It should still
build, but ldd and readelf should show that your new executable has an
Note there's no whitepace in "-Wl,-R/opt/sybase/lib". And that's 'Wl',
little 'L', as in link, not 'W1'.
Note too that I use NetBSD, not Linux, and I'm not sure which ld(1) you've
got, making it important to review the info pages I referred you to. If
'-R' of your ld doesn't mean "add this directory to the RPATH", you'll
have to use '-rpath' instead. (Mine is GNU ld version 2.14 20030612.)
> Clueless as usual, I wonder if you've seen THAT before. If it is still
> the linker, I don't know where else to tell it to look.
In these days of shared libraries, we can't speak of "the linker" anymore.
There's ld, the static linker, that brings together your static objects
and prepares an executable image. And there's the run-time linker, that
finishes the job, finding (and resolving) the shared objects just when the
executable is launched.
You came in the door with a run-time linker problem, and have regressed to
a static linking problem (everyone's favorite -- not). Let's see if we
can get you back to where you started, and go forward this time. ;-)
You're welcome. Must've caught me on a good day.
> > -----Original Message-----
> > From: freetds-bounces at lists.ibiblio.org
> > [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of James
> > K. Lowden
> > Sent: Wednesday, May 04, 2005 4:17 PM
> > To: FreeTDS Development Group
> > Subject: Re: [freetds] sqsh won't run
> > James McGowan wrote:
> > > I've installed sqsh version .. on a Redhat 9 system with Sybase ASE
> > > 10.0.0 and I get this message when I attempt to execute it:
> > >
> > > /usr/local/bin/sqsh.bin: error while loading shared libraries:
> > > libct.so.0: cannot open shared object file: No such file or
> > directory
> > The problem is that your run-time linker isn't looking where
> > libct.so.0 is to be found. Other libraries might also be
> > affected (but probably not).
> > You can check with:
> > $ ldd $(command -v sqsh)
> > /usr/local/bin/sqsh:
> > -lc.12 => /usr/lib/libc.so.12
> > -lct.3 => /usr/local/lib/libct.so.3
> > -ltds.5 => /usr/local/lib/libtds.so.5
> > -lm.0 => /usr/lib/libm387.so.0
> > -lm.0 => /usr/lib/libm.so.0
> > -lcrypt.0 => /usr/lib/libcrypt.so.0
> > -lreadline.5 => /usr/pkg/lib/libreadline.so.5
> > -lcurses.6 => /usr/lib/libcurses.so.6
> > As you can see, the run-time linker on my system collects
> > shared objects from three places. By default (on my system)
> > it looks only in /usr/lib.
> > Yours should show a "not found" or two.
> > To tell it where to look, you can tell it where such files
> > might generally be found, or where this one may be found for
> > sqsh. I prefer the latter option. To affect your run-time
> > linker generally, consult your man pages for ld.so or perhaps
> > ld.elf_so. LD_LIBRARY_PATH is a popular knob.
> > The latter choice involves changing the RPATH in the sqsh ELF
> > binary. If you're compiling & linking with gcc, you can pass
> > the linker options with '-Wl'. I did it by modifying
> > src/Makefile in the sqsh tree, changing:
> > SYBASE_LIBDIR = -L$(SYBASE_OCOS)/lib
> > to
> > SYBASE_LIBDIR = -Wl,-R/usr/pkg/lib \
> > -Wl,-R/usr/local/lib \
> > -L$(SYBASE_OCOS)/lib
> > >From the root of the sqsh tree, change src/Makefile as above
> > >(substituting
> > your system's path to libct.so.0, of course), then:
> > $ rm src/sqsh; make
> > You should see your '-Wl' arguments pop up there. To check your work:
> > $ readelf -d $(command -v sqsh) | sed -ne1,/RPATH/p
> > Dynamic segment at offset 0x286a4 contains 24 entries:
> > Tag Type Name/Value
> > 0x00000001 (NEEDED) Shared library: [libct.so.3]
> > 0x00000001 (NEEDED) Shared library: [libtds.so.5]
> > 0x00000001 (NEEDED) Shared library: [libm.so.0]
> > 0x00000001 (NEEDED) Shared library: [libcrypt.so.0]
> > 0x00000001 (NEEDED) Shared library: [libreadline.so.5]
> > 0x00000001 (NEEDED) Shared library: [libcurses.so.6]
> > 0x00000001 (NEEDED) Shared library: [libc.so.12]
> > 0x0000000f (RPATH) Library rpath: [/usr/pkg/lib:/usr/local/lib]
> > For more, cf.:
> > $ info -f gcc --index='Wl'
> > $ info -f ld --index='-R FILE'
> > Isn't consistency wonderful?
> > HTH.
> > --jkl
More information about the FreeTDS