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 11:08:22

On Sat, Oct 25, 2008 at 8:43 AM, Alexander Sack <pisymbol_at_[hidden]> wrote:
> 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.

Looks like in trunk someone beat me to it!!!  This is fixed with:

BOOST_REGEX_ICU_OPTS = "<target-os>freebsd:<include>/usr/local/include" ;

Thanks!

-aps