[MacPorts] #42756: macports doesn't compile with bundled tcl
#42756: macports doesn't compile with bundled tcl ---------------------------+-------------------------------- Reporter: xeron.oskom@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.2.99 Keywords: | Port: ---------------------------+-------------------------------- tcl bundled macports coudn't be compiled if tcl already installed and $LDFLAGS and/or $CPPFLAGS include macports dirs {{{ /Users/xeron/workspace/devel/macports/vendor/tcl8.5.15/unix/../libtommath/bn_mp_cmp.c:20:1: error: conflicting types for 'TclBN_mp_cmp' mp_cmp (mp_int * a, mp_int * b) ^ /opt/local/include/tclTomMathDecls.h:63:16: note: expanded from macro 'mp_cmp' #define mp_cmp TclBN_mp_cmp ^ /opt/local/include/tclTomMathDecls.h:158:13: note: previous declaration is here EXTERN int TclBN_mp_cmp(const mp_int *a, const mp_int *b); ^ 1 error generated. make[2]: *** [bn_mp_cmp.o] Error 1 make[1]: *** [all-tcl] Error 2 make: *** [all] Error 1 }}} {{{ $ echo $LDFLAGS -L/opt/local/lib $ echo $CPPFLAGS -I/opt/local/include $ sudo port installed | grep "tcl" tcl @8.6.1_0+corefoundation+threads+universal (active) }}} With empty $LDFLAGS and $CPPFLAGS it compiles w/o any issues. -- Ticket URL: <https://trac.macports.org/ticket/42756> MacPorts <http://www.macports.org/> Ports system for OS X
#42756: macports doesn't compile with bundled tcl ----------------------------+-------------------------------- Reporter: xeron.oskom@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.2.99 Resolution: | Keywords: Port: | ----------------------------+-------------------------------- Comment (by cal@…): Replying to [ticket:42756 xeron.oskom@…]:
tcl bundled macports coudn't be compiled if tcl already installed and $LDFLAGS and/or $CPPFLAGS include macports dirs
What's your use case for doing this anyway? I'd say it's a bad idea and unsupported; we even strip MacPorts dirs from $PATH deliberately at the beginning of `./configure`. I could extend the check to remove `-I$prefix/include` from `CPPFLAGS` and `-L$prefix/lib` from `LDFLAGS`, but that would be unexpected to a user actually specifying them. I think this is a user error – feel free to convince me that it isn't, and if you can suggest how this can be solved. -- Ticket URL: <https://trac.macports.org/ticket/42756#comment:1> MacPorts <http://www.macports.org/> Ports system for OS X
#42756: macports doesn't compile with bundled tcl ----------------------------+-------------------------------- Reporter: xeron.oskom@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.2.99 Resolution: | Keywords: Port: | ----------------------------+-------------------------------- Comment (by xeron.oskom@…): Replying to [comment:1 cal@…]:
Replying to [ticket:42756 xeron.oskom@…]:
tcl bundled macports coudn't be compiled if tcl already installed and $LDFLAGS and/or $CPPFLAGS include macports dirs
What's your use case for doing this anyway? I'd say it's a bad idea and unsupported; we even strip MacPorts dirs from $PATH deliberately at the beginning of `./configure`. I could extend the check to remove `-I$prefix/include` from `CPPFLAGS` and `-L$prefix/lib` from `LDFLAGS`, but that would be unexpected to a user actually specifying them.
I think this is a user error – feel free to convince me that it isn't, and if you can suggest how this can be solved.
Because I would like any software which requires compilation (ruby gems natives, compilation by hands, etc) to use macports libs and headers. And also https://rvm.io/integration/macports-before-autolibs If you want to use bundled tcl I think it's good idea to ensure there're no other tcls in any compiler paths and don't blame user. -- Ticket URL: <https://trac.macports.org/ticket/42756#comment:3> MacPorts <http://www.macports.org/> Ports system for OS X
#42756: macports doesn't compile with bundled tcl ----------------------------+-------------------------------- Reporter: xeron.oskom@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.2.99 Resolution: | Keywords: Port: | ----------------------------+-------------------------------- Comment (by egall@…): Perhaps there could be a `--with-bundled-tcl` flag for the configure script to control whether the bundled tcl gets built or not? Or a `--with- tcl-prefix=` flag to control which already-installed copy of Tcl gets used, if any? There are already precedents for both in MacPorts, as I remember there being a `--with-included-tclthread` flag previously, and there are also `--with-curlprefix` and `--with-sqlite3prefix` flags for choosing the prefix of curl and sqlite3 respectively... -- Ticket URL: <https://trac.macports.org/ticket/42756#comment:4> MacPorts <http://www.macports.org/> Ports system for OS X
#42756: macports doesn't compile with bundled tcl ----------------------------+-------------------------------- Reporter: xeron.oskom@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.2.99 Resolution: | Keywords: Port: | ----------------------------+-------------------------------- Comment (by cal@…): Replying to [comment:4 egall@…]:
Perhaps there could be a "`--with-bundled-tcl`" flag for the configure script to control whether the bundled tcl gets built or not? Or a "`--with-tcl-prefix=`" flag to control which already-installed copy of Tcl gets used, if any?
That increases the possibility for misconfigurations (such as choosing Tcl 8.6), increases the complexity required in order to get the blessed tclsh load the macports source from the correct path (which we could just rip out and be done with in the current state, because we control the Tcl library path) and is generally even more autoconf work to do, which I'd like to avoid.
There are already precedents for both in MacPorts, as I remember there being a "`--with-included-tclthread`" flag previously, and there are also "`--with-curlprefix`" and "`--with-sqlite3prefix`" flags for choosing the prefix of curl and sqlite3 respectively...
Check again, those no longer exist. -- Ticket URL: <https://trac.macports.org/ticket/42756#comment:6> MacPorts <http://www.macports.org/> Ports system for OS X
#42756: macports doesn't compile with bundled tcl ----------------------------+-------------------------------- Reporter: xeron.oskom@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.2.99 Resolution: | Keywords: Port: | ----------------------------+-------------------------------- Comment (by cal@…): Replying to [comment:3 xeron.oskom@…]:
Because I would like any software which requires compilation (ruby gems natives, compilation by hands, etc) to use macports libs and headers. And also https://rvm.io/integration/macports-before-autolibs
That's certainly a good reason for having those variables set, but do you need them when compiling MacPorts?
If you want to use bundled tcl I think it's good idea to ensure there're no other tcls in any compiler paths and don't blame user.
I'm not sure that's easy to test, though. I can certainly test whether Tcl headers are somewhere in the paths specified by `CPPFLAGS`, but since there are Tcl headers in `/usr/include` the test would always succeed (and having them in `/usr/include` is not a problem, just adding them to `CPPFLAGS` is because those are apparently put ahead of Tcl's own CPPFLAGS in their build system (which '''is''' the sane place to but them, btw)). Of course I could remove `-I$prefix/include` from CPPFLAGS and `-L$prefix/lib` from LDFLAGS if they are found, but there might be users out there who did set those variables on purpose when building macports and might wonder why they're getting stripped. Does this problem occur when running selfupdate or when compiling MacPorts from source? -- Ticket URL: <https://trac.macports.org/ticket/42756#comment:7> MacPorts <http://www.macports.org/> Ports system for OS X
#42756: macports doesn't compile with bundled tcl ----------------------------+-------------------------------- Reporter: xeron.oskom@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.2.99 Resolution: | Keywords: Port: | ----------------------------+-------------------------------- Comment (by egall@…): Replying to [comment:6 cal@…]:
Replying to [comment:4 egall@…]:
Perhaps there could be a "`--with-bundled-tcl`" flag for the configure script to control whether the bundled tcl gets built or not? Or a "`--with-tcl-prefix=`" flag to control which already-installed copy of Tcl gets used, if any?
That increases the possibility for misconfigurations (such as choosing Tcl 8.6), If a user is building from source themselves, they should be aware of that. Also I fail to see why choosing Tcl 8.6 is considered a "mis"configuration. and is generally even more autoconf work to do, which I'd like to avoid. I like doing autoconf work, you could always let me do that for you. Heck, I may even already have such flags in my own fork of MacPorts, let me check...
There are already precedents for both in MacPorts, as I remember there
being a "`--with-included-tclthread`" flag previously, and there are also "`--with-curlprefix`" and "`--with-sqlite3prefix`" flags for choosing the prefix of curl and sqlite3 respectively...
Check again, those no longer exist (actually the curl one does, but the
others are gone). I just checked out trunk and the sqlite3 one still exists, too. Also while the "`--with-included-tclthread`" flag may be gone now, I would argue that should be brought back as well, as its presence has often made the difference between compilation success and failure for me... -- Ticket URL: <https://trac.macports.org/ticket/42756#comment:8> MacPorts <http://www.macports.org/> Ports system for OS X
#42756: macports doesn't compile with bundled tcl ----------------------------+-------------------------------- Reporter: xeron.oskom@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.2.99 Resolution: | Keywords: Port: | ----------------------------+-------------------------------- Comment (by dluke@…): Replying to [comment:7 cal@…]:
Of course I could remove `-I$prefix/include` from CPPFLAGS and `-L$prefix/lib` from LDFLAGS if they are found, but there might be users out there who did set those variables on purpose when building macports and might wonder why they're getting stripped.
It's more likely that people are going to set that by mistake than purposely create a situation where their base build/install is dependent on something that it might uninstall. I would favor removing those flags (like we do for $PATH) just to prevent that dependency cycle. If someone really wants/needs it, they can go mess with autoconf ;-) -- Ticket URL: <https://trac.macports.org/ticket/42756#comment:9> MacPorts <http://www.macports.org/> Ports system for OS X
#42756: macports doesn't compile with bundled tcl ----------------------------+-------------------------------- Reporter: xeron.oskom@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.2.99 Resolution: | Keywords: Port: | ----------------------------+-------------------------------- Comment (by larryv@…): Replying to [comment:8 egall@…]:
Replying to [comment:6 cal@…]:
That increases the possibility for misconfigurations (such as choosing Tcl 8.6), If a user is building from source themselves, they should be aware of that. Also I fail to see why choosing Tcl 8.6 is considered a "mis"configuration.
It’s a misconfiguration because we don’t support it.
I just checked out trunk and the sqlite3 one still exists, too. Also while the "`--with-included-tclthread`" flag may be gone now, I would argue that should be brought back as well
This isn’t the place for this conversation (take it to macports-dev if you wish), but I strongly oppose adding more configuration flags than the ones we already have. I wouldn’t be opposed to removing even more of them. -- Ticket URL: <https://trac.macports.org/ticket/42756#comment:10> MacPorts <http://www.macports.org/> Ports system for OS X
#42756: macports doesn't compile with bundled tcl ----------------------------+-------------------------------- Reporter: xeron.oskom@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.2.99 Resolution: | Keywords: Port: | ----------------------------+-------------------------------- Comment (by xeron.oskom@…): Replying to [comment:7 cal@…]:
That's certainly a good reason for having those variables set, but do you need them when compiling MacPorts?
No I don't. But also I don't want to cleanup them by hands before macports compilation.
Does this problem occur when running selfupdate or when compiling MacPorts from source?
Compiling from source. Haven't tested with selfupdate (Is it possible to get SVN version of macports with selfupdate?). -- Ticket URL: <https://trac.macports.org/ticket/42756#comment:11> MacPorts <http://www.macports.org/> Ports system for OS X
#42756: macports doesn't compile with bundled tcl ----------------------------+-------------------------------- Reporter: xeron.oskom@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.2.99 Resolution: | Keywords: Port: | ----------------------------+-------------------------------- Comment (by jmr@…): Replying to [comment:11 xeron.oskom@…]:
Replying to [comment:7 cal@…]:
Does this problem occur when running selfupdate or when compiling MacPorts from source?
Compiling from source. Haven't tested with selfupdate (Is it possible to get SVN version of macports with selfupdate?).
All of base uses a clean environment, so I would highly doubt it’s a problem with selfupdate. -- Ticket URL: <https://trac.macports.org/ticket/42756#comment:12> MacPorts <http://www.macports.org/> Ports system for OS X
#42756: macports doesn't compile with bundled tcl ----------------------------+-------------------------------- Reporter: xeron.oskom@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.2.99 Resolution: | Keywords: Port: | ----------------------------+-------------------------------- Comment (by cal@…): Replying to [comment:8 egall@…]:
If a user is building from source themselves, they should be aware of that. Also I fail to see why choosing Tcl 8.6 is considered a "mis"configuration.
In that case you obviously haven't tried doing that. It currently breaks MacPorts (in a completely un-obvious way) because MacPorts declares `try` in a way incompatible with the command added natively to Tcl 8.6.
I just checked out trunk and the sqlite3 one still exists, too. Also while the "`--with-included-tclthread`" flag may be gone now, I would argue that should be brought back as well, as its presence has often made the difference between compilation success and failure for me...
If that's the case then you should file a bug against the Tcl Thread package and ask them to fix the problem caused by the build. The problem might however be gone by now, because I also updated the included Tcl Thread package to 2.7.0. The `--with-included-tclthread` flag was actually never necessary IMO – base before the recent changes would automatically determine whether the host Tcl had the package and enable this option if it didn't. Without this option, trace mode doesn't work. Replying to [comment:11 xeron.oskom@…]:
Replying to [comment:7 cal@…]:
That's certainly a good reason for having those variables set, but do you need them when compiling MacPorts? No I don't. But also I don't want to cleanup them by hands before macports compilation.
That's understandable. Let's wait what the discussion on -dev suggests, but at the moment I'm inclined to do the extra shell scripting/autoconf work to strip those paths automatically.
Compiling from source. Haven't tested with selfupdate (Is it possible to get SVN version of macports with selfupdate?).
No. -- Ticket URL: <https://trac.macports.org/ticket/42756#comment:13> MacPorts <http://www.macports.org/> Ports system for OS X
#42756: macports doesn't compile with bundled tcl ----------------------------+-------------------------------- Reporter: xeron.oskom@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.2.99 Resolution: | Keywords: Port: | ----------------------------+-------------------------------- Comment (by egall@…): Replying to [comment:13 cal@…]:
Replying to [comment:8 egall@…]:
If a user is building from source themselves, they should be aware of that. Also I fail to see why choosing Tcl 8.6 is considered a "mis"configuration.
In that case you obviously haven't tried doing that. It currently breaks MacPorts (in a completely un-obvious way) because MacPorts declares `try` in a way incompatible with the command added natively to Tcl 8.6.
I was just checking tcl.m4's history in trunk, and if it is the case that MacPorts is incompatible with Tcl 8.6, then perhaps r101415 should be reverted? -- Ticket URL: <https://trac.macports.org/ticket/42756#comment:14> MacPorts <http://www.macports.org/> Ports system for OS X
#42756: macports doesn't compile with bundled tcl ----------------------------+-------------------------------- Reporter: xeron.oskom@… | Owner: macports-tickets@… Type: defect | Status: closed Priority: Normal | Milestone: Component: base | Version: 2.2.99 Resolution: fixed | Keywords: Port: | ----------------------------+-------------------------------- Changes (by cal@…): * status: new => closed * resolution: => fixed Comment: Removed the offending values from the environment variables in r117727, regenerated configure in r117728. I won't revert the change to tcl.m4 now because we're no longer using the macro where the change went and might prove useful if we ever want to go back. -- Ticket URL: <https://trac.macports.org/ticket/42756#comment:15> MacPorts <http://www.macports.org/> Ports system for OS X
#42756: macports doesn't compile with bundled tcl ----------------------------+-------------------------------- Reporter: xeron.oskom@… | Owner: macports-tickets@… Type: defect | Status: closed Priority: Normal | Milestone: Component: base | Version: 2.2.99 Resolution: fixed | Keywords: Port: | ----------------------------+-------------------------------- Comment (by xeron.oskom@…): Latest svn version still doesn't compile. Same error. -- Ticket URL: <https://trac.macports.org/ticket/42756#comment:16> MacPorts <http://www.macports.org/> Ports system for OS X
#42756: macports doesn't compile with bundled tcl ----------------------------+-------------------------------- Reporter: xeron.oskom@… | Owner: macports-tickets@… Type: defect | Status: reopened Priority: Normal | Milestone: Component: base | Version: 2.2.99 Resolution: | Keywords: Port: | ----------------------------+-------------------------------- Changes (by xeron.oskom@…): * status: closed => reopened * resolution: fixed => -- Ticket URL: <https://trac.macports.org/ticket/42756#comment:17> MacPorts <http://www.macports.org/> Ports system for OS X
#42756: macports doesn't compile with bundled tcl ----------------------------+-------------------------------- Reporter: xeron.oskom@… | Owner: macports-tickets@… Type: defect | Status: reopened Priority: Normal | Milestone: Component: base | Version: 2.2.99 Resolution: | Keywords: Port: | ----------------------------+-------------------------------- Comment (by cal@…): Please attach config.log and the output of the failed build. -- Ticket URL: <https://trac.macports.org/ticket/42756#comment:18> MacPorts <http://www.macports.org/> Ports system for OS X
#42756: macports doesn't compile with bundled tcl ----------------------------+-------------------------------- Reporter: xeron.oskom@… | Owner: macports-tickets@… Type: defect | Status: reopened Priority: Normal | Milestone: Component: base | Version: 2.2.99 Resolution: | Keywords: Port: | ----------------------------+-------------------------------- Comment (by xeron.oskom@…): Done. -- Ticket URL: <https://trac.macports.org/ticket/42756#comment:19> MacPorts <http://www.macports.org/> Ports system for OS X
#42756: macports doesn't compile with bundled tcl ----------------------------+-------------------------------- Reporter: xeron.oskom@… | Owner: macports-tickets@… Type: defect | Status: closed Priority: Normal | Milestone: Component: base | Version: 2.2.99 Resolution: fixed | Keywords: Port: | ----------------------------+-------------------------------- Changes (by cal@…): * status: reopened => closed * resolution: => fixed Comment: I think this is fixed in r117754 and r117755. The fix is not particularly pretty, and I think this might turn out to be a boomerang later on, especially with newer autoconf versions. -- Ticket URL: <https://trac.macports.org/ticket/42756#comment:20> MacPorts <http://www.macports.org/> Ports system for OS X
#42756: macports doesn't compile with bundled tcl ----------------------------+-------------------------------- Reporter: xeron.oskom@… | Owner: macports-tickets@… Type: defect | Status: closed Priority: Normal | Milestone: Component: base | Version: 2.2.99 Resolution: fixed | Keywords: Port: | ----------------------------+-------------------------------- Comment (by xeron.oskom@…): Works now. Thank you! -- Ticket URL: <https://trac.macports.org/ticket/42756#comment:21> MacPorts <http://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts