root: Add --enable-cxx11 when using libc++

[jfcaron3]

The current ROOT can compile (with ACLiC) code with C++11 extensions, but emits a warning unless ROOT was built with --enable-cxx11. It seems that several of the +gcc4X and +clang variants should be able to handle C++11, so could we make those variants use --enable-cxx11 in order to suppress warnings for progressive users? I don't know what else --enable-cxx11 actually does beyond suppress the warnings.

ROOT Talk reference: ​http://root.cern.ch/phpBB3/viewtopic.php?f=3&t=15591

[l1q1d@…]

I'm doing some tests and I'll release the new Portfile soon

(mattia francesco moro)

[cjones051073 (Chris Jones)]

From memory, I had to specifically disable c++11 support for some reason, I think it wasn't compatible with some variants. I forget the details now...

Basically, if enabling it we need to make sure all variants work properly.

cheers Chris

[cjones051073 (Chris Jones)]

I've run some tests myself, and I cannot seem to reproduce the problems I had before. Probably it was based on an older ROOT version, now fixed...

Anyway, I'll attached a trivial patch that just adds a new variant that enables c++11 support. I think we should do it this way, rather than hardcode things either way, to allow users to choose.

In my tests, it works OK. support is only enabled for compilers that support it, and for me (OSX10.8, Xcode 4.6.3) the default system compiler does not seem to support it. gcc 4.7 onwards, and the MacPorts clang compilers do though.

My patch doesn't enable c++11 by default. I think we could, but I would like to see some tests on other systems first (I only have access to OSX 10.8).

cheers Chris

[cjones051073 (Chris Jones)]

Have you had time to test the patch to see if it works for you ?

[ryandesign (Ryan Carsten Schmidt)]

Providing a variant to enable C++11 seems like a bad idea. In comment:ticket:40238:3 our resident C++11 expert Jeremy H.S. said adding this variant would "allow the user to shoot themselves in the foot" so we should not add it.

[jeremyhu (Jeremy Huddleston Sequoia)]

I wouldn't say I'm a C++11 expert. I know a lot about runtimes and the lower level aspects of this problem, but I'm not much of an expert on the higher levels of the C++ language ;)

[jfcaron3]

I would like to revive this ticket and add to the request that the flag not just be for --enable-cxx11, but to make root link against libcxx instead of libgcc. The basic problem is that even if you compile the root port using a modern compiler that supports C++11, the libgcc library doesn't. Try using a list initializer in a compiled ROOT macro and it doesn't compile.

Whatever the ultimate solution is, I would like this line of code:

static const vector<int> v = {1,2,3};

to compile using ACLiC with root fresh-from-macports without special gSystem->SetMakeSharedLib stuff. Language support for C++11 without library support only takes us so far.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jfcaron@…:

I would like to revive this ticket and add to the request that the flag not just be for --enable-cxx11, but to make root link against libcxx instead of libgcc. The basic problem is that even if you compile the root port using a modern compiler that supports C++11, the libgcc library doesn't. Try using a list initializer in a compiled ROOT macro and it doesn't compile.

Whatever the ultimate solution is, I would like this line of code:

static const vector<int> v = {1,2,3};

to compile using ACLiC with root fresh-from-macports without special gSystem->SetMakeSharedLib stuff. Language support for C++11 without library support only takes us so far.

Yes. I suggest that we enable C++11 support based on what the C++ runtime is. If the user is using libc++, we should enable it.

[cjones051073 (Chris Jones)]

Is there a macports way of checking what c++ runtime is being used ? Or is it enough to just enable this for osx 10.9 where the libc++ runtime is now default ?

Chris

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jonesc@…:

Is there a macports way of checking what c++ runtime is being used ? Or is it enough to just enable this for osx 10.9 where the libc++ runtime is now default ?

Chris

On base trunk, you can check configure.cxx_stdlib ... on older base, it's the default for the OS version.

[cjones051073 (Chris Jones)]

Ok thanks. So for the current macports release, we should just enable it by default for osx 10.9, and then when the support in base is released, i can switch to the better test. I'll try and get around to adding this next week.

Cheers chris

[jeremyhu (Jeremy Huddleston Sequoia)]

Not exactly. I'm thinking this:

Index: Portfile
===================================================================
--- Portfile	(revision 113119)
+++ Portfile	(working copy)
@@ -111,6 +111,26 @@
                     --enable-fink \
                     --enable-gdml
 
+platform darwin {
+    set cxx_stdlib {}
+
+    if {[info exists configure.cxx_stdlib] &&
+        ${configure.cxx_stdlib} ne {} &&
+        [string match *clang* ${configure.cxx}]} {
+        set cxx_stdlib ${configure.cxx_stdlib}
+    } elseif {[string match *clang* ${configure.cxx}] &&
+              ${os.major} >= 13} {
+        set cxx_stdlib libc++
+    } else {
+        set cxx_stdlib libstdc++
+    }
+
+    if {${cxx_stdlib} == "libc++"} {
+        configure.args-delete --disable-c++11
+        configure.args-append --enable-c++11
+    }
+}
+
 universal_variant   no
 
 default_variants    +ssl +xml +gsl +minuit2 +tmva +roofit +graphviz +opengl +soversion

[cjones051073 (Chris Jones)]

I've attached a second patch file, with Jeremy's suggestion (thanks). Please could you test ? Builds for me on OSX10.9.

Chris

[jfcaron3]

Replying to jonesc@…:

I've attached a second patch file, with Jeremy's suggestion (thanks). Please could you test ? Builds for me on OSX10.9.

Chris

I'm trying to test it on my 10.7 machine, am I doing this right?

1) I set up a local portfile repository as here: ​https://guide.macports.org/#development.local-repositories

2) I made directories science/root, and in root I put the original portfile for my currently installed root port.

3) I downloaded your root.2.diff and applied it using "patch". Then did "portindex".

4) I reinstalled the root port

This still gave the same error as before when trying to use C++11 initializer lists, but I don't have a good way to check that it was actually using the local portfile, and which options were used to build it. How do I actually select the libcxx dependency?

I also tried manually requesting libcxx, uninstalling root, then reinstalling. The effect is the same.

Jean-François

[jeremyhu (Jeremy Huddleston Sequoia)]

Yeah, that's because it won't be enabled on your configuration. You'd need to install base trunk, choose libc++ as your C++ runtime, and reinstall all of your ports.

I suggest you set this in /opt/local/etc/macports/macports.conf :

buildfromsource         always
delete_la_files    yes
cxx_stdlib libc++

delete_la_files is there because this is a good opportunity for you to do that as well (it would require a full reinstall just like switching the C++ runtime)

Note that Lion's libc++ is a bit older and you may run into issues that have been fixed in Mountain Lion and Mavericks that weren't pulled back into Lion software updates.

[jfcaron3]

Replying to jeremyhu@…:

Yeah, that's because it won't be enabled on your configuration. You'd need to install base trunk, choose libc++ as your C++ runtime, and reinstall all of your ports.

I suggest you set this in /opt/local/etc/macports/macports.conf :

buildfromsource         always
delete_la_files    yes
cxx_stdlib libc++

delete_la_files is there because this is a good opportunity for you to do that as well (it would require a full reinstall just like switching the C++ runtime)

Note that Lion's libc++ is a bit older and you may run into issues that have been fixed in Mountain Lion and Mavericks that weren't pulled back into Lion software updates.

Ah, that's a bit more drastic than I would like just to test a new portfile configuration. I thought I just needed to have the port libcxx installed. How likely is installing base trunk & switching C++ runtimes to break a bunch of stuff? I'm willing to try it, but I don't want to be unable to do real work come Monday morning because of broken ports...

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jfcaron@…:

Replying to jeremyhu@…:

Yeah, that's because it won't be enabled on your configuration. You'd need to install base trunk, choose libc++ as your C++ runtime, and reinstall all of your ports.

I suggest you set this in /opt/local/etc/macports/macports.conf :

buildfromsource         always
delete_la_files    yes
cxx_stdlib libc++

delete_la_files is there because this is a good opportunity for you to do that as well (it would require a full reinstall just like switching the C++ runtime)

Note that Lion's libc++ is a bit older and you may run into issues that have been fixed in Mountain Lion and Mavericks that weren't pulled back into Lion software updates.

Ah, that's a bit more drastic than I would like just to test a new portfile configuration. I thought I just needed to have the port libcxx installed. How likely is installing base trunk & switching C++ runtimes to break a bunch of stuff? I'm willing to try it, but I don't want to be unable to do real work come Monday morning because of broken ports...

I'm doing that on all but one of my Mountain Lion machines.

I was doing that on my Lion machine when I still had one.

I didn't encounter any issues which I didn't also encounter with Mavericks, and most of those are fixed or getting fixed.

[jfcaron3]

Replying to jeremyhu@…:

Replying to jfcaron@…:

Replying to jeremyhu@…:

Yeah, that's because it won't be enabled on your configuration. You'd need to install base trunk, choose libc++ as your C++ runtime, and reinstall all of your ports.

I suggest you set this in /opt/local/etc/macports/macports.conf :

buildfromsource         always
delete_la_files    yes
cxx_stdlib libc++

delete_la_files is there because this is a good opportunity for you to do that as well (it would require a full reinstall just like switching the C++ runtime)

Note that Lion's libc++ is a bit older and you may run into issues that have been fixed in Mountain Lion and Mavericks that weren't pulled back into Lion software updates.

Ah, that's a bit more drastic than I would like just to test a new portfile configuration. I thought I just needed to have the port libcxx installed. How likely is installing base trunk & switching C++ runtimes to break a bunch of stuff? I'm willing to try it, but I don't want to be unable to do real work come Monday morning because of broken ports...

I'm doing that on all but one of my Mountain Lion machines.

I was doing that on my Lion machine when I still had one.

I didn't encounter any issues which I didn't also encounter with Mavericks, and most of those are fixed or getting fixed.

I think I'm going to need more specific instructions before I can test this on my machine. I've followed the instructions from here: ​http://guide.macports.org/#installing.macports.subversion and here: wiki:Migration (By the way, did I need to actually delete the old MacPorts from the package at any point? I just did sudo make install "on top" of whatever was there before.) After "sudo make install" is when I added those three lines to macports.conf, is that right?

After doing that, I did selfupdate and tried to upgrade my outdated ports, but now cctools fails to build. I guess I need to uninstall & reinstall all my ports, but I'll wait for confirmation before starting that long process.

Jean-François

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jfcaron@…:

I think I'm going to need more specific instructions before I can test this on my machine. I've followed the instructions from here: ​http://guide.macports.org/#installing.macports.subversion and here: ​https://trac.macports.org/wiki/Migration (By the way, did I need to actually delete the old MacPorts from the package at any point? I just did sudo make install "on top" of whatever was there before.) After "sudo make install" is when I added those three lines to macports.conf, is that right?

After doing that, I did selfupdate and tried to upgrade my outdated ports, but now cctools fails to build. I guess I need to uninstall & reinstall all my ports, but I'll wait for confirmation before starting that long process.

Jean-François

You should try asking for help with things like this on the macports-users mailing list.

sudo make install "over" the package installed bits is fine.

You should do 'sudo port -v -f uninstall installed' and start from scratch with the updated config.

[cjones051073 (Chris Jones)]

Did you manage to test this ? ROOT 5.34.12 is likely to be released soon (to fix amongst over things some residual OSX 10.9 issues) and I would like to include this patch in that update, at the same time.

If you didn't managed, if you could upload a simple test case I can just run, to this ticket, I can try it myself on my OSX10.9 machine.

Chris

[jeremyhu (Jeremy Huddleston Sequoia)]

Pushed in r113530 as it's worked well enough for me and there haven't been any negative reports.

[cjones051073 (Chris Jones)]

thanks !

[jfcaron3]

Replying to jonesc@…:

Did you manage to test this ? ROOT 5.34.12 is likely to be released soon (to fix amongst over things some residual OSX 10.9 issues) and I would like to include this patch in that update, at the same time.

If you didn't managed, if you could upload a simple test case I can just run, to this ticket, I can try it myself on my OSX10.9 machine.

Chris

I did try to test it but ended up breaking various other ports in the process. Not knowing whether I was not testing properly or whether it was a problem with the patch, and needing to get work done on the next weekday, I reinstalled MacPorts from the package and reinstalled my ports. A simple test would be to create a file macro.C with the following contents:

#include <vector>

void macro(void)
{ vector<int> v = {4,5,6}; }

Then at the command line, do: root -l macro.C+

Jean-François

[cjones051073 (Chris Jones)]

Hi,

You test case seems to work OK for me,

MacBookPro ~ > root -l macro.C+
root [0] 
Processing macro.C+...
Info in <TUnixSystem::ACLiC>: creating shared library /Users/chris/./macro_C.so
root [1] macro()
root [2] 

So it seems all is OK ;)

Chris

[jfcaron3]

Replying to jonesc@…:

Hi,

You test case seems to work OK for me,

MacBookPro ~ > root -l macro.C+
root [0] 
Processing macro.C+...
Info in <TUnixSystem::ACLiC>: creating shared library /Users/chris/./macro_C.so
root [1] macro()
root [2] 

So it seems all is OK ;)

Chris

As far as I understand it, this patch will make root use --enable-c++11 and libc++ if either: clang is the system compiler or one of the clang variants was chosen for the port. Is that right? I'm still on OSX 10.7.5 (not planning to upgrade anytime) and wish to use C++11 library and language features in ROOT, I'm flexible about which runtime and which compiler I use to accomplish this.

[cjones051073 (Chris Jones)]

Not quite. It enables it either on OSX 10.9 by default (as libc++ is the default there) or if you are running the current trunk macPorts base, and have followed the instructions in comment #19 to use libc++. Either way, you have to use libc++ and not libstdc++ in order to get c++11 support enabled. If you are not willing to move to OSX 10.9, you need to do the later.

[jfcaron3]

Now that this patch is in the regular root port (as of r113530), do I still need to be running "trunk base" in order to make use of this on 10.7.5?

Is it enough to just add the libc++ line in my macports.conf and reinstall my ports? Are the buildfromsource and delete_la_files lines required, or are they doing something else? I'd rather not have to build everything from source if possible.

[cjones051073 (Chris Jones)]

If you are not running OSX 10.9 you still need to be using the trunk of base.

[jeremyhu (Jeremy Huddleston Sequoia)]

buildfromsource is required because you are using a non-default C++ runtime.

delete_la_files is reccomended because you're rebuilding everything anyways.