Re: [Boost-build] Build issues with boost/regex and ICU_PATH

Subject: Re: [Boost-build] Build issues with boost/regex and ICU_PATH
From: Alexander Sack (pisymbol_at_[hidden])
Date: 2008-10-25 08:43:59

On Fri, Oct 24, 2008 at 11:29 PM, Steve M. Robbins <steve_at_[hidden]> wrote:
> On Fri, Oct 24, 2008 at 08:51:25AM -0400, Alexander Sack wrote:
>> On Fri, Oct 24, 2008 at 4:43 AM, John Maddock <john_at_[hidden]> wrote:
>
>> > No it's deliberate: adding /usr/include to the list of include paths breaks
>> > most *nix systems, well gcc on Linux anyway.  So any patch has to be BSD
>> > specific.
>>
>> Wait, /usr/local/include breaks gcc on Linux?  I realize /usr/include
>> might but /usr/local/include?
>
> It breaks any GCC, since:
>
> (a) gcc has /usr/local/include on its default include search path, and
> (b) specifying -I /usr/local/include means it is on the path twice, so
> (c) #include_next doesn't work properly.
>
> At least, that's my recollection of the problem (which was many years
> ago on IRIX).  Take it with a grain of salt, since my memory has
> recently been shown to be faulty.  :-)

Steve, this is interesting, on my FreeBSD 6.1-amd64 and
FreeBSD-7.0-amd64 machines I see:

[root_at_hagen ~]# gcc -v -x c -E  -
Using built-in specs.
Configured with: FreeBSD/amd64 system compiler
Thread model: posix
gcc version 3.4.4 [FreeBSD] 20050518
 /usr/libexec/cc1 -E -quiet -v -D_LONGLONG -
ignoring duplicate directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include
End of search list.

But on my 10.5.5 OS X (Darwin) machine I see:

fallingwater-6:~ alexs$ gcc -v -x c -E -
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5484~1/src/configure
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=i686-apple-darwin9 --with-arch=apple --with-tune=generic
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5484)
 /usr/libexec/gcc/i686-apple-darwin9/4.0.1/cc1 -E -quiet -v
-D__DYNAMIC__ - -fPIC -mmacosx-version-min=10.5.5 -mtune=generic
-march=apple
ignoring nonexistent directory
"/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../../i686-apple-darwin9/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc/i686-apple-darwin9/4.0.1/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.

Weird.  I'll bet Linux is different too.  Alright, I'll come up with a
FreeBSD specific patch and resend.  Thanks Steve for the feedback.

-aps