macports doesn't compile with bundled tcl

[xeron (Ivan Larionov)]

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.

[neverpanic (Clemens Lang)]

Replying to 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.

[raimue (Rainer Müller)]

Cc Me!

[xeron (Ivan Larionov)]

Replying to cal@…:

Replying to 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.

[cooljeanius (Eric Gallager)]

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...

[cooljeanius (Eric Gallager)]

Cc Me!

[neverpanic (Clemens Lang)]

Replying to 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 (actually the curl one does, but the others are gone). That reminds me that the CFLAGS and LDFLAGS the user set also cause MacPorts to link against it's own curl, which is a bad idea, IMO.

[neverpanic (Clemens Lang)]

Replying to 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?

[cooljeanius (Eric Gallager)]

Replying to cal@…:

Replying to 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...

[danielluke (Daniel J. Luke)]

Replying to 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 ;-)

[larryv (Lawrence Velázquez)]

Replying to egall@…:

Replying to 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.

[xeron (Ivan Larionov)]

Replying to 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?).

[jmroot (Joshua Root)]

Replying to xeron.oskom@…:

Replying to 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.

[neverpanic (Clemens Lang)]

Replying to 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 xeron.oskom@…:

Replying to 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.

[cooljeanius (Eric Gallager)]

Replying to cal@…:

Replying to 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?

Edit: lol, that actually turned out to be my own patch that I submitted in #37583 that was committed in r101415... sorry about that...

[neverpanic (Clemens Lang)]

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.

[xeron (Ivan Larionov)]

Latest svn version still doesn't compile. Same error.

[neverpanic (Clemens Lang)]

Please attach config.log and the output of the failed build.

[xeron (Ivan Larionov)]

Done.

[neverpanic (Clemens Lang)]

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.

[xeron (Ivan Larionov)]

Works now. Thank you!