base needs to export RAWCPP

[ryandesign (Ryan Carsten Schmidt)]

xorg-libXt uses "gcc" and "cpp"; should use ${configure.cc} and ${configure.cpp}; see UsingTheRightCompiler.

$ port -ux upgrade xorg-libXt
--->  Fetching xorg-libXt
--->  Verifying checksum(s) for xorg-libXt
--->  Extracting xorg-libXt
--->  Configuring xorg-libXt
Error: Target org.macports.configure returned: configure failure: shell command " cd "/mp/var/macports/build/_Users_rschmidt_macports_dports_x11_xorg-libXt/work/libXt-1.0.6" && ./configure --prefix=/mp --disable-dependency-tracking " returned error 1
Command output: checking whether the /usr/bin/gcc-4.0 linker (/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin8.11.1 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking whether /usr/bin/gcc-4.0 and cc understand -c and -o together... yes
gcc -dumpversion
gcc: Error: You should be using ${configure.cc}
See http://trac.macports.org/wiki/UsingTheRightCompiler
checking for pkg-config... /mp/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for XT... yes
checking alloca.h usability... yes
checking alloca.h presence... yes
checking for alloca.h... yes
checking for snprintf... yes
checking for main in -lws2_32... no
checking for cpp... /mp/bin/no_default_gcc/cpp
checking if /mp/bin/no_default_gcc/cpp requires -undef... cpp 
cpp: Error: You should be using ${configure.cpp}
See http://trac.macports.org/wiki/UsingTheRightCompiler
cpp -undef
cpp: Error: You should be using ${configure.cpp}
See http://trac.macports.org/wiki/UsingTheRightCompiler
cpp -undef -ansi
cpp: Error: You should be using ${configure.cpp}
See http://trac.macports.org/wiki/UsingTheRightCompiler
configure: error: /mp/bin/no_default_gcc/cpp defines unix with or without -undef.  I don't know what to do.

Error: Unable to upgrade port: 1

[jeremyhu (Jeremy Huddleston Sequoia)]

It's using AC_PROG_CC like every other autoconf build system out there...

[ryandesign (Ryan Carsten Schmidt)]

I don't know how autoconf works, but I know that most other ports manage to use the programs identified by the CC, CXX and CPP environment variables that MacPorts sets for them, and that's we want ports to do as explained in UsingTheRightCompiler. Do you have any insight into how we could most easily convince this part of autoconf to play nicely with us?

[ryandesign (Ryan Carsten Schmidt)]

In the case of the "gcc" issue above, it is not using AC_PROG_CC or any other variable; it is using "gcc". See aclocal.m4:

    case `gcc -dumpversion` in
    3.4.* | 4.*)
	CWARNFLAGS+=" -Wold-style-definition -Wdeclaration-after-statement"
	;;
    esac

[ryandesign (Ryan Carsten Schmidt)]

In the case of the "cpp" issue above, it seems the configure script looks for a variable RAWCPP. So to fix that part, add to the Portfile:

configure.env-append    RAWCPP=${configure.cpp}

[jeremyhu (Jeremy Huddleston Sequoia)]

AC_PROG_CC isn't an environment variable. It's an m4 macro which basically determines what the compiler should be. This is what pretty much *EVERY* autoconf based build system uses to set the compiler. This macro is what sets CC if it isn't already set... CC isn't set outside of this. Further, in my local test with the checkout, CC is honored... I'm puzzled.

Perhaps we need to autoreconf because of a broken autoconf used to make the package? I'll check that later.

[ryandesign (Ryan Carsten Schmidt)]

The same issue applies to xorg-libX11.

I don't believe autoconf specifically is involved; I believe the problem is that the authors of these packages have not made use of the facilities in autoconf for using the discovered compiler, and are instead always using "gcc".

[jeremyhu (Jeremy Huddleston Sequoia)]

Was libX11-1.2.1 ok? Here's the diffstat between 1.2.1 and 1.2.2:

~/src/freedesktop/src/libX11 $ git diff eac57c77afdf44f50692225b8b0345a7c927bc84 75fe48e7a42a685d7098e8d7108b9b956c471563 | diffstat
 configure.ac                   |   17 
 include/X11/Xlib.h             |   21 
 man/XAllocColor.man            |    2 
 man/xkb/XkbGetKeyboard.man     |    2 
 modules/im/ximcp/imThaiFlt.c   |   50 +
 modules/om/generic/omGeneric.c |    2 
 nls/compose.dir.pre            |   17 
 nls/el_GR.UTF-8/Compose.pre    |  441 -----------
 nls/en_US.UTF-8/Compose.pre    | 1607 -----------------------------------------
 nls/fi_FI.UTF-8/Compose.pre    | 1607 -----------------------------------------
 nls/iso8859-1/Compose.pre      |   16 
 nls/iso8859-15/Compose.pre     |    8 
 nls/iso8859-9/Compose.pre      |    8 
 nls/iso8859-9e/Compose.pre     |    8 
 nls/locale.alias.pre           |   39 
 nls/locale.dir.pre             |   15 
 nls/pt_BR.UTF-8/Compose.pre    | 1495 +-------------------------------------
 nls/th_TH.UTF-8/XLC_LOCALE.pre |   12 
 nls/th_TH/XLC_LOCALE.pre       |    6 
 src/ChkMaskEv.c                |    2 
 src/ChkWinEv.c                 |    2 
 src/MaskEvent.c                |    2 
 src/WinEvent.c                 |    2 
 src/XlibInt.c                  |    2 

The only build-level changes are in configure.ac:

diff --git a/configure.ac b/configure.ac
index b4593f4..ab6d5a3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,9 +1,9 @@
 #                                               -*- Autoconf -*-
 # Process this file with autoconf to produce a configure script.
 
-AC_PREREQ(2.57)
+AC_PREREQ(2.60)
 AC_INIT([libX11],
-        1.2.1,
+        1.2.2,
         [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg],
         libX11)
 AC_CONFIG_SRCDIR([Makefile.am])
@@ -18,6 +18,11 @@ AC_CONFIG_HEADER([include/X11/XlibConf.h])
 m4_ifndef([XORG_MACROS_VERSION], [AC_FATAL([must install xorg-macros 1.2 or later before running autoconf/autogen])])
 XORG_MACROS_VERSION(1.2)
 
+# Set common system defines for POSIX extensions, such as _GNU_SOURCE
+# Must be called before any macros that run the compiler (like AC_PROG_LIBTOOL)
+# to avoid autoconf errors.
+AC_USE_SYSTEM_EXTENSIONS
+
 # Checks for programs.
 AC_PROG_LIBTOOL
 DOLT
@@ -364,14 +369,6 @@ if test "x$GCC" = "xyes"; then
        X11_CFLAGS="$GCC_WARNINGS $X11_CFLAGS"
 fi
 
-AC_TRY_COMPILE([
-#include <features.h>
-#ifndef __GLIBC__
-#error not glibc
-#endif
-], [], [AC_DEFINE(_GNU_SOURCE, 1,
-    [ Enable GNU and other extensions to the C environment for glibc])])
-
 X11_DATADIR="${datadir}/X11"
 AC_DEFINE_DIR(X11_DATADIR, X11_DATADIR, [Location of libX11 data])
 AC_SUBST(X11_DATADIR)

So if that change somehow breaks CC, then the bug is not in the lib itself but somewhere in autoconf. Changing the dependency to be 2.60 instead of 2.57 and adding AC_USE_SYSTEM_EXTENSIONS should not break something.

Further, I cannot reproduce your error in libX11-1.2.2 (didn't try the others):

$ CC=/this/is/invalid/cc ./configure
checking for a BSD-compatible install... /opt/local/bin/ginstall -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /opt/local/bin/gmkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for style of include used by make... GNU
checking for gcc... /this/is/invalid/cc
checking for C compiler default output file name... 
configure: error: in `/Users/jeremy/src/freedesktop/src/libX11':
configure: error: C compiler cannot create executables
See `config.log' for more details.

$ grep invalid config.log 
configure:2889: result: /this/is/invalid/cc
configure:3129: /this/is/invalid/cc --version >&5
./configure: line 3131: /this/is/invalid/cc: No such file or directory
configure:3140: /this/is/invalid/cc -v >&5
./configure: line 3142: /this/is/invalid/cc: No such file or directory
configure:3151: /this/is/invalid/cc -V >&5
./configure: line 3153: /this/is/invalid/cc: No such file or directory
configure:3200: /this/is/invalid/cc    conftest.c  >&5
./configure: line 3202: /this/is/invalid/cc: No such file or directory
ac_cv_env_CC_value=/this/is/invalid/cc
ac_cv_prog_ac_ct_CC=/this/is/invalid/cc
CC='/this/is/invalid/cc'
ac_ct_CC='/this/is/invalid/cc'

So this looks like something that is NOT a package bug to me... are you sure CC is being exported?

[jeremyhu (Jeremy Huddleston Sequoia)]

maybe it's just not being exported in configure... ?

[ryandesign (Ryan Carsten Schmidt)]

Replying to jeremyhu@…:

Was libX11-1.2.1 ok?

No, it was also affected. I have only recently written and begun using the script mentioned at the bottom of UsingTheRightCompiler.

Base is not the problem. As I wrote above, the gcc problem is a problem is the configure script (e.g. line 12527 of xorg-libX11 1.2.2's configure script) which says

    case `gcc -dumpversion` in

It is running "gcc"; it is not using any variable to discover what CC we would like to use. I would call this an upstream bug.

And the cpp problem is that the configure script apparently does not respond to the common variable CPP and instead is looking for a variable RAWCPP. This is weird to me and I don't know why they do this but it can be fixed as I wrote above.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jeremyhu@…:

Perhaps we need to autoreconf because of a broken autoconf used to make the package? I'll check that later.

Adding

use_autoconf yes

does in fact remove the "gcc -dumpversion" call from the configure script, leaving only the RAWCPP variable to set.

[ryandesign (Ryan Carsten Schmidt)]

For xorg-libXt, use_autoreconf was needed instead of use_autoconf, so I think I meant use_autoreconf. Patches for both ports attached.

[jeremyhu (Jeremy Huddleston Sequoia)]

It looks like those tarballs were 'make dist'd with old m4 macros... this was fixed over a month ago!

​http://cgit.freedesktop.org/xorg/util/macros/commit/?id=b885bb59ec23bb338c8df68e40c6ef2c2a9325cc

so we just need to autoreconf...

As for RAWCPP, that's something that base needs to do.

[jeremyhu (Jeremy Huddleston Sequoia)]

r53730 r53731 r53732 are fixed as far as I'm concerned... the RAWCPP issue is something that should be done in base... passing the buck

[blb@…]

What software besides xorg uses RAWCPP? googling it seems pretty focused on xorg...

[ryandesign (Ryan Carsten Schmidt)]

Or, to ask another way, why doesn't xorg use the usual CPP variable like everybody else?

[tobypeterson]

It makes no sense to do this in base, ports that need specific environment variables (RAWCPP in this case) should set them appropriately.

[ryandesign (Ryan Carsten Schmidt)]

It could make sense to make an xorg portgroup if this is something every xorg port would otherwise have to do on its own.

[jeremyhu (Jeremy Huddleston Sequoia)]

I asked yesterday in xorg-devel about RAWCPP prefering cpp over $CPP... it was done explicitly, so there has to be a reason...

I'm guess a portgroup would be ok... but I really don't see the point. The only thing that this saves us is that the test environment won't flag a false positive.

Perhaps the better thing to do is just ignore it. All it needs is a generic cpp for man pages and the like. It isn't for code, so $CPP isn't necessary there. Why they don't just use $CPP is beyond me, but I'm guessing there is a reason...

[jmroot (Joshua Root)]

Really doesn't look like base's problem.

[jeremyhu (Jeremy Huddleston Sequoia)]

Well, then it's the test-suite. I don't think that we need to worry about this case. The configure script just expects 'cpp' to be *A* preprocessor (used for man pages and the like). I don't know why thy choose that *explicitly* over $CPP ... but there must've been a reason...