Re: .so and .a libs, tcl, postgres = in over my head

[David Welton <davidw@gate.cks.com>]

On Wed, Jul 01, 1998 at 01:30:15PM -0400, Dan Jacobowitz wrote:
> All right, having seen this behavior recently (in libapache-mod-perl,
> still sitting in incoming waiting for an override file editing :), I'll
> take a stab at this.

Actually, the end result of this is a mod_dtcl (mod_tcl already
exists, but is weird, has no license, and no official page anymore,
and an author who seems to have dissappeared).  

> On Wed, Jul 01, 1998 at 09:42:05AM -0700, David Welton wrote:
> > First, thanks to yourself and Stephen Zander for your replies:-)
> > 
> > On Wed, Jul 01, 1998 at 08:19:09AM +0200, Oliver Elphick wrote:
> > > David Welton wrote:
> > > ...

> > >   >It can run "normal" tcl programs, like
> > >   >puts "hello world", but it seems to choke on the load, like this:
> > >   >@hrothgar [~] $mytclsh tcltest.tcl 
> > >   >couldn't load file "libpgtcl.so": /usr/lib/libpgtcl.so: undefined
> > >   >symbol: Tcl_GetChannel
> > >   >    while executing
> > >   >"load libpgtcl.so"
> > >   >    (file "tcltest.tcl" line 1)
> 
> The first question is whether the symbol is present.  If it is, it's a
> scope problem; if it isn't, it's a linker problem.

I'm not real sure on how to determine that, but.. 
@heorot [~] $ nm /usr/lib/libtcl8.0.a | grep Tcl_GetChannel
         U Tcl_GetChannel
000006c0 T Tcl_GetChannel
00002140 T Tcl_GetChannelBufferSize
00000950 T Tcl_GetChannelHandle
00000990 T Tcl_GetChannelInstanceData
00000920 T Tcl_GetChannelMode
00000930 T Tcl_GetChannelName
00002280 T Tcl_GetChannelOption
00000940 T Tcl_GetChannelType
         U Tcl_GetChannel
         U Tcl_GetChannelBufferSize
         U Tcl_GetChannelHandle
         U Tcl_GetChannelName
         U Tcl_GetChannelOption
         U Tcl_GetChannel
         U Tcl_GetChannelName
         U Tcl_GetChannel
         U Tcl_GetChannelHandle
         U Tcl_GetChannelType
         U Tcl_GetChannel
         U Tcl_GetChannelHandle
         U Tcl_GetChannelInstanceData
         U Tcl_GetChannelType

The section where it is 'T' is tclIO.o.  So.. it seems like it is
there..  
 
> > >   >Interesting.. I try compiling like this:
> > >   >gcc -o mytclsh mytclsh.c /usr/lib/tcl8.0.a /usr/lib/libm.a /usr/lib/libdl.a
> > >   >
> > >   >and I get:
> > >   >@hrothgar [~] $mytclsh tcltest.tcl 
> > >   >couldn't load file "libpgtcl.so": /lib/libcrypt.so.1: undefined symbol:
> > >       >	_ufc_foobar
> > >   >    while executing
> > >   >"load libpgtcl.so"
> > >   >    (file "tcltest.tcl" line 1)
> 
> You probably don't want to do that.  I can see a reason for linking
> statically, to libtcl, but you shouldn't statically link to libraries
> you know will be available unless absolutely necessary.

Someone told me that was the way to do what I wanted:->  I see that
-static works, and it certainly seems cleaner...

> > @hrothgar [~] $gcc -g -o mytclsh mytclsh.c -static -ltcl8.0 -shared
> > -lm -ldl
> [snip]
> > execve("./mytclsh", ["mytclsh", "tcltest.tcl"], [/* 21 vars */]) = 0
> > --- SIGSEGV (Segmentation fault) ---
> > +++ killed by SIGSEGV +++
> > 
> > Wow, that's the fastest I've ever seen anything die.
> 
> Errors that early refer to linking problems.  In this case : -shared is
> meant only for use in actual .so's.  I am guessying that the flag you
> want is -rdynamic, judging from various makefiles lying around.  Try:
> 
> gcc -g -o mytclsh mytclsh.c -rdynamic -ltcl8.0 -lm -ldl

Well, that works (actually, it doesn't but for more mundane reasons -
'er' , the error message thing, is undefined.. :-) Fixing that makes
it go.

But.. my intent is to have a mod_dtcl that I can load into apache.
The current module links like this:

ld -Bshareable -o mod_dtcl.so mod_dtcl-so.o -static -ltcl8.0

And dies when you try and load a page with a 'load' command in it,
presumably for the same reasons mytclsh was dying.  -rdynamic does not
work with -Bshareable.  

> > > On the other hand, it might be that it is impossible to load a shared
> > > library from inside a static library.
> 
> It can be done.  libperl.a is statically linked in when perl is built,
> and contains the dlopen stubs perl uses.

Hrmph...:->

So, what does one read to 'get' some of these concepts better..  The
ideas behind static and shared libs are fairly clear, but.. now I am
getting more curious about what makes this stuff tick..

Thanks,
-- 
David Welton                          http://www.efn.org/~davidw 

	Debian GNU/Linux - www.debian.org


--  
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org