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. Any insight is very welcome. Bernard PS It would be nice if there were a Tcl folder in /opt/local/var/macports/sources/rsync.macports.org/release/ports (just like Python, Ruby, etc) in order to add Portfiles for various Tcl compiled extensions. I suppose I'd have to make a feature request for this somewhere. I wrote:

I'm having a problem trying to selfupdate MacPorts on my machine: the configure script stops on the following

checking for Tcl configuration... found /usr/local/lib/tclConfig.sh checking for existence of /usr/local/lib/tclConfig.sh... loading checking for Tcl public headers... /usr/local/include checking for tclsh... /usr/bin/tclsh checking for Tcl package directory... /Library/Tcl checking whether tclsh was compiled with threads... no configure: error: tcl wasn't compiled with threads enabled

I currently have MacPorts 1.5.0 installed from the .dmg archive.

My version of tclsh was 8.4.10 in /usr/bin and probably indeed it was not compiled with threads.

So I installed the MacPorts version of Tcl (sudo port install tcl) thinking that this one would be compiled with threads enabled. This installed version 8.4.15 in /opt/local/bin.

Then trying again to "port -selfupdate"

Same error and still the configure script finds tclsh in /usr/bin checking for tclsh... /usr/bin/tclsh

So I changed the /usr/bin/tclsh symlink so that it points to the newly compiled tclsh: lrwxr-xr-x 1 root wheel 20 Sep 1 14:12 /usr/bin/tclsh -> /opt/local/bin/tclsh

Still I get the same error from the MacPorts configure script.

How can I get out of this ? How do I do to have tclsh compiled with threads enabled? Apparently even with the MacPorts version it is not. I found the following line in /opt/local/lib/tclConfig.sh: # Flag, 1: we built Tcl with threads enables, 0 we didn't TCL_THREADS=0

And why is the MacPorts configure script looking for the wrong Tcl. It is loading /usr/local/lib/tclConfig.sh.

TIA

Bernard

_______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users

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.

Ryan, thanks for the reply. 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" ? cheers, Bernard

Ryan Schmidt wrote:

On Sep 2, 2007, at 01:24, Bernard Desgraupes wrote:

...

Ryan Schmidt wrote:

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.

I understand.

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.

...and this is why it all works just fine like this in the default case. This is because the system's Tcl _is_ compiled with threads enabled (see last line in /usr/lib/tclConfig.sh). I had messed up my installation because I had a freshly compiled Tcl which installed itself in usr/local/bin and was not compiled with threads enabled.

We could of course add --enable-threads to the tcl port if that's desired.

There could be a variant to turn this on. Anyway the current scheme is the best, there's no point relying on a MacPorts-built Tcl when the system's Tcl works just fine. Thanks for the clarification, Bernard