New Ticket     Tickets     Wiki     Browse Source     Timeline     Roadmap     Ticket Reports     Search

Ticket #20190 (closed defect: fixed)

Opened 5 years ago

Last modified 5 years ago

base needs to export RAWCPP

Reported by: ryandesign@… Owned by: ryandesign@…
Priority: Normal Milestone:
Component: ports Version: 1.7.1
Keywords: Cc: jeremyhu@…
Port: xorg-libXt, xorg-libX11

Description

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

Attachments

xorg-libXt.diff (423 bytes) - added by ryandesign@… 5 years ago.
xorg-libX11.diff (498 bytes) - added by ryandesign@… 5 years ago.

Change History

comment:1 Changed 5 years ago by jeremyhu@…

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

comment:2 Changed 5 years ago by ryandesign@…

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?

comment:3 Changed 5 years ago by ryandesign@…

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

comment:4 Changed 5 years ago by ryandesign@…

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}

comment:5 follow-up: ↓ 12 Changed 5 years ago by jeremyhu@…

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.

comment:6 Changed 5 years ago by ryandesign@…

  • Port changed from xorg-libXt to xorg-libXt, xorg-libX11
  • Summary changed from xorg-libXt should use configure.cc and configure.cpp to xorg-libXt and xorg-libX11 should use configure.cc and configure.cpp

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

comment:7 follow-up: ↓ 11 Changed 5 years ago by jeremyhu@…

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?

comment:8 Changed 5 years ago by jeremyhu@…

  • Cc jeremyhu@… added
  • Owner changed from jeremyhu@… to ryandesign@…
  • Component changed from ports to base
  • Summary changed from xorg-libXt and xorg-libX11 should use configure.cc and configure.cpp to base is not properly exporting CC and CPP

comment:9 Changed 5 years ago by jeremyhu@…

  • Milestone set to MacPorts 1.8.0

comment:10 Changed 5 years ago by jeremyhu@…

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

comment:11 in reply to: ↑ 7 Changed 5 years ago by ryandesign@…

  • Summary changed from base is not properly exporting CC and CPP to xorg-libXt and xorg-libX11 should use configure.cc and configure.cpp
  • Component changed from base to ports
  • Milestone MacPorts 1.8.0 deleted

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.

comment:12 in reply to: ↑ 5 Changed 5 years ago by ryandesign@…

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.

Changed 5 years ago by ryandesign@…

Changed 5 years ago by ryandesign@…

comment:13 Changed 5 years ago by ryandesign@…

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

comment:14 Changed 5 years ago by jeremyhu@…

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.

comment:15 Changed 5 years ago by jeremyhu@…

  • Summary changed from xorg-libXt and xorg-libX11 should use configure.cc and configure.cpp to base needs to export RAWCPP
  • Component changed from ports to base
  • Milestone set to MacPorts 1.8.0

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

comment:16 Changed 5 years ago by blb@…

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

comment:17 Changed 5 years ago by ryandesign@…

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

comment:18 Changed 5 years ago by toby@…

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

comment:19 Changed 5 years ago by ryandesign@…

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

comment:20 Changed 5 years ago by jeremyhu@…

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

comment:21 Changed 5 years ago by jmr@…

  • Component changed from base to ports
  • Milestone MacPorts 1.8.0 deleted

Really doesn't look like base's problem.

comment:22 Changed 5 years ago by jeremyhu@…

  • Status changed from new to closed
  • Resolution set to fixed

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

Note: See TracTickets for help on using tickets.