Pure doesn't build with clang/libc++

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Configure pure with "CXX=clang CXXFLAGS=-stdlib=libc++ 
LDFLAGS=-stdlib=libc++"
2. Build pure and compilation errors happen in runtime.cc

What is the expected output? What do you see instead?
Pure should be built without errors.

What version of the product are you using? On what operating system?
Mac OS X 10.8.2 and FreeBSD 9-STABLE

Please provide any additional information below.
A patch enclosed, but few tests(prelude, 025, 041, 042, and 044) failed with 
some format difference like "#<pointer 0>" and "#<pointer 0x0>", haven't dug 
deeper.

Original issue reported on code.google.com by windoze....@gmail.com on 8 Feb 2013 at 1:15

Attachments:

• runtime.patch

[GoogleCodeExporter]

What LLVM/clang/libc++ version is that? Also, I'd really like to understand 
what the exact issues with using libc++ are. Could you please attach your 
buildlogs showing the compilation errors you get?

Original comment by aggraef@gmail.com on 11 Feb 2013 at 11:46

• Changed state: Accepted

[GoogleCodeExporter]

Pure defines some symbols conflict with C++11 standard, i.e. "is_scalar" in 
interpreter.cc and "is_void" and "hash" in runtime.cc.
Also pure uses "std::complex" in a wrong way, by standard, std::complex::real() 
and imag() return value type instead of reference of internal member, thus 
cannot be converted to pointers.
Compiled on Mac OS X 10.8.2, clang version is "Apple LLVM version 4.2 
(clang-425.0.24) (based on LLVM 3.2svn)", libc++ version ("_LIBCPP_VERSION" 
defined in "/usr/lib/c++/v1/__config") is 1101.
Error log is enclosed.

Original comment by windoze....@gmail.com on 11 Feb 2013 at 3:10

Attachments:

• error-log.txt

[GoogleCodeExporter]

Thanks for posting the error logs. You're right about std::complex, that must 
have changed somewhere along the way. I'll have to fix that so that it works 
with both C++11 and older versions of the C++ library.

About is_scalar(), is_void() and hash(): I also have these in my C++11 headers, 
so I will try to reproduce these errors with -std=c++11. But I don't really see 
how the std namespace could possibly come into scope there?

Original comment by aggraef@gmail.com on 11 Feb 2013 at 4:27

[GoogleCodeExporter]

I really have no idea why you haven't encountered any errors, "is_scalar" is 
defined as a struct template in type_traits(which is a standard header included 
indirectly almost anywhere); then redefined in interpreter.cc as a function, 
which is obviously a name collision; so do "is_void" and "hash".

"using namespace std;" in header files is not a good practice anyway.

A quick grep shows following header files have the issue:
expr.hh:38:using namespace std;
interpreter.hh:171:using namespace std;
matcher.hh:30:using namespace std;
symtable.hh:30:using namespace std;

Original comment by windoze....@gmail.com on 11 Feb 2013 at 4:55

[GoogleCodeExporter]

> "using namespace std;" in header files is not a good practice anyway.

You're right, I forgot to check the header files. Facepalm.

The reason I never saw these errors (and noone else reported them so far) is 
that with the standard setup Pure gets compiled with the old C++ library, which 
works with either gcc or clang. Adding -std=c++11 I can reproduce the errors 
that you see.

Original comment by aggraef@gmail.com on 11 Feb 2013 at 9:44

• Changed state: Started
• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

This should be fixed in rev. 99b1018 now. I could only check with -std=c++0x, 
but that works ok with both gcc and clang, so it will hopefully work with C++11 
as well. Could you please give it another whirl and report back? Thanks.

Please note that since you've reported the bug, I moved Pure over to Bitbucket, 
so you now have to get the latest repository sources at 
https://bitbucket.org/purelang/pure-lang.

Original comment by aggraef@gmail.com on 13 Feb 2013 at 6:07

• Changed state: Fixed

[GoogleCodeExporter]

Tested build pure core package on following platforms:
1. Ubuntu Linux 12.04.2 LTS, GCC 4.6.3-1ubuntu5, LLVM-3.1. CXX set to "c++ 
-std=c++0x". Pure built without error and all tests passed.
2. FreeBSD 9-STABLE, Clang/LLVM 3.2, CXX set to "clang++ -std=c++11 
-stdlib=libc++", Pure built without error but test cases prelude, 025, 041, 
042, and 044 failed.
3. Mac OS X, Xcode 4.6 (Apple LLVM version 4.2, clang-425.0.24, based on LLVM 
3.2svn), CXX set to "clang++ -std=c++11 -stdlib=libc++", Pure built without 
error but test cases prelude, 025, 041, 042, and 044 failed.
Seems libc++ have different output format for pointers from libstdc++("0x0" and 
"0"). No idea if it's a big issue but my simple test scripts run without 
problem.

One more thing, configure script doesn't take CXXFLAGS, I've to set CXX to 
something like "c++ -std=c++0x".

Original comment by windoze....@gmail.com on 14 Feb 2013 at 8:02

Attachments:

• test.tar.gz

[GoogleCodeExporter]

Great, thanks for the report. I'll see what I can do about the pointer 
formatting issue; a little __show__ rule for the NULL pointer should take care 
of that.

The attached test.tar.gz has 0 bytes, can you please try uploading again? 
Thanks.

About configure and CXXFLAGS: This works for me, here's the command line that I 
used in bash to test with clang and C++0x on Ubuntu 12.04.2 (autoconf version 
2.68):

CC=clang CXX=clang++ CXXFLAGS="-g -O2 -std=c++0x -Wall" ./configure

Note that all the variables need to be specified in the environment, not as 
parameters of the configure command. At least that's the way it works with 
autoconf 2.68. Also note that if you use any of the --enable-release, 
--enable-debug options with configure, it will override the CXXFLAGS. Maybe 
that was the problem that you had?

Original comment by aggraef@gmail.com on 14 Feb 2013 at 12:03

[GoogleCodeExporter]

> Also note that if you use any of the --enable-release, --enable-debug options 
with configure, it will override the CXXFLAGS.
That's the case! I'm using --enable-release along with a lot of other options 
in order to build with MacPorts.
CC=cc CXX="c++ -stdlib=libc++" CXXFLAGS="-stdlib=libc++" ../configure 
--enable-release --with-libgmp-prefix=/opt/local 
--with-libmpfr-prefix==/opt/local --with-libiconv-prefix=/opt/local

Re-attach the test log.

Original comment by windoze....@gmail.com on 14 Feb 2013 at 1:13

Attachments:

• test.tar.gz

[GoogleCodeExporter]

The pointer formatting issue should be fixed as well (rev. 47b4719). It should 
always print 0x0 for the NULL pointer now. Does 'make check' pass for you now?

Original comment by aggraef@gmail.com on 14 Feb 2013 at 2:06

[GoogleCodeExporter]

This is explained here: 
http://purelang.bitbucket.org/docs/install.html#predefined-build-types. 
--enable-release and --enable-debug override both CFLAGS and CXXFLAGS (CPPFLAGS 
will be preserved, however). I agree that this is a bit unfortunate if you want 
the --enable-release setting as a basis but also need to specify your own 
CFLAGS/CXXFLAGS. I will have to think about how to handle this in a better way; 
if you already have any idea how to modify configure.ac then please let me know.

Original comment by aggraef@gmail.com on 14 Feb 2013 at 2:31

[GoogleCodeExporter]

Yes, all tests passed on FreeBSD and OSX with clang/libc++ now.
A suggestion is to move away from autotools as they've never been hassleless on 
any systems except few popular Linux distributions. It took me hours to make 
everything work on FreeBSD.

Original comment by windoze....@gmail.com on 14 Feb 2013 at 4:02

[GoogleCodeExporter]

I've fixed the issue with CXXFLAGS being completely overridden by the build 
types in rev. dc771e9, so combinations of --enable-release and CXXFLAGS should 
work now.

Yeah, the autotools are a nuisance and they're getting a bit old, but I found 
that almost all other cross-platform build systems are even worse. ;-) The only 
one I really like is waf, but even that makes some things pretty hard. And in 
any case, porting Pure over to waf will be a considerable amount of work. I 
have it on my TODO list, but don't hold your breath for it yet.

Ok, since everything seems to be in good working order now, I'm ready to do a 
release (0.57). If I don't run into further obstacles, it should show up on 
Bitbucket and Launchpad in the next few hours.

Thanks for reporting!

Albert

Original comment by aggraef@gmail.com on 14 Feb 2013 at 4:40

[GoogleCodeExporter]

Original comment by aggraef@gmail.com on 14 Feb 2013 at 4:42

• Changed state: Verified