[MacPorts] #20190: xorg-libXt should use configure.cc and configure.cpp
#20190: xorg-libXt should use configure.cc and configure.cpp -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: jeremyhu@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.7.1 Keywords: | Port: xorg-libXt -------------------------------------+-------------------------------------- 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 }}} -- Ticket URL: <http://trac.macports.org/ticket/20190> MacPorts <http://www.macports.org/> Ports system for Mac OS
#20190: xorg-libXt should use configure.cc and configure.cpp -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: jeremyhu@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.7.1 Keywords: | Port: xorg-libXt -------------------------------------+-------------------------------------- Comment(by jeremyhu@…): It's using AC_PROG_CC like every other autoconf build system out there... -- Ticket URL: <http://trac.macports.org/ticket/20190#comment:1> MacPorts <http://www.macports.org/> Ports system for Mac OS
#20190: xorg-libXt should use configure.cc and configure.cpp -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: jeremyhu@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.7.1 Keywords: | Port: xorg-libXt -------------------------------------+-------------------------------------- Comment(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? -- Ticket URL: <http://trac.macports.org/ticket/20190#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS
#20190: xorg-libXt should use configure.cc and configure.cpp -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: jeremyhu@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.7.1 Keywords: | Port: xorg-libXt -------------------------------------+-------------------------------------- Comment(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 }}} -- Ticket URL: <http://trac.macports.org/ticket/20190#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS
#20190: xorg-libXt should use configure.cc and configure.cpp -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: jeremyhu@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.7.1 Keywords: | Port: xorg-libXt -------------------------------------+-------------------------------------- Comment(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} }}} -- Ticket URL: <http://trac.macports.org/ticket/20190#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS
#20190: xorg-libXt should use configure.cc and configure.cpp -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: jeremyhu@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.7.1 Keywords: | Port: xorg-libXt -------------------------------------+-------------------------------------- Comment(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. -- Ticket URL: <http://trac.macports.org/ticket/20190#comment:5> MacPorts <http://www.macports.org/> Ports system for Mac OS
#20190: xorg-libXt and xorg-libX11 should use configure.cc and configure.cpp -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: jeremyhu@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.7.1 Keywords: | Port: xorg-libXt, xorg-libX11 -------------------------------------+-------------------------------------- Changes (by ryandesign@…): * port: xorg-libXt => xorg-libXt, xorg-libX11 Comment: 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". -- Ticket URL: <http://trac.macports.org/ticket/20190#comment:6> MacPorts <http://www.macports.org/> Ports system for Mac OS
#20190: xorg-libXt and xorg-libX11 should use configure.cc and configure.cpp -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: jeremyhu@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.7.1 Keywords: | Port: xorg-libXt, xorg-libX11 -------------------------------------+-------------------------------------- Comment(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? -- Ticket URL: <http://trac.macports.org/ticket/20190#comment:7> MacPorts <http://www.macports.org/> Ports system for Mac OS
#20190: base is not properly exporting CC and CPP -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 1.7.1 Keywords: | Port: xorg-libXt, xorg-libX11 -------------------------------------+-------------------------------------- Changes (by jeremyhu@…): * cc: jeremyhu@… (added) * owner: jeremyhu@… => ryandesign@… * component: ports => base -- Ticket URL: <http://trac.macports.org/ticket/20190#comment:8> MacPorts <http://www.macports.org/> Ports system for Mac OS
#20190: base is not properly exporting CC and CPP -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: MacPorts 1.8.0 Component: base | Version: 1.7.1 Keywords: | Port: xorg-libXt, xorg-libX11 -------------------------------------+-------------------------------------- Changes (by jeremyhu@…): * milestone: => MacPorts 1.8.0 -- Ticket URL: <http://trac.macports.org/ticket/20190#comment:9> MacPorts <http://www.macports.org/> Ports system for Mac OS
#20190: base is not properly exporting CC and CPP -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: MacPorts 1.8.0 Component: base | Version: 1.7.1 Keywords: | Port: xorg-libXt, xorg-libX11 -------------------------------------+-------------------------------------- Comment(by jeremyhu@…): maybe it's just not being exported in configure... ? -- Ticket URL: <http://trac.macports.org/ticket/20190#comment:10> MacPorts <http://www.macports.org/> Ports system for Mac OS
#20190: xorg-libXt and xorg-libX11 should use configure.cc and configure.cpp -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.7.1 Keywords: | Port: xorg-libXt, xorg-libX11 -------------------------------------+-------------------------------------- Changes (by ryandesign@…): * component: base => ports * milestone: MacPorts 1.8.0 => Comment: Replying to [comment:7 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 [comment:3 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 [comment:4 wrote above]. -- Ticket URL: <http://trac.macports.org/ticket/20190#comment:11> MacPorts <http://www.macports.org/> Ports system for Mac OS
#20190: xorg-libXt and xorg-libX11 should use configure.cc and configure.cpp -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.7.1 Keywords: | Port: xorg-libXt, xorg-libX11 -------------------------------------+-------------------------------------- Comment(by ryandesign@…): Replying to [comment:5 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.
-- Ticket URL: <http://trac.macports.org/ticket/20190#comment:12> MacPorts <http://www.macports.org/> Ports system for Mac OS
#20190: xorg-libXt and xorg-libX11 should use configure.cc and configure.cpp -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.7.1 Keywords: | Port: xorg-libXt, xorg-libX11 -------------------------------------+-------------------------------------- Comment(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. -- Ticket URL: <http://trac.macports.org/ticket/20190#comment:13> MacPorts <http://www.macports.org/> Ports system for Mac OS
#20190: xorg-libXt and xorg-libX11 should use configure.cc and configure.cpp -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.7.1 Keywords: | Port: xorg-libXt, xorg-libX11 -------------------------------------+-------------------------------------- Comment(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=b885bb59ec23bb338c8d... so we just need to autoreconf... As for RAWCPP, that's something that base needs to do. -- Ticket URL: <http://trac.macports.org/ticket/20190#comment:14> MacPorts <http://www.macports.org/> Ports system for Mac OS
#20190: base needs to export RAWCPP -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: MacPorts 1.8.0 Component: base | Version: 1.7.1 Keywords: | Port: xorg-libXt, xorg-libX11 -------------------------------------+-------------------------------------- Changes (by jeremyhu@…): * component: ports => base * milestone: => MacPorts 1.8.0 Comment: 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 -- Ticket URL: <http://trac.macports.org/ticket/20190#comment:15> MacPorts <http://www.macports.org/> Ports system for Mac OS
#20190: base needs to export RAWCPP -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: MacPorts 1.8.0 Component: base | Version: 1.7.1 Keywords: | Port: xorg-libXt, xorg-libX11 -------------------------------------+-------------------------------------- Comment(by blb@…): What software besides xorg uses RAWCPP? googling it seems pretty focused on xorg... -- Ticket URL: <http://trac.macports.org/ticket/20190#comment:16> MacPorts <http://www.macports.org/> Ports system for Mac OS
#20190: base needs to export RAWCPP -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: MacPorts 1.8.0 Component: base | Version: 1.7.1 Keywords: | Port: xorg-libXt, xorg-libX11 -------------------------------------+-------------------------------------- Comment(by ryandesign@…): Or, to ask another way, why doesn't xorg use the usual CPP variable like everybody else? -- Ticket URL: <http://trac.macports.org/ticket/20190#comment:17> MacPorts <http://www.macports.org/> Ports system for Mac OS
#20190: base needs to export RAWCPP -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: MacPorts 1.8.0 Component: base | Version: 1.7.1 Keywords: | Port: xorg-libXt, xorg-libX11 -------------------------------------+-------------------------------------- Comment(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. -- Ticket URL: <http://trac.macports.org/ticket/20190#comment:18> MacPorts <http://www.macports.org/> Ports system for Mac OS
#20190: base needs to export RAWCPP -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: MacPorts 1.8.0 Component: base | Version: 1.7.1 Keywords: | Port: xorg-libXt, xorg-libX11 -------------------------------------+-------------------------------------- Comment(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. -- Ticket URL: <http://trac.macports.org/ticket/20190#comment:19> MacPorts <http://www.macports.org/> Ports system for Mac OS
#20190: base needs to export RAWCPP -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: MacPorts 1.8.0 Component: base | Version: 1.7.1 Keywords: | Port: xorg-libXt, xorg-libX11 -------------------------------------+-------------------------------------- Comment(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... -- Ticket URL: <http://trac.macports.org/ticket/20190#comment:20> MacPorts <http://www.macports.org/> Ports system for Mac OS
#20190: base needs to export RAWCPP -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.7.1 Keywords: | Port: xorg-libXt, xorg-libX11 -------------------------------------+-------------------------------------- Changes (by jmr@…): * component: base => ports * milestone: MacPorts 1.8.0 => Comment: Really doesn't look like base's problem. -- Ticket URL: <http://trac.macports.org/ticket/20190#comment:21> MacPorts <http://www.macports.org/> Ports system for Mac OS
#20190: base needs to export RAWCPP --------------------------------------+------------------------------------- Reporter: ryandesign@… | Owner: ryandesign@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 1.7.1 Resolution: fixed | Keywords: Port: xorg-libXt, xorg-libX11 | --------------------------------------+------------------------------------- Changes (by jeremyhu@…): * status: new => closed * resolution: => fixed Comment: 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... -- Ticket URL: <http://trac.macports.org/ticket/20190#comment:22> MacPorts <http://www.macports.org/> Ports system for Mac OS
participants (1)
-
MacPorts