From owner-freebsd-ports@FreeBSD.ORG Fri Sep 16 01:39:48 2011 Return-Path: Delivered-To: freebsd-ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E131B106566B for ; Fri, 16 Sep 2011 01:39:48 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by mx1.freebsd.org (Postfix) with ESMTP id 7D1B18FC0A for ; Fri, 16 Sep 2011 01:39:48 +0000 (UTC) Received: by wyg24 with SMTP id 24so4492040wyg.17 for ; Thu, 15 Sep 2011 18:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=COXcGbSDvp5kw+6WQ7y0J/WKM4Lte8lhxP63niYPHKw=; b=Sud4Wp4O6OGRQ4qPVzxtybn+ePSGBaIE4yqfVbGfJtOaRceQKF0Mp6mjFBdKa0aAIp srIbNf6V0Yp2AOlTLFvcepjAvhnZBgsIxnh1+z8BCp+C/PLUXmtgwXX0irZsCTmRRtW5 mh176OS/osfBu2nEF+GcqyATHrHiimuMpSSbI= MIME-Version: 1.0 Received: by 10.227.176.200 with SMTP id bf8mr668080wbb.77.1316137187193; Thu, 15 Sep 2011 18:39:47 -0700 (PDT) Received: by 10.180.100.1 with HTTP; Thu, 15 Sep 2011 18:39:47 -0700 (PDT) Date: Thu, 15 Sep 2011 21:39:47 -0400 Message-ID: From: "b. f." To: Xavier HUMBERT , freebsd-ports@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: Building caire and $PATH order X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 01:39:49 -0000 > A couple of weeks ago, after installing openssl from ports, I changed > PATH order in my .bash_login, in order to use /usr/local before /usr an > so on. > > Today, I upgraded icu, and its dependants, including cairo. The build > was successful until reaching cairo : > > ----------------------------------------------------------------------- > checking how to allow undefined symbols in shared libraries used by test > suite... checking whether cc supports -Wl,--allow-shlib-undefined... yes > -Wl,--allow-shlib-undefined > checking whether byte ordering is bigendian... no > checking whether float word ordering is bigendian... fopen: No such file > or directory > fopen: No such file or directory > unknown > configure: error: > > Unknown float word ordering. You need to manually preset > ax_cv_c_float_words_bigendian=no (or yes) according to your system. > ----------------------------------------------------------------------- > > Setting PATH with /usr/local *after*, on the command line fixed the > problem. > > Is this a known behavior ? A mess with two include files with the same > name in /usr/include and /usr/local/include ? It is difficult to figure out what went wrong, because you have not isolated the point of failure, or provided a full listing of your environment, the config.log, and a build transcript. The error message is of the kind that would be issued if the conftest.o file for the configure script test were deleted before the test was concluded, which could happen if there were hardware problems, or if the parts of the work directory were removed during the build, so I wonder if this problem is consistently reproducible. Header interposition can occur, but usually happens when you change compilers or tinker with the compiler flags, and not the system path. If your failure wasn't transient, or due to hardware problems, it is more likely that you are using different binary executables with the changed system path, because some of them are called in system Makefiles or configure scripts by their basenames. For instance, in the test that failed: 17786: { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether float word ordering is bigendian" >&5 17787:$as_echo_n "checking whether float word ordering is bigendian... " >&6; } 17788-if test "${ax_cv_c_float_words_bigendian+set}" = set; then : 17789- $as_echo_n "(cached) " >&6 17790-else 17791- 17792- 17793-# The endianess is detected by first compiling C code that contains a special 17794-# double float value, then grepping the resulting object file for certain 17795-# strings of ascii values. The double is specially crafted to have a 17796-# binary representation that corresponds with a simple string. In this 17797-# implementation, the string "noonsees" was selected because the individual 17798-# word values ("noon" and "sees") are palindromes, thus making this test 17799-# byte-order agnostic. If grep finds the string "noonsees" in the object 17800-# file, the target platform stores float words in big-endian order. If grep 17801-# finds "seesnoon", float words are in little-endian order. If neither value 17802-# is found, the user is instructed to specify the ordering. 17803- 17804-ax_cv_c_float_words_bigendian=unknown 17805-cat confdefs.h - <<_ACEOF >conftest.$ac_ext 17806-/* end confdefs.h. */ 17807- 17808- 17809-double d = 90904234967036810337470478905505011476211692735615632014797120844053488865816695273723469097858056257517020191247487429516932130503560650002327564517570778480236724525140520121371739201496540132640109977779420565776568942592.0; 17810- 17811- 17812-_ACEOF 17813-if ac_fn_c_try_compile "$LINENO"; then : 17814- 17815- 17816-if strings - conftest.$ac_objext | grep noonsees >/dev/null ; then 17817- ax_cv_c_float_words_bigendian=yes 17818-fi 17819-if strings - conftest.$ac_objext | grep seesnoon >/dev/null ; then 17820- if test "$ax_cv_c_float_words_bigendian" = unknown; then 17821- ax_cv_c_float_words_bigendian=no 17822- else 17823- ax_cv_c_float_words_bigendian=unknown 17824- fi 17825-fi , without even examining the configure script functions that are called, one can see that 'strings' and 'grep' are called by their basenames, and that changing the path could affect the binary executables used by the test, and thus the test outcome. This isn't desirable, but is common in a lot of configure scripts and Makefiles, so it is not a good idea to change the path arbitrarily. It would be safer to just call the security/openssl utilities by their full pathnames, or at least to only override the basenames of the security/openssl utilities, and not others, by doing something like: mkdir /usr/local/opensslbin ln -s /usr/local/bin/openssl /usr/local/opensslbin/openssl ln -s /usr/local/bin/c_rehash /usr/local/opensslbin/c_rehash and adding /usr/local/opensslbin to your path before /usr/bin. But if you want to learn why the path change caused this failure, or even if it did, then you will have to dig a bit deeper. b.