[MacPorts] #39752: tcl @8.6.0's tclConfig.sh script contains MacPorts build directories
#39752: tcl @8.6.0's tclConfig.sh script contains MacPorts build directories ---------------------+-------------------------------- Reporter: egall@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Keywords: | Port: tcl ---------------------+-------------------------------- 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. -- Ticket URL: <https://trac.macports.org/ticket/39752> MacPorts <http://www.macports.org/> Ports system for OS X
#39752: tcl @8.6.0's tclConfig.sh script contains MacPorts build directories ----------------------+------------------- Reporter: egall@… | Owner: mww@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: | Keywords: Port: tcl | ----------------------+------------------- Changes (by ryandesign@…): * cc: mww@… (removed) * owner: macports-tickets@… => mww@… -- Ticket URL: <https://trac.macports.org/ticket/39752#comment:1> MacPorts <http://www.macports.org/> Ports system for OS X
#39752: tcl @8.6.0's tclConfig.sh script contains MacPorts build directories ----------------------+-------------------- Reporter: egall@… | Owner: mww@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: invalid | Keywords: Port: tcl | ----------------------+-------------------- Changes (by cal@…): * status: new => closed * resolution: => invalid Comment: 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. -- Ticket URL: <https://trac.macports.org/ticket/39752#comment:2> MacPorts <http://www.macports.org/> Ports system for OS X
#39752: tcl @8.6.0's tclConfig.sh script contains MacPorts build directories ----------------------+-------------------- Reporter: egall@… | Owner: mww@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: invalid | Keywords: Port: tcl | ----------------------+-------------------- Comment (by cal@…): Also see `/usr/lib/tclConfig.sh`: {{{ TCL_BUILD_LIB_SPEC='-F/private/var/tmp/tcl/tcl-102~350/OBJROOT2/tcl/Deployment -framework Tcl' }}} -- Ticket URL: <https://trac.macports.org/ticket/39752#comment:3> MacPorts <http://www.macports.org/> Ports system for OS X
#39752: tcl @8.6.0's tclConfig.sh script contains MacPorts build directories ----------------------+-------------------- Reporter: egall@… | Owner: mww@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: invalid | Keywords: Port: tcl | ----------------------+-------------------- Comment (by egall@…): Replying to [comment:2 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. -- Ticket URL: <https://trac.macports.org/ticket/39752#comment:4> MacPorts <http://www.macports.org/> Ports system for OS X
#39752: tcl @8.6.0's tclConfig.sh script contains MacPorts build directories ----------------------+-------------------- Reporter: egall@… | Owner: mww@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: invalid | Keywords: Port: tcl | ----------------------+-------------------- Comment (by cal@…): Replying to [comment:4 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? -- Ticket URL: <https://trac.macports.org/ticket/39752#comment:5> MacPorts <http://www.macports.org/> Ports system for OS X
#39752: tcl @8.6.0's tclConfig.sh script contains MacPorts build directories ----------------------+-------------------- Reporter: egall@… | Owner: mww@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: invalid | Keywords: Port: tcl | ----------------------+-------------------- Comment (by egall@…): Replying to [comment:5 cal@…]:
Replying to [comment:4 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: [[BR]] (will paste results here later) [[BR]] 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.
-- Ticket URL: <https://trac.macports.org/ticket/39752#comment:6> MacPorts <http://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts