Loading shared libraries that are not TCL packages

12 views
Skip to first unread message

watkipet

unread,
Aug 27, 2008, 12:02:20 PM8/27/08
to starkit
I've created a Starpack that loads the mysqltcl package. This works
fine on one system that has libmysqlclient.so.15 (part of mysql
client), but the systems I want deploy to use libmysqlclient.so.14 and
my Starpack fails to run.

I doubt that my organization will update mysql accross all the systems
just to run my app. I know I can load shared libraries that are TCL
packages with a starpack. Is it possible to include libmysqlclient.so.
15 (not a TCL package), with my Starpack? If so, how do I do it?

Bezoar

unread,
Aug 28, 2008, 2:01:57 PM8/28/08
to starkit
This may be something you can try. I believe that when the starpack
starts up
it only copies out the tcl shared library s the Operating system can
load it up and then
uses vfs to allow your script to access shared libraries inside the
starpack. The OS does not
know about those libraries nor can it get to them like your script
can. So the only way
this may work is to include the mysql so file in the starpack then
copy it out to a known
location outside the starpack then modify the environment
LD_LIBRARY_PATH to include the
directory where the library is located as its first path. It is
possible that you may need to
do the old fork and exec trick to make this work; so your starpack
will need to operate in
two modes , prep mode and run mode.

set prepmode 1 ; # assume prep mode
if { $argc == 1 } {
# if we have a command line arg then we are in run mode if you have
args to your program your
# means to figure out mode will be different
set prepmode 0
}

if { $prepmode } {
file copy [file join $starkit::dir lib mysqllib.so ] [file join /
tmp mysqlib.so ]
set env(LD_LIBRARY_PATH) [ join [ concat /tmp [split
$env(LD_LIBRARY_PATH) : ] ] : ]
# use nohup? since exec does not replace current running process
with new as in bourne shell
# this is not exactly what I described. If you have Tclx extension
you can use the fork call . Problem
# with just exec'ing like this is that putting it into the
background is necessary to keep it running
# after the parent exit, but may also close off the childs stdin
and stdout. When you fork you get
# your own copy of the stdin and stdout in the child so the parent
exiting does not matter.
exec <starpackname> run &
exit(0);
}

# load up your mysql shared library by requiring mysqltcl which is
now first in line
package require mysqltcl
.... rest o script here

Note this is just an idea of how I would initially approach it and I
have not tried it. I will be
curious if you get this to work. Let us know.

Carl
Reply all
Reply to author
Forward
0 new messages