Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#42756 closed defect (fixed)

macports doesn't compile with bundled tcl

Reported by: xeron (Ivan Larionov) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: base Version: 2.2.99
Keywords: Cc: raimue (Rainer Müller), cooljeanius (Eric Gallager)
Port:

Description

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.

Attachments (2)

config.log (68.7 KB) - added by xeron (Ivan Larionov) 10 years ago.
build.log (239.4 KB) - added by xeron (Ivan Larionov) 10 years ago.

Download all attachments as: .zip

Change History (23)

comment:1 in reply to:  description ; Changed 10 years ago by 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.

comment:2 Changed 10 years ago by raimue (Rainer Müller)

Cc: raimue@… added

Cc Me!

comment:3 in reply to:  1 ; Changed 10 years ago by 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.

comment:4 Changed 10 years ago by 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...

Version 0, edited 10 years ago by cooljeanius (Eric Gallager) (next)

comment:5 Changed 10 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:6 in reply to:  4 ; Changed 10 years ago by 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.

Last edited 10 years ago by neverpanic (Clemens Lang) (previous) (diff)

comment:7 in reply to:  3 ; Changed 10 years ago by 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?

comment:8 in reply to:  6 ; Changed 10 years ago by 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...

comment:9 in reply to:  7 Changed 10 years ago by 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 ;-)

comment:10 in reply to:  8 Changed 10 years ago by 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.

comment:11 in reply to:  7 ; Changed 10 years ago by 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?).

comment:12 in reply to:  11 Changed 10 years ago by 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.

comment:13 in reply to:  11 ; Changed 10 years ago by 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.

comment:14 in reply to:  13 Changed 10 years ago by 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...

Last edited 10 years ago by cooljeanius (Eric Gallager) (previous) (diff)

comment:15 Changed 10 years ago by neverpanic (Clemens Lang)

Resolution: fixed
Status: newclosed

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.

comment:16 Changed 10 years ago by xeron (Ivan Larionov)

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

comment:17 Changed 10 years ago by xeron (Ivan Larionov)

Resolution: fixed
Status: closedreopened

comment:18 Changed 10 years ago by neverpanic (Clemens Lang)

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

Changed 10 years ago by xeron (Ivan Larionov)

Attachment: config.log added

Changed 10 years ago by xeron (Ivan Larionov)

Attachment: build.log added

comment:19 Changed 10 years ago by xeron (Ivan Larionov)

Done.

comment:20 Changed 10 years ago by neverpanic (Clemens Lang)

Resolution: fixed
Status: reopenedclosed

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.

comment:21 Changed 10 years ago by xeron (Ivan Larionov)

Works now. Thank you!

Note: See TracTickets for help on using tickets.