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-26 07:28:37

On Sun, Oct 26, 2008 at 3:45 AM, Vladimir Prus <ghost_at_[hidden]> wrote:
> On Saturday 25 October 2008 07:29:56 Steve M. Robbins 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.
>
> Just to clarify -- what exactly #include_next is supposed to do in any
> header installed in /usr/local/include?
>
>> 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.  :-)
>
> I *think* modern gcc will flat out refuse to add an include directory that
> is already searched by defaul.

Btw, this is still broke for FreeBSD as ICU_SEARCH_OPTS needs to be
set to /usr/local/lib for icudata and friends.  I am going to file a
ticket and upload a patch.

-aps