On Sep 2, 2007, at 01:24, Bernard Desgraupes wrote:
Ryan Schmidt wrote:
On Sep 1, 2007, at 12:00, Bernard Desgraupes wrote:
OK, I've solved my problem: I edited the Portfile and added manually --enable-threads to the [configure.args] proc arguments and rebuilt tcl from scratch. Then I fiddled with sym links to make sure that the tclsh in /usr/bin points to /opt/local/bin/ tclsh and similarly with the tclConfig.sh file.
After that, the selfupdate configuration went fine.
I'm still wondering why the --enable-threads configure argument is not present by default (or at least via a variant) if it is needed by something as basic as "port selfupdate". I'm probably missing something.
It sounds like a rogue Tcl in /usr/local was interfering. I recommend you remove it, and anything else you have directly in / usr/local. It will likely interfere with other MacPorts ports. I recommend you install any software you need by using MacPorts. If ports do not exist for software you want, they can probably be created.
Yes, I have aTcl in /usr/local but it seems that this is now the location ($prefix) where Tcl's Makefile installs. In the past the prefix was just /usr. Now the configure script says: if test "${prefix}" = "NONE"; then prefix=/usr/local fi
I periodically rebuild my Tcl (and Tcl.framework too) from newly released sources or from CVS HEAD: so tclsh gets installed in /usr/ local/bin. Never mind, now I'm aware of the issue, I think I can cope with it.
Yet the original question still holds: why doesn't the Tcl Portfile have the --enable-threads argument if threads are required to be enabled when executing a "port selfupdate" ?
Don't know, and there's no tcl maintainer whom we could ask. Does MacPorts even build itself against the MacPorts tcl if it's present? I thought it always used the system's tcl. Well, except obviously in your case it's using the /usr/local tcl but again that's only because gcc always looks there and we don't know how to turn it off. The first lines of /opt/local/bin/port are: #!/bin/sh #\ exec /usr/bin/tclsh "$0" "$@" So it seems the intention is to use the system's tcl, not MacPorts's tcl. We could of course add --enable-threads to the tcl port if that's desired.