From owner-freebsd-hackers@FreeBSD.ORG Fri May 9 21:12:29 2014 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DEB328E for ; Fri, 9 May 2014 21:12:29 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 585766C0 for ; Fri, 9 May 2014 21:12:28 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-232-70.lns20.per1.internode.on.net [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s49LCOa8018799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 9 May 2014 14:12:26 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <536D44B4.3030708@freebsd.org> Date: Sat, 10 May 2014 05:12:20 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: hackers@FreeBSD.ORG Subject: help needed with apache build on FreeBSD (9-ish) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 21:12:29 -0000 I've been banging my head agains this for a couple of days now and I'm ready to swallow my pride and look for help :-) For $DAYJOB we have an apache 2.2 installed and for reasons I can't go into it can not be done via a port, so We are doing it manually. The build is done in a chroot, which contains a pretty much standard FreeBSD install of vintage 9.0 (ish). The standard apache build is run in the chroot and if the chroot is on an 8.0 based (real) machine is succeeds. If on the other hand the build is on a 9.1 based or 10.0 based VM. if fails with the following error: gmake[3]: Entering directory `/usr/build/buildroot/build/cloudcc/build_x86_64/httpd-2.2.11/srclib/pcre' gmake[4]: Entering directory `/usr/build/buildroot/build/cloudcc/build_x86_64/httpd-2.2.11/srclib/pcre' libtool --silent --mode=link /usr/bin/gcc -g -O0 -L/usr/local/lib -L/usr/build/buildroot/tools/x86_gcc4.2.4/usr/lib -L/usr/build/buildroot/tools/x86_gcc4.2.4/opt/pixel8/lib -o libpcre.la -static maketables.lo get.lo study.lo pcre.lo libtool: link: unable to infer tagged configuration libtool: link: specify a tag with `--tag' gmake[4]: *** [libpcre.la] Error 1 gmake[4]: Leaving directory `/usr/build/buildroot/build/cloudcc/build_x86_64/httpd-2.2.11/srclib/pcre' gmake[3]: *** [install-recursive] Error 1 Now if I go to that directory and run the command EXACTLY as show, I do indeed get that error, but if I run it by hand and as suggested, add "--tag=CC" then it succeeds. to make things more puzzling, the arguments that are run when the same chroot is running in an 8.0 system are slightly different. This also succeeds if I type it in by hand on the 10 based system. libtool --silent --mode=link /usr/bin/gcc -Wall -Wno-unused-parameter -nostdinc -isystem /usr/build/buildroot/tools/x86_gcc4.2.4/us r/include --sysroot /usr/build/buildroot/tools/x86_gcc4.2.4 -g -O0 -L/usr/build/buildroot/tools/x86_gcc4.2.4/usr/lib -L/usr/build/buildroot/tools/x86_gcc4.2.4/opt/pixel8/lib -o libpcre.la -static maketables.lo get.lo study.lo pcre.lo I have two questions. 1/ given that apache has a maze of autoconf/libtool/configure files all over the place, many of which are autogenerated, where, in the original distribution would I find a file into which I can add the aforementionned --tag argument, or failing that, is there any environment variable or make argument to teh main build of apache that would result in that getting set.. 2/ does anyone have any idea why one would fail and the other succeed, when it's the same identical chroot (nfs mounted to different machines. I have set the UNAME_xxx variables and confirmed that they are working. The only environment differences in the chroots are the SUDO_USER and USER variables. (1003 vs 1005) Does anyone know how to find out WHY configure is acting different? hte config.lo files show that configure is deciding the same things, and yet, the command lines differ.. the whole -Wall section is missing from the one that fails. Julian (at witts end)