tcl @8.6.0's tclConfig.sh script contains MacPorts build directories

[cooljeanius (Eric Gallager)]

specifically:

# String to pass to linker to pick up the Tcl library from its
# build directory.
TCL_BUILD_LIB_SPEC='-L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_tcl/tcl/work/tcl8.6.0/unix -ltcl8.6'

# Location of the top-level source directory from which Tcl was built.
# This is the directory that contains a README file as well as
# subdirectories such as generic, unix, etc.  If Tcl was compiled in a
# different place than the directory containing the source files, this
# points to the location of the sources, not the location where Tcl was
# compiled.
TCL_SRC_DIR='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_tcl/tcl/work/tcl8.6.0'

# String to pass to linker to pick up the Tcl stub library from its
# build directory.
TCL_BUILD_STUB_LIB_SPEC='-L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_tcl/tcl/work/tcl8.6.0/unix -ltclstub8.6'

# Path to the Tcl stub library in the build directory.
TCL_BUILD_STUB_LIB_PATH='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_tcl/tcl/work/tcl8.6.0/unix/libtclstub8.6.a'

This makes it difficult to manually compile Tcl extensions against MacPorts's Tcl.

[neverpanic (Clemens Lang)]

This is actually expected. $TCL_BUILD_STUB_LIB_SPEC is for the cases when you're building your own Tcl in-tree and want to link against that from its build (as opposed to install) location.

If you use the macros from tcl.m4 in your autoconf-based build system it will automatically choose the right set of variables for you.

[neverpanic (Clemens Lang)]

Also see /usr/lib/tclConfig.sh:

TCL_BUILD_LIB_SPEC='-F/private/var/tmp/tcl/tcl-102~350/OBJROOT2/tcl/Deployment -framework Tcl'

[cooljeanius (Eric Gallager)]

Replying to cal@…:

This is actually expected. $TCL_BUILD_STUB_LIB_SPEC is for the cases when you're building your own Tcl in-tree and want to link against that from its build (as opposed to install) location.

I think that actually might have been what I was trying to do (I have a copy of Tcl in-tree for my fork of apple-gdb, for use with gdbtk), and I think that I must have just forgot to tell it to use the in-tree one instead of the MacPorts one... although then again, if this is from 8 months ago, I do not think that I had actually started work on that by that point, so maybe it was for something different, I forget...

If you use the macros from tcl.m4 in your autoconf-based build system it will automatically choose the right set of variables for you.

The macros in the standard tcl.m4 are also pretty out-of-date, so I usually modify the copy I use to bring it more up-to-date, and it is possible that one of these modifications might have accidentally messed up the variables that it chose... anyway, either way it was probably a user error on my part, so I am okay with the closing of this.

[neverpanic (Clemens Lang)]

Replying to egall@…:

I think that actually might have been what I was trying to do (I have a copy of Tcl in-tree for my fork of apple-gdb, for use with gdbtk), and I think that I must have just forgot to tell it to use the in-tree one instead of the MacPorts one... although then again, if this is from 8 months ago, I do not think that I had actually started work on that by that point, so maybe it was for something different, I forget...

Make sure that right next to the tclConfig.sh file picked up by your configure script there also is a Makefile. That's the test tcl.m4 uses to determine whether to use the build variables.

The macros in the standard tcl.m4 are also pretty out-of-date, so I usually modify the copy I use to bring it more up-to-date, and it is possible that one of these modifications might have accidentally messed up the variables that it chose... anyway, either way it was probably a user error on my part, so I am okay with the closing of this.

In what way are the macros in tcl.m4 out of date?

[cooljeanius (Eric Gallager)]

Replying to cal@…:

Replying to egall@…:

The macros in the standard tcl.m4 are also pretty out-of-date, so I usually modify the copy I use to bring it more up-to-date, and it is possible that one of these modifications might have accidentally messed up the variables that it chose... anyway, either way it was probably a user error on my part, so I am okay with the closing of this.

In what way are the macros in tcl.m4 out of date?

Try running autoreconf with the -Wall flag in a project that contains the standard tcl.m4 file in it, and uses all the macros from it (actually let me whip up a reduced test case to do that). It will print a bunch of warnings about obsolete macros:
(will paste results here later)
You can run autoupdate on it, but doing that leaves behind some artifacts that have to be fixed manually. I will attach a diff to illustrate in a bit.