Michael Peppler
Sybase Consulting
Sybase on Linux
Install Guide for Sybase on Linux
General Sybase Resources
General Perl Resources
BCP Tool
Bug Tracker
Mailing List Archive
Downloads Directory
Sybase on Linux FAQ
Sybperl FAQ
Michael Peppler's resume

sybperl-l Archive

Up    Prev    Next    

From: Harry Bochner <harry dot bochner at genomecorp dot com>
Subject: Re: Client lib 11.1 and DGUX 4.0
Date: Oct 17 1997 10:10PM

Rick Perron wrote:
> I still have need to have LD_LIBRARY_PATH set.  But I had that problem
> with the 10.0.4 client.  Since I went from DU 4.0A to DU 4.0B I have
> been unable to build any of the sybperls (or DBD:Sybase) so that I
> don't need LD_LIBRARY_PATH set.  :(

I think I've got it worked out now. The procedure is simple enough,
but the number of blind alleys I went down figuring it out was

Here's the procedure; comments/explanation follows.
Note this is for sybperl2.08, DGUX4.0[AB], and Sybase client
library 11.1.

0) The usual preparations: hide /usr/shlib/ and
   /usr/local/lib/tcl.a, etc.
1) cd $SYBASE/lib
2) mkdir hide
3) mv *.so hide
4) mv hide/ .
5) cd SybperlSrc
6) edit CONFIG, setting EXTRA_LIBS=-ldnet_stub, and SYBASE=...
7) perl Makefile.PL
8) make
9) make test
10) cd $SYBASE/lib
11) mv hide/* .
12) cd SybperlSrc
13) make test


One of my major problems was that DGUX tends toward uninformative
errors messages where there's a problem with a shared library. The
best way I've found to get more information is
setenv _RLD_ARGS -interactive
(see the man page for "loader")
But remember to unset this when you don't need it; sometimes it
seems to make perl crash with a SEGV :-(

The main thing going on is this: with version 11.1 of the client
libraries (unlike version 10.0.2, the last version I used) you've
got the .so files sitting in the same directory as the .a files.
And the loader will, by default, use .so in preference to .a.
Using the .so files is fine (and saves space), but then the
run-time loader needs to be able to find them, and that tends to
require setting LD_LIBRARY_PATH. (There's supposed to be a way
around this using the -rpath switch to ld, but I wasn't able to
get it to work. Or you could just copy them into some place that's
searched by default ;-)
My preference is to use the .a files instead. The easiest way to
do that is to move them out of the way, as in step 3. (If moving
them isn't practical at your site, you might try copying them to
another directory, and pointing CONFIG at the copy. Or maybe there's
a switch to ld to tell it not to use the .so files?)

For DGUX 4.0A that's basically it, and step 4 isn't needed. But
on DGUX 4.0B, if you run make test without in $SYBASE/lib,
you get this from CTlib:
> Open Client Message:
> Message number: LAYER = (5) ORIGIN = (3) SEVERITY = (5) NUMBER = (131)
> Message String: ct_init(): network packet layer: internal net library > error: Netlib state error - Netlib initialization may have failed doesn't have to be there when you do the make (although
the procedure sketched above has it there for clarity). And DBlib
works without it. But for CTlib it has to be there at run-time. I
find this puzzling (and spent a lot of time working it out! ;-(

That's it, I hope.

Good Luck!

Harry Bochner