[Starkit] System Library mismatches

[Clif Flynt]

Hi,
  I've been having weird problems with building starpacks lately,
and I think it's got to do with the system libraries and versions
of gcc being used in various places.

  I'm using the Tclkit 8.4.9, 8.4.11 and 8.5 from equi4, not building
my own, and the latest sdx and critcl from the equi4 archives.  (Latest
as of November 24/25 when I was thrashing to figure out why working
code stopped working.)

  My application has some Tcl code, and two .so files I build with
critcl.

  When I use the 8.5 tclkit to build the starpack, it works on my
system, but is failing on other systems with an error:

./gutenbrowse: error while loading shared libraries: libstdc++.so.5:
cannot open shared object file: No such file or directory

The user reports that he doesn't have libstdc++.so.5;
$ locate libstdc++.so.5
$ locate libstdc++.so
/usr/lib/libstdc++.so.6.0.5
/usr/lib/libstdc++.so.6.0.4
/usr/lib/libstdc++.so.6
/usr/lib64/libstdc++.so.6.0.5
/usr/lib64/libstdc++.so.6.0.4
/usr/lib64/libstdc++.so.6

  If I build with the 8.4.11 or 8.4.9 starkit (regular and upx)
the application fails when it tries to load my .so libraries.  Just
runing the tclkit and typing "load ./libbzcrit.so" will crash
the tclkit.

  In other work I've been running into problems with stdlibc++
and such being either version 2.3.4 or 3.0 on different systems,
and software that relies on the libraries getting hosed.  It seems
like some distros are not using the naming conventions the way
I thought they were designed to be used.

  Have others run into these problems?  Did I miss the solution
somewhere?

  Is there a way to force a starpack to a fully static build, rather
than relying on system shared libraries?

  Thanks,

  Clif

-- 
.... Clif Flynt ... http://www.cflynt.com ... clif at cflynt.com ...
..Tcl/Tk: A Developer's Guide (2nd edition) - Morgan Kauffman ..
..12th Annual Tcl/Tk Conference:  Oct 24-28, 2005,  Portland, OR.
.............  http://www.tcl.tk/community/tcl2005/  ............