I think the OpenBSD crowd is a bunch of masturbating monkeys, in that they make such a big deal about concentrating on security to the point where they pretty much admit that nothing else matters to them.
GPS: Fri Oct 19 2001
There are some peculiar things that occur in OpenBSD when building Tcl/Tk extensions.
For some reason when building Tcl using configure without any options it builds libraries with names like this:
libtcl83.so.1.0 libtcl83.a
Most extensions seem to think that the name should be libtcl8.3, so I constantly have to change the -l usage in the Makefile, or use a symbolic link (which I think is messy). This may be related to /bin/sh being pdksh instead of bash like in Linux, or something with sed. I don't know enough about the Tcl/Autoconf build system to tell. There is also a recent version (8.3) of Tcl in the 2.9 ports tree, but I'm still using 2.6, so I can't comment much on it.
Has anybody else run into this problem, and how did you solve it?
LV I don't think it has to do with the shell you are using - instead, it has to do with the way the OS writers want their dynamic libraries written. On SPARC Solaris, the dynamic libraries are normally named /lib/ld.so.1, etc. with SOMETIMES someone creating a symlink of /lib/ld.so to whatever is the latest.
However, there is a problem doing that - if the dynamic library changes an API, and people are linked against the plain .so, their apps break.
In the above case, I'd say the extensions written to look for libtcl.so are wrong and should be fixed...
AK There is actually information in tclConfig.sh which tells the extension writer how library names are composed:
# Indicates whether a version numbers should be used in -l switches
# ("ok" means it's safe to use switches like -ltcl7.5; "nodots" means
# use switches like -ltcl75). SunOS and FreeBSD require "nodots", for
# example.
TCL_LIB_VERSIONS_OK='ok'
GPS That makes sense however my tclConfig.sh has this:
TCL_LIB_VERSIONS_OK='nodots'
I also checked the TCL_LIB_* -l flags, and they all use -ltcl83, not -ltcl8.3
Now that I'm pointing this out, I really think that extensions to Tcl shouldn't use Autoconf. In several of my software projects I've used a Tcl script for configuration. So the user can do something like tclsh8.3 configure to build a Makefile. I manually check with glob for libtcl8.3 or libtcl83 in the configure file, and I parse arguments such as --prefix, --disable-stubs, and --help. It really makes things much easier than using Autoconf.
LV On the other hand, for these simple things, that is easy. However, for dealing with all the various combinations of what functions work which way on what platforms, what commands work with which options, etc. the tcl configure scripts would be hundreds of lines long and each one would have to be hand written - or one would end up writing a framework in tcl that was as complicated and a nuisance as autoconf .
There is no requirement that extension writers use autoconf- but then, there is no requirement that an extension work on your platform. The people who want their extensions to work across many platforms use autoconf rather than spending hundreds of hours developing their own configuration script. I think that is a reasonable alternative.
As for the specific problem you list here - I would suggest submitting a http://tcl.sf.net/ bug report with all the relavent info so that if there is a bug, it is fixed once for all users of openbsd.
SS I can't agree, you may end up writing your framework in Tcl that is NOT as complicated and a nuisance as autoconf, just because you may select a better design, and a better design can't suggest to write a configuration framework as a shell script (that is crap and very limited itself), nor to make simple things as twisted as autoconf is.
Stu That's not wrong, that's how libraries are named on OpenBSD. There is nothing to fix.