trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Peach <>
Subject Re: [VOTE] Release v3.3.3
Date Fri, 07 Jun 2013 17:43:41 GMT
On Jun 7, 2013, at 10:13 AM, Nick Kew <> wrote:

> On 7 Jun 2013, at 17:07, Leif Hedstrom wrote:
>> On 6/7/13 10:02 AM, Nick Kew wrote:
>>>>>> checking checking whether to auto-set compiler optimization flags...
>>>>>> configure: error: clang is the only supported on compiler on Darwin
>>>>> FWIW it's detecting my compiler as gnu.  Which seems perverse:
>>>> Nod. Did you try explicitly with clang/clang++ (configure CC=clang CXX=clang++)
>>>> -- Leif
>>> That works (though I also needed to set pcre explicitly: configure
>>> succeeded with the default but build failed).
>> hmmm, I've always have had to use --with-pcre=/usr/local  on my Mac (I use HomeBrew).
> My pcre is somewhat chopped about, for the benefit of something
> else whose pcre usage was causing more serious trouble (refused
> to work with mac native / homebrew build).  Hence that was not
> unexpected, just a mention in passing of the configure/make discrepancy.
> Worked fine with --with-pcre=/usr/local/pcre
>>> It then proceeds to fail test for further spurious reasons that appear
>>> to stem from mixing build components.  But nothing fatal.
>> File bugs as necessary.
> Didn't look like ATS bug.  Rather env bug.
>>> Anyway, whence the CLANG requirement and bizarre manifestation
>>> of the build error?  This is new in 3.3.x but I can't see it in CHANGES.
>> So, the story behind CLANG is complicated. Short story, the old gcc wrapper that
Apple used to support segfaults when compiling ATS. So, we forced it to only work with CLANG/CLANG++.
> gcc was fine with 3.2.x.   I'd expect a CHANGES entry!
> Guess I can't've been listening adequately when it was discussed.

You're right, this wasn't discussed or documented clearly enough. It should be called out
in the release notes.

It's been documented on the wiki for a long time <>,
but that doesn't have a lot of visibility.	

>> The compiler detection was later rewritten, so maybe it's easily possible to test
for "cc" or "c++" and be ok (since those are just clang now). It's important however that
it doesn't pick gcc/g++, cause that will always fail during the compilation phase (since the
compiler segfaults).
> Yet it tried gcc (not cc or clang) first, and only complained as a side-effect
> of testing flex!  That's what I find the most bizarre, and it rather suggests
> the possibility of two bugs cancelling each other.

configure is explicitly error'ing out when it sees GCC on Darwin:

flathead:trafficserver.git jpeach$ git grep 'supported on compiler'      AC_MSG_ERROR([clang is the only supported on compiler on Darwin])
flathead:trafficserver.git jpeach$ git log -S'supported on compiler'
commit aeb7442e67b57158b2e0e87a4b39fd670d9bfa99
Author: James Peach <>
Date:   Fri May 3 10:35:58 2013 -0700

    TS-1872: minor cleanup to compiler flag handling
      - Prefer AS_IF to the case statement.
      - Test for directories before adding them to the linker path.
      - Error out if we are building on Darwin with a non-clang compiler.
      That's almost certainly an ancient version of gcc that won't work.

I expect the flex thing might be a red herring.

>> File bugs on this too :).
> Will do.  Might also try and patch it.

FWIW, I don't think there's any point trying to support Apple's GCC on Darwin. However, it
would be interesting to support upstream GCC from MacPorts or Homebrew, <>.


View raw message