Building caire and $PATH order

[b. f.]

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