llvm dev - Apr 2012 - [LLVMdev] clang++ on MacOSX with fsf-gcc libstdc++?

Hi,
the subject says it all...

After some experimenting, I got a bit confused as far as what the proper thing
to do might be....

I build llvm/clang from trunk sources on OSX Lion 10.7.3 (i.e.
x86_64-apple-darwin11.3.0 to speak GNU's platform-ese) where I also have
successfully built a fsf-gcc 4.6.2 (and lately a 4.7 for that matter) from
sources.
Now, I think I understand that by playing with clang's
lib/Frontend/InitHeaderSearch.cpp you can have clang use whatever libstdc++
include files you want.

Is that really true and fully supported practice, or do you have, when on OSX,
either stick with Apple's (through Xcode-)provided gcc 4.2.1's libstdc++
or the all-new (but still a bit immature) libc++?

I'm aware (after posting http://llvm.org/bugs/show_bug.cgi?id=12303) that if
you build clang with paths tuned for, say, gcc-4.6's libstdc++, then you
have to remember, every time you build something with clang++, to always make
the linker find gcc-4.6's libstdc++, but as cumbersome as it might seem (if
there's some configure hook that avoids the need of always passing
"-L<wherever gcc-4.6'libstdc++ lives>" I'd really be
happy to use it), it's always worked for me.

Until lately, when I built the latest gcc-4.7 and since then clang++ (rebuilt of
course with paths updated for the new compiler) chokes on every cpp file as soon
as I start including something like <iostream> or <vector> etc..

Is it just a problem with gcc-4.7 libstdc++ headers that for some reason clang++
is not (yet) able to digest, or have I always been doing something not supported
on OSX and I've just been lucky that it has been working until now?

Thanks,
Andrea.




-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120412/4e47bb65/attachment.html>

On Thu, Apr 12, 2012 at 10:44 AM, Andrea Bigagli <andrea.bigagli at
me.com> wrote:
> Hi,
> the subject says it all...
>
> After some experimenting, I got a bit confused as far as what the proper
> thing to do might be....
>
> I build llvm/clang from trunk sources on OSX Lion 10.7.3 (i.e.
> x86_64-apple-darwin11.3.0 to speak GNU's platform-ese) where I also
have
> successfully built a fsf-gcc 4.6.2 (and lately a 4.7 for that matter) from
> sources.
> Now, I think I understand that by playing with clang's
> lib/Frontend/InitHeaderSearch.cpp you can have clang use whatever libstdc++
> include files you want.
>
> Is that really true and fully supported practice, or do you have, when on
> OSX, either stick with Apple's (through Xcode-)provided gcc 4.2.1's
> libstdc++ or the all-new (but still a bit immature) libc++?
>
> I'm aware (after
posting http://llvm.org/bugs/show_bug.cgi?id=12303) that if
> you build clang with paths tuned for, say, gcc-4.6's libstdc++, then
you
> have to remember, every time you build something with clang++, to always
> make the linker find gcc-4.6's libstdc++, but as cumbersome as it might
seem
> (if there's some configure hook that avoids the need of always passing
> "-L<wherever gcc-4.6'libstdc++ lives>" I'd really
be happy to use it), it's
> always worked for me.
>
> Until lately, when I built the latest gcc-4.7 and since then clang++
> (rebuilt of course with paths updated for the new compiler) chokes on every
> cpp file as soon as I start including something like <iostream> or
<vector>
> etc..
>
> Is it just a problem with gcc-4.7 libstdc++ headers that for some reason
> clang++ is not (yet) able to digest, or have I always been doing something
> not supported on OSX and I've just been lucky that it has been working
until
> now?
There are known issues with using the libstdc++ 4.7 headers with
clang.  If you're interested in specifics, try searching
llvm.org/bugs/ .(Not that I would call the setup you're using on OSX
"supported", exactly, but there isn't any particular reason it
shouldn't work.)

On a side note, please file bugs if you're running into issues with libc++.

-Eli

If you check the Clang list (cfe-dev-list) the issue dealing with 
atomics for gcc-4.7 has been settled. I can verify this on Debian Linux 
using gcc-4.7 that clang/clang++ builds and no long fails when compiling 
a simple HelloWorld program. Atomics for c++ are now recognized as 
__c11_atomic_* and it builds cleanly from what i've tested.

I presently don't have a 10.7 box to test against trunk, but those 
errors are now gone from Linux.

The thread to read:

http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-April/020686.html

- Marc

On 04/12/2012 10:44 AM, Andrea Bigagli wrote:
> Hi,
> the subject says it all...
>
> After some experimenting, I got a bit confused as far as what the 
> proper thing to do might be....
>
> I build llvm/clang from trunk sources on OSX Lion 10.7.3 (i.e. 
> x86_64-apple-darwin11.3.0 to speak GNU's platform-ese) where I also 
> have successfully built a fsf-gcc 4.6.2 (and lately a 4.7 for that 
> matter) from sources.
> Now, I think I understand that by playing with clang's 
> lib/Frontend/InitHeaderSearch.cpp you can have clang use whatever 
> libstdc++ include files you want.
>
> Is that really true and fully supported practice, or do you have, when 
> on OSX, either stick with Apple's (through Xcode-)provided gcc
4.2.1's
> libstdc++ or the all-new (but still a bit immature) libc++?
>
> I'm aware (after posting 
> http://llvm.org/bugs/show_bug.cgi?id=12303) that if you build clang 
> with paths tuned for, say, gcc-4.6's libstdc++, then you have to 
> remember, every time you build something with clang++, to always make 
> the linker find gcc-4.6's libstdc++, but as cumbersome as it might 
> seem (if there's some configure hook that avoids the need of always 
> passing "-L<wherever gcc-4.6'libstdc++ lives>" I'd
really be happy to
> use it), it's always worked for me.
>
> Until lately, when I built the latest gcc-4.7 and since then clang++ 
> (rebuilt of course with paths updated for the new compiler) chokes on 
> every cpp file as soon as I start including something like <iostream>
> or <vector> etc..
>
> Is it just a problem with gcc-4.7 libstdc++ headers that for some 
> reason clang++ is not (yet) able to digest, or have I always been 
> doing something not supported on OSX and I've just been lucky that it 
> has been working until now?
>
> Thanks,
> Andrea.
>
>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-- 
Marc J. Driftmeyer
Email :: mjd at reanimality.com <mailto:mjd at reanimality.com>
Web :: http://www.reanimality.com
Cell :: (509) 435-5212
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120412/6ac8e15e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mjd.vcf
Type: text/x-vcard
Size: 317 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120412/6ac8e15e/attachment.vcf>

Marc J. Driftmeyer <mjd <at> reanimality.com> writes:
>     If you check the Clang list (cfe-dev-list) the issue dealing with
>     atomics for gcc-4.7 has been settled. I can verify this on Debian
>     Linux using gcc-4.7 that clang/clang++ builds and no long fails when
>     compiling a simple HelloWorld program. Atomics for c++ are now
>     recognized as __c11_atomic_* and it builds cleanly from what i've
>     tested.
>     I presently don't have a 10.7 box to test against trunk, but those
>     errors are now gone from Linux.
>     The thread to read:
>       http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-April/020686.html
>     - Marc
Oh, 
thank you very much Marc for the reference to the relevant thread.

I'm going to update trunk and give it a try as soon as I 
get back in front of my mac

Andrea.