Using -std=c++11 with the macports gcc-4.7 compiler

[Jeremy Huddleston Sequoia]

On Jan 17, 2013, at 11:24, Clemens Lang <cal at macports.org> wrote:

> On Wed, Jan 16, 2013 at 08:06:15PM -0800, Jeremy Huddleston Sequoia wrote:
>> We may need to figure out a way to deal with this ABI compatibility
>> issue in base … is there currently a way to query what
>> configure.compiler was for another installed port?
> 
> Are you saying there is no way to have clang and gcc (from both Xcode
> and MacPorts) generate ABI-compatible binaries (compatible with each
> other, but also with the host's ABI)?

Not at all.

> If that is true getting this right
> would be a major effort. Wouldn't that also mean we had to avoid linking
> against any OS-provided (C++?) library at any cost?

No.  I'm saying that if a library uses libc++ and exports C++ objects, then its client needs to use libc++ as well.  Similarly, if a library uses libstdc++ and exports C++ objects, then its client needs to use libstdc++ as well.

> On Wed, Jan 16, 2013 at 11:44:17PM -0600, Ryan Schmidt wrote:
>> There's a lot of information available at install time that's not
>> recorded anywhere that might be useful later. Compiler used, Xcode
>> version, OS X version and build number, number of CPUs, amount of
>> memory, number of build jobs... We could record information like this,
>> and provide a command to easily retrieve all the information, and ask
>> users to include it with bug reports. But it would be a bit of work to
>> implement, for a hypothetical future benefit. :/
> 
> The hypothetical future benefit is what makes me think whether
> implementing this is time well spent. Most of that information can also
> be generated on the fly (e.g., using a port report-bug command?) instead
> of storing this in the package.

No, because the machine used to build a project may not be the one installing it.

> There's other information we might want to record, though: E.g. the list
> of packages (and their versions) installed when a package was built
> might be useful.

True, but that may be more data than we're willing to store.

> On Wed, Jan 16, 2013 at 10:42:04PM -0800, Jeremy Huddleston Sequoia wrote:
>> This sounds like a good GSOC project.
> 
> I think we have other areas in base where time could be spent with more
> helpful outcome (e.g., dependency management and computation,
> pre-computing all actions instead of doing them one-by-one, designing a
> proper interface between port1.0 and macports1.0 (like there apparently
> used to be))).

Yes, there is plenty of room for improvement.

--Jeremy