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

[Stephen Zander <gibreel@pobox.com>]

>>>>> "David" == David Welton <davidw@gate.cks.com> writes:

[snip c code]

    David> Compiled with gcc -o mytclsh mytclsh.c -ltcl8.0, it seems
    David> to work pretty well, when run like this:

    David> mytclsh foobar.tcl, where foobar.tcl is this:

    David> load libpgtcl.so puts "hello world"

    David> Everything is ok so far...

    David> But, when I compile like so: gcc -o mytclsh mytclsh.c
    David> /usr/lib/tcl8.0.a -lm -ldl

    David> It can run "normal" tcl programs, like puts "hello world",
    David> but it seems to choke on the load, like this: @hrothgar [~]
    David> $mytclsh tcltest.tcl couldn't load file "libpgtcl.so":
    David> /usr/lib/libpgtcl.so: undefined symbol: Tcl_GetChannel
    David> while executing "load libpgtcl.so" (file "tcltest.tcl" line
    David> 1)

    David> I've given a look at this, but...frankly, I'm a bit lost
    David> between all the static and dynamic and what not.

    David> So.. hrmmm.. is this a problem with the
    David> postgres... tcl.. me?

    David> Interesting.. I try compiling like this: gcc -o mytclsh
    David> mytclsh.c /usr/lib/tcl8.0.a /usr/lib/libm.a
    David> /usr/lib/libdl.a

I expect your problem is here: explicitly declaring static libraries
on the command line.  Is there any reason for doing it?  Basicly, it
means you're only including the symbols necessary to resolve mytclsh.o
and aren't getting them published for access by the dynamic linker.
Is there a difference between the two versions of mytclsh if you use nm
on them?

I'm not game to suggest a specific gcc flag(s) to use 'cause I
normally only do obscure shared-lib magic on Solaris but look into
using -static before the -l<lib> flag(s) if you really must avoid
using the dynamic versions of the libs.

-- 
Stephen
---
all coders are created equal; that they are endowed with certain
unalienable rights, of these are beer, net connectivity, and the
pursuit of bugfixes...  - Gregory R Block


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