Re: GCC driver-driver [was: Re: standard way to require c++11?]

[Landon J Fuller]

On Apr 22, 2015, at 12:23 PM, Mihai Moldovan  wrote:
> 
>> Ah, clever.  I see what you mean, but yeah, that would require more 
>> extensive use of muniversal which is more of a hack in my mind than a proper 
>> solution. =/
> 
> You're right. The proper solution would be to add the old driver-driver back 
> to FSF GCC and get it upstreamed, instead of relying even more on universal.
[snip]
> 
> Does anyone here have:
>  - a clear understanding of the legal matter?
>  - experience with writing robust code and maybe even a little bit of 
> knowledge of GCC's internals (likely helpful)?
>  - enough time to backport/implement this?
>  - confidence a backport will be accepted by the GCC project?
> 
> It's not required to meet all points. Even one would be good enough. This can 
> be a team effort if needed. The GCC Strike Force![0]
> 
> On OS X, having driver-driver again with -arch support would certainly be a 
> very welcome improvement to FSF GCC.[1]


Sorry, I just now saw this e-mail.

I wrote an independent MIT-licensed implementation of the ‘driver-driver’ for 
FatELF:

https://github.com/landonf/haiku-buildtools/blob/fatelf/fatelf/utils/fatelf-gcc.c

Some minor work would be required to extricate it from the fatelf-utils code so 
that it can stand alone, and to replace the ‘fatelf_glue_cmd’ with lipo(1), but 
all the difficult bits related to GCC argument handling, etc, are done.

-landonf___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[Mojca Miklavec]

On Fri, May 1, 2015 at 3:43 AM, Ryan Schmidt wrote:

 And what should the default value be? C++11? C11?

 I think we should probably move toward portgroups where the default is not to 
 do anything, and some directive has to be used to activate the portgroup's 
 behavior.

Indeed. I often wish I was able to use the Python PortGroup to be able
to recall some complex variables from the PortGroup for C++ projects
with some Python bindings. But the PortGroup itself changes so much
that there's no way to use it and also no way to recover/revert
back to the default behaviour. So we end up hardcoding Python
variables in regular ports, while that could/should be handled by the
PortGroup.

(The wxWidgets PortGroup doesn't do anything at by itself all for
example, exactly for the reasons you mention: it might only be used in
variants etc.)

Including the PortGroup first and setting the required standard like
C++11 or C++14 at some later point sounds reasonable to me.

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[Mihai Moldovan]

On 30.04.2015 03:56 AM, Ryan Schmidt wrote:
 On Apr 29, 2015, at 1:37 AM, Ryan Schmidt wrote:
 That was going to be my suggestion, to avoid a proliferation of portgroups 
 that all do something similar.
 
 For example, right now I'm dealing with the fact that gpsd 3.14 requires C11 
 (not C++11), and would like to be able to indicate that so that pre-C11 
 compilers get blacklisted.

Hmm, a valid request. But what is an appropriate name for such a PortGroup?
standards?

And what should the default value be? C++11? C11?



Mihai



signature.asc
Description: OpenPGP digital signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[Ryan Schmidt]

On Apr 30, 2015, at 6:46 AM, Mihai Moldovan wrote:

 On 30.04.2015 03:56 AM, Ryan Schmidt wrote:
 On Apr 29, 2015, at 1:37 AM, Ryan Schmidt wrote:
 That was going to be my suggestion, to avoid a proliferation of portgroups 
 that all do something similar.
 
 For example, right now I'm dealing with the fact that gpsd 3.14 requires C11 
 (not C++11), and would like to be able to indicate that so that pre-C11 
 compilers get blacklisted.

This was solved another way, and I haven't had this problem before, but it 
seems like it could come up again.


 Hmm, a valid request. But what is an appropriate name for such a PortGroup?
 standards?

Yeah I'm not sure.


 And what should the default value be? C++11? C11?

I think we should probably move toward portgroups where the default is not to 
do anything, and some directive has to be used to activate the portgroup's 
behavior.

For example the github portgroup does nothing unless github.setup is invoked, 
though we should also move away from .setup procedures, like the php and python 
portgroups already have.

The app portgroup is an anti-example: just including the portgroup makes it try 
to add an app bundle, because the default for app.create is yes; we should 
change it to no so that including the portgroup does nothing, and the 
behavior has to be activated by setting app.create yes in the portfile. This 
becomes more important as portgroups start including each other, or for ports 
that want to use a portgroup's functionality only in a subport or variant.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[Ryan Schmidt]

On Apr 29, 2015, at 12:12 AM, Mihai Moldovan wrote:

 Do we want a general cxx PortGroup with options for C++11, C++14,
 C++... or a new PortGroup for every standard? Probably the former?

That was going to be my suggestion, to avoid a proliferation of portgroups that 
all do something similar.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[Mihai Moldovan]

On 14.04.2015 07:44 AM, Mojca Miklavec wrote:
 Could something like that be added to the compiler_blacklist
 PortGroup? I believe that pure C++11 projects need consistent handling
 and it would be very handy to allow a keyword like compiler.c++11 or
 compiler.something c++11 to replace all of the logic above inside
 a port.

I've now added a new PortGroup called cxx11, which does the blacklisting and
stdlib checking.

Extending compiler_blacklist_versions looked too complicated, as its logic is
contained in multiple procs and one option_proc.

Also, using PortGroup cxx11 1.0 vs. compiler.c++11/compiler.something
c++11 is practically the same thing.

Feel free to improve it and hit me, if I messed something up.



Mihai




signature.asc
Description: OpenPGP digital signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[Ryan Schmidt]

On Apr 28, 2015, at 11:39 PM, Mihai Moldovan wrote:

 On 14.04.2015 07:44 AM, Mojca Miklavec wrote:
 Could something like that be added to the compiler_blacklist
 PortGroup? I believe that pure C++11 projects need consistent handling
 and it would be very handy to allow a keyword like compiler.c++11 or
 compiler.something c++11 to replace all of the logic above inside
 a port.
 
 I've now added a new PortGroup called cxx11, which does the blacklisting and
 stdlib checking.

Thanks. That was my first thought as well... but what happens next when ports 
want to require C++14, or some other future standard? Should it be able to 
accommodate that as well?


 Extending compiler_blacklist_versions looked too complicated, as its logic is
 contained in multiple procs and one option_proc.

Right, I would not add this to that portgroup; it is a different concept.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[Mihai Moldovan]

On 29.04.2015 06:55 AM, Ryan Schmidt wrote:
 
 On Apr 28, 2015, at 11:39 PM, Mihai Moldovan wrote:
 
 On 14.04.2015 07:44 AM, Mojca Miklavec wrote:
 Could something like that be added to the compiler_blacklist PortGroup? I
 believe that pure C++11 projects need consistent handling and it would be
 very handy to allow a keyword like compiler.c++11 or 
 compiler.something c++11 to replace all of the logic above inside a
 port.
 
 I've now added a new PortGroup called cxx11, which does the blacklisting
 and stdlib checking.
 
 Thanks. That was my first thought as well... but what happens next when ports
 want to require C++14, or some other future standard? Should it be able to
 accommodate that as well?

As far as I can tell, C++14 should be supported by libc++. It'll require clang
= 3.4, though. I'm not sure what makes more sense. Do we want a general cxx
PortGroup with options for C++11, C++14, C++... or a new PortGroup for every
standard? Probably the former?

A future standard like C++1z... meh. grep for C++1z in this thread and
you'll understand why that's inducing quite some headache.

For a future standard, the pre-installed libc++ probably won't cut it, so we're
running into big trouble. Best not to think about it for now...


 Extending compiler_blacklist_versions looked too complicated, as its logic
 is contained in multiple procs and one option_proc.
 
 Right, I would not add this to that portgroup; it is a different concept.

Well, dunno. It's actually *using* compiler_blacklist_versions, so it's at least
somewhat related. This said, yes, what cxx11 does is using the
compiler_blacklist_versions API/the functionality, it doesn't care about
implementation details, so it is decoupled from the PortGroup.



Mihai



signature.asc
Description: OpenPGP digital signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[Lawrence Velázquez]

On Apr 21, 2015, at 5:14 AM, Jeremy Huddleston Sequoia jerem...@apple.com 
wrote:

 On Apr 20, 2015, at 23:51, Mihai Moldovan io...@macports.org wrote:
 
 Yes, that would be adding a new dependency on libgcc and FSF GCC for all C++ 
 ports. But so does using libc++ on 10.6. Implicitly at least. Fortunately 
 that doesn't add dependencies on 10.7 and higher.
 
 For specific ports, yes. In general, muniversal might take of that. But it 
 doesn't make a lot of sense to change our ports base to muniversal, if we 
 can salvage the current state by using clang. Which implies libc++. Gotcha.
 
 What does muniversal have to do with anything?

I think Mihai is thinking about using the portgroup's automatic lipo(1)-ing as 
a hacky substitute for a proper GCC driver-driver.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[Jeremy Huddleston Sequoia]

 On Apr 22, 2015, at 10:30, Lawrence Velázquez lar...@macports.org wrote:
 
 On Apr 21, 2015, at 5:14 AM, Jeremy Huddleston Sequoia jerem...@apple.com 
 wrote:
 
 On Apr 20, 2015, at 23:51, Mihai Moldovan io...@macports.org wrote:
 
 Yes, that would be adding a new dependency on libgcc and FSF GCC for all 
 C++ ports. But so does using libc++ on 10.6. Implicitly at least. 
 Fortunately that doesn't add dependencies on 10.7 and higher.
 
 For specific ports, yes. In general, muniversal might take of that. But it 
 doesn't make a lot of sense to change our ports base to muniversal, if we 
 can salvage the current state by using clang. Which implies libc++. Gotcha.
 
 What does muniversal have to do with anything?
 
 I think Mihai is thinking about using the portgroup's automatic lipo(1)-ing 
 as a hacky substitute for a proper GCC driver-driver.

Ah, clever.  I see what you mean, but yeah, that would require more extensive 
use of muniversal which is more of a hack in my mind than a proper solution. =/

 
 vq
 ___
 macports-dev mailing list
 macports-dev@lists.macosforge.org
 https://lists.macosforge.org/mailman/listinfo/macports-dev



smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

GCC driver-driver [was: Re: standard way to require c++11?]

[Mihai Moldovan]

On 22.04.2015 07:39 PM, Jeremy Huddleston Sequoia wrote: 
 On Apr 22, 2015, at 10:30, Lawrence Velázquez lar...@macports.org wrote:

 On Apr 21, 2015, at 5:14 AM, Jeremy Huddleston Sequoia jerem...@apple.com 
 wrote:

 On Apr 20, 2015, at 23:51, Mihai Moldovan io...@macports.org wrote:
[...]
 For specific ports, yes. In general, muniversal might take of that. But it 
 doesn't make a lot of sense to change our ports base to muniversal, if we 
 can salvage the current state by using clang. Which implies libc++. Gotcha.

 What does muniversal have to do with anything?

 I think Mihai is thinking about using the portgroup's automatic lipo(1)-ing 
 as a hacky substitute for a proper GCC driver-driver.

Yep, thanks Larry.


 Ah, clever.  I see what you mean, but yeah, that would require more extensive 
 use of muniversal which is more of a hack in my mind than a proper solution. 
 =/

You're right. The proper solution would be to add the old driver-driver back to 
FSF GCC and get it upstreamed, instead of relying even more on muniversal.

Personally, I do not wish to do so, for multiple reasons.

First, a compiler is a somewhat delicate matter and I do not think I've got 
experience to get it right. I don't want to completely break (or break in 
subtle ways) FSF GCC on OS X.

Next, there's this copyright-license issue. While only taking driver-driver 
from GCC 4.2 and backporting it to at least the newest GCC 5 version might 
technically not be too difficult (although it probably requires 
re-implementation in C++?), Apple would still be the original copyright holder 
on that code and as such can decide under what license to release it. Given 
they don't want to do that on a GPL-3 basis, only a complete rewrite (for 
whatever that means *exactly*) would give a contributor the right to claim 
copyright and determine the license.

Even in a complete rewrite case, I'd be concerned with legal problems because 
the general concept of a GCC driver-driver was their idea. Given that we'd want 
the new driver-driver to behave like the 4.2 one, there inadvertently will be 
similarities.

On the other hand, maybe Apple doesn't care and would indeed be happy to see 
GCC a little bit better supported on their platform. This is pure speculation.

Does anyone here have:
  - a clear understanding of the legal matter?
  - experience with writing robust code and maybe even a little bit of 
knowledge of GCC's internals (likely helpful)?
  - enough time to backport/implement this?
  - confidence a backport will be accepted by the GCC project?

It's not required to meet all points. Even one would be good enough. This can 
be a team effort if needed. The GCC Strike Force![0]

On OS X, having driver-driver again with -arch support would certainly be a 
very welcome improvement to FSF GCC.[1]



Mihai

[0] joke on https://wiki.debian.org/XStrikeForce (which itself it not a joke 
but a great thing for Debian.)
[1] This would only be useful for MacPorts on recent OS X releases if 
-stdlib=libc++ would make GCC not link to its own libstdc++ at all. I don't 
know if that's the case.



signature.asc
Description: OpenPGP digital signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GCC driver-driver [was: Re: standard way to require c++11?]

[Ryan Schmidt]

On Apr 22, 2015, at 1:45 PM, Mihai Moldovan wrote:

 On 22.04.2015 08:41 PM, Ryan Schmidt wrote:
 
 On Apr 22, 2015, at 1:23 PM, Mihai Moldovan wrote:
 
 You're right. The proper solution would be to add the old driver-driver 
 back to FSF GCC and get it upstreamed, instead of relying even more on 
 muniversal.
 
 Personally, I do not wish to do so, for multiple reasons.
 
 Too bad Apple didn't contribute the code back to FSF. Or maybe they did and 
 they didn't accept it for some reason? I don't know. But this is the kind of 
 thing I hate about forking projects.
 
 FSF GCC is licensed as GPLv3. Apple does explicitly not allow usage of its 
 code under GPLv3 for some reason I have forgotten, but only GPLv2.
 
 There might have been other (technical) reasons for rejecting the changes 
 Apple did to GCC, but AFAIK that was the biggest disagreement.

GCC wasn't GPL 3 when Apple developed the compiler driver.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GCC driver-driver [was: Re: standard way to require c++11?]

[Clemens Lang]

Hi,

- On 22 Apr, 2015, at 20:23, Mihai Moldovan io...@macports.org wrote:

 First, a compiler is a somewhat delicate matter and I do not think I've got
 experience to get it right. I don't want to completely break (or break in
 subtle ways) FSF GCC on OS X.

Feel free to ask me if you stumble across problems. I've done some compiler 
stuff
in the past (even though not in C++ and not for GCC, but the general concepts 
are
the same everywhere).


 Even in a complete rewrite case, I'd be concerned with legal problems 
 because
 the general concept of a GCC driver-driver was their idea. Given that we'd 
 want
 the new driver-driver to behave like the 4.2 one, there inadvertently will be
 similarities.

Unless there is a patent filed for the concept (which I doubt, but I didn't 
check)
there is no issue. There's no copyright on ideas, but you're right that you 
cannot
just copy their code. I don't think Apple would object to better GCC support for
their platform, though, so they may actually welcome somebody doing it (even
though they'd probably not state it publicly, or anywhere, really).

That being said, IANAL and you should take what I said with the obvious grain of
salt.

 Does anyone here have:
  - a clear understanding of the legal matter?

I'd say if have that, even though I'm not a lawyer.

  - experience with writing robust code and maybe even a little bit of 
 knowledge
  of GCC's internals (likely helpful)?

Not enough knowledge of GCC internals to be helpful here, sorry.

  - enough time to backport/implement this?

Definitely not.

  - confidence a backport will be accepted by the GCC project?

Somewhat, unless RMS shows up and sees Apple attacking his freedom. That being
said, I'd be surprised if Apple didn't try to upstream the change back in the 
days
(heck, they even tried pushing LLVM into GCC under GPL, but the GCC people
wouldn't have it).


 [1] This would only be useful for MacPorts on recent OS X releases if
 -stdlib=libc++ would make GCC not link to its own libstdc++ at all. I don't
 know if that's the case.

Are you aware of http://stackoverflow.com/questions/8208/using-g-with-libc?
I haven't tried it in a while, but when I last did it was actually pretty easy
to make GCC compile against libc++.

-- 
Clemens Lang
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GCC driver-driver [was: Re: standard way to require c++11?]

[Mihai Moldovan]

On 22.04.2015 08:41 PM, Ryan Schmidt wrote:
 
 On Apr 22, 2015, at 1:23 PM, Mihai Moldovan wrote:

 You're right. The proper solution would be to add the old driver-driver back 
 to FSF GCC and get it upstreamed, instead of relying even more on muniversal.

 Personally, I do not wish to do so, for multiple reasons.
 
 Too bad Apple didn't contribute the code back to FSF. Or maybe they did and 
 they didn't accept it for some reason? I don't know. But this is the kind of 
 thing I hate about forking projects.

FSF GCC is licensed as GPLv3. Apple does explicitly not allow usage of its code 
under GPLv3 for some reason I have forgotten, but only GPLv2.

There might have been other (technical) reasons for rejecting the changes Apple 
did to GCC, but AFAIK that was the biggest disagreement.



Mihai




signature.asc
Description: OpenPGP digital signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GCC driver-driver [was: Re: standard way to require c++11?]

[Ryan Schmidt]

On Apr 22, 2015, at 1:23 PM, Mihai Moldovan wrote:
 
 You're right. The proper solution would be to add the old driver-driver back 
 to FSF GCC and get it upstreamed, instead of relying even more on muniversal.
 
 Personally, I do not wish to do so, for multiple reasons.

Too bad Apple didn't contribute the code back to FSF. Or maybe they did and 
they didn't accept it for some reason? I don't know. But this is the kind of 
thing I hate about forking projects.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GCC driver-driver [was: Re: standard way to require c++11?]

[Mihai Moldovan]

On 22.04.2015 08:47 PM, Ryan Schmidt wrote:
 On Apr 22, 2015, at 1:45 PM, Mihai Moldovan wrote:
 On 22.04.2015 08:41 PM, Ryan Schmidt wrote:
 Too bad Apple didn't contribute the code back to FSF. Or maybe they did and 
 they didn't accept it for some reason? I don't know. But this is the kind 
 of thing I hate about forking projects.

 FSF GCC is licensed as GPLv3. Apple does explicitly not allow usage of its 
 code under GPLv3 for some reason I have forgotten, but only GPLv2.

 There might have been other (technical) reasons for rejecting the changes 
 Apple did to GCC, but AFAIK that was the biggest disagreement.
 
 GCC wasn't GPL 3 when Apple developed the compiler driver.

The best summary I could come up with: 
http://www.phoronix.com/scan.php?page=news_itempx=MTU4MzE

Looks like Apple did try to push LLVM into GCC, but it didn't work out. 
Ironically, one of the reasons was the code written in C++, to which GCC 
upstream switched themselves recently. There seem to also have been licensing 
problems of another kind.

This doesn't explain why subfeatures like driver-driver weren't upstreamed, 
though. As far as I've seen that one time I actually read driver-driver's 
source code, it does not depend upon LLVM. May have been an all or nothing 
deal, though. (Besides, I can understand getting frustrated.)



Mihai



signature.asc
Description: OpenPGP digital signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GCC driver-driver [was: Re: standard way to require c++11?]

[Jeremy Huddleston Sequoia]

 On Apr 22, 2015, at 11:23, Mihai Moldovan io...@macports.org wrote:
 
 On 22.04.2015 07:39 PM, Jeremy Huddleston Sequoia wrote: 
 On Apr 22, 2015, at 10:30, Lawrence Velázquez lar...@macports.org wrote:
 
 On Apr 21, 2015, at 5:14 AM, Jeremy Huddleston Sequoia jerem...@apple.com 
 wrote:
 
 On Apr 20, 2015, at 23:51, Mihai Moldovan io...@macports.org wrote:
 [...]
 For specific ports, yes. In general, muniversal might take of that. But 
 it doesn't make a lot of sense to change our ports base to muniversal, if 
 we can salvage the current state by using clang. Which implies libc++. 
 Gotcha.
 
 What does muniversal have to do with anything?
 
 I think Mihai is thinking about using the portgroup's automatic lipo(1)-ing 
 as a hacky substitute for a proper GCC driver-driver.
 
 Yep, thanks Larry.
 
 
 Ah, clever.  I see what you mean, but yeah, that would require more 
 extensive use of muniversal which is more of a hack in my mind than a proper 
 solution. =/
 
 You're right. The proper solution would be to add the old driver-driver back 
 to FSF GCC and get it upstreamed, instead of relying even more on muniversal.
 
 Personally, I do not wish to do so, for multiple reasons.
 
 First, a compiler is a somewhat delicate matter and I do not think I've got 
 experience to get it right. I don't want to completely break (or break in 
 subtle ways) FSF GCC on OS X.
 
 Next, there's this copyright-license issue. While only taking driver-driver 
 from GCC 4.2 and backporting it to at least the newest GCC 5 version might 
 technically not be too difficult (although it probably requires 
 re-implementation in C++?), Apple would still be the original copyright 
 holder on that code and as such can decide under what license to release it. 
 Given they don't want to do that on a GPL-3 basis, only a complete rewrite 
 (for whatever that means *exactly*) would give a contributor the right to 
 claim copyright and determine the license.

That's not how it works.

1) It wouldn't be backporting because it's not going backwards ;)

2) Copyright and license are different issues.  It doesn't matter that Apple 
holds the copyright.

3) The driver-driver is GPLv2+ (look at driverdriver.c in the apple-gcc42 
port), so it's perfectly usable with gcc5.

 Even in a complete rewrite case, I'd be concerned with legal problems 
 because the general concept of a GCC driver-driver was their idea. Given that 
 we'd want the new driver-driver to behave like the 4.2 one, there 
 inadvertently will be similarities.

You cannot copyright ideas.  That is what patents are for.

 On the other hand, maybe Apple doesn't care and would indeed be happy to see 
 GCC a little bit better supported on their platform. This is pure speculation.

I don't really care about gcc, and I doubt many other at Apple do either.  
We've moved on to clang years ago and don't give gcc much thought.

 Does anyone here have:
  - a clear understanding of the legal matter?

I am not a lawyer, so I cannot give advise, but I am confident enough in my own 
understanding to act.

  - experience with writing robust code and maybe even a little bit of 
 knowledge of GCC's internals (likely helpful)?

yes

  - enough time to backport/implement this?

No, but it should be fairly straight forward, especially if you only care about 
supporting i386/x86_64 since that only requires the single intel CTARGET gcc.  
If you want to support ppc, that will be more problematic because you'll need 
to build a ppc gcc and an intel gcc.  Look at how hacky the build_gcc script is 
in the apple-gcc42 port.

  - confidence a backport will be accepted by the GCC project?

It isn't something FSF is interested in.  They haven't cared for the past 10 
years, so I doubt they'd start caring now.  It also doesn't really fit the gcc 
model.

 It's not required to meet all points. Even one would be good enough. This can 
 be a team effort if needed. The GCC Strike Force![0]
 
 On OS X, having driver-driver again with -arch support would certainly be a 
 very welcome improvement to FSF GCC.[1]
 
 
 
 Mihai
 
 [0] joke on https://wiki.debian.org/XStrikeForce (which itself it not a joke 
 but a great thing for Debian.)
 [1] This would only be useful for MacPorts on recent OS X releases if 
 -stdlib=libc++ would make GCC not link to its own libstdc++ at all. I don't 
 know if that's the case.
 
 ___
 macports-dev mailing list
 macports-dev@lists.macosforge.org
 https://lists.macosforge.org/mailman/listinfo/macports-dev



smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[Mihai Moldovan]

 I don't know any port that fails to build with libstdc++ but is
 happy with libc++ offhand.
 llvm-3.7 and webkit-gtk are two such ports that I can point to off
 the top of my head.

 By libstdc++ I am of course referring to the *system* libstdc++. I
 apologize if that was not clear.

I was talking about explicitly needing libc++, not C++11 support. I assume 
webkit-gtk and llvm-3.7 only need libc++ by extension because they are using 
C++11 features. Naturally, system libstdc++ won't cut it for these, but there's 
no immediate reason why they wouldn't in theory compile with a more recent 
libstdc++.


 Yes, but then you'd need to use the FSF GCC compilers from MacPorts
 to build all of your C++ ports in order for them to interoperate, and
 those ports would all have a new dependency on the libgcc port.

 Furthermore, nobody has bothered to update the gcc ports to use the
 Apple gcc driver driver, so the use of multiple -arch options pretty
 much blocks +universal which is a big issue for ports like wine that
 have heavy dependencies and are i386.

Yes, that would be adding a new dependency on libgcc and FSF GCC for all C++ 
ports. But so does using libc++ on 10.6. Implicitly at least. Fortunately that 
doesn't add dependencies on 10.7 and higher.

For specific ports, yes. In general, muniversal might take of that. But it 
doesn't make a lot of sense to change our ports base to muniversal, if we can 
salvage the current state by using clang. Which implies libc++. Gotcha.


On 15.04.2015 10:45 AM, Mojca Miklavec wrote:
 On Wed, Apr 15, 2015 at 9:42 AM, Mihai Moldovan wrote:
 On 14.04.2015 10:02 AM, Jeremy Huddleston Sequoia wrote:
 Because the above is completely entirely true.  You can have
 multiple versions of C++ runtimes in the same process (even
 libc++ and libstdc++).  The issue arrises when you try to pass
 objects between them.  For example, assume libA links libstdc++
 and libB links another copy of libstdc++ as well as libA.  If
 libA exports C++ API that libB consumes, then it will be
 interacting with them through the wrong runtime.

 Re-iterating: is this not the case for multiple copies of libc++?

 I don't know enough to answer, but at the moment we don't have
 multiple copies of libc++ anywhere. (Yet. I'm not sure what C++1z
 will bring.)

On 15.04.2015 12:55 PM, Jeremy Huddleston Sequoia wrote:
 It is certainly be the case for multiple copies of the libc++
 runtime.  But we're not dealing with multiple copies of libc++.
 However, you are considering multiple copies of libstdc++.

 How would you end up with two different versions of libc++?

Yes, I was explicitly thinking of C++1z support, which would (as far as I can 
tell) potentially lead to multiple copies of libc++.
Ok, so that's a problem. Not an immediate one, but maybe coming up some time 
later. I realize this is slightly off-topic for *this thread*, but I'd like to 
understand when and why this is a problem in general (multiple copies of some 
C++ runtime.)
I haven't yet understood it completely. Maybe I'm too stupid to do so in 
general, but I'm still very fuzzy on that aspect.


On 15.04.2015 12:55 PM, Jeremy Huddleston Sequoia wrote:
 Do you have evidence of any such issues? If so, that is a bug that
 should be filed. If you notice, our headers are heavily annotated
 with '#ifdef __BLOCKS__' around such cases.

No. No hard evidence as such. I can only remember seeing this happen before 
with... the wine ports IIRC? That's why we blacklisted FSF GCC on the wine* 
ports quite a while ago.

You're free to remove that blacklist line and try yourself, though... I haven't 
tried building wine with FSF GCC in a few years.


On 15.04.2015 12:55 PM, Jeremy Huddleston Sequoia wrote:
 What the system libraries link against is irrelevant.  It is the
 interfaces provided by the system libraries that matters.

So... uhm, to know if things could potentially go awry, I'd need to check the 
API if functions take C++ objects directly and guess what these functions might 
do with the objects?


On 15.04.2015 12:55 PM, Jeremy Huddleston Sequoia wrote:
 Yes, it most certainly is a system runtime.  We've been shipping
 libc++ with OS X since Lion (10.7).  It was just made the default
 C++ runtime with Mavericks (10.9).

I've been too unspecific. When I say system runtime, I mean the runtime that 
other system libraries providing a C++ ABI are linking against.


 It is not. A user must edit macports.conf multiple time while
 bootstrapping the MacPorts system for libc++, (re-) build
 clang/llvm ports multiple times to make them use the correct
 stdlib, will not be able to use binary archives etc.

 This is only true for 10.5. It works automatically on 10.6 and later
  as soon as the user changes three lines in macports.conf (before
 installing anything). The complicated bootstraping procedure is only
  needed for 10.5. 10.6 and later is a piece of cake.

Yes, the procedure isn't too difficult to carry out, but we will need to make 
users aware that 

Re: standard way to require c++11?

[Jeremy Huddleston Sequoia]

 On Apr 20, 2015, at 23:51, Mihai Moldovan io...@macports.org wrote:
 
 I don't know any port that fails to build with libstdc++ but is
 happy with libc++ offhand.
 llvm-3.7 and webkit-gtk are two such ports that I can point to off
 the top of my head.
 
 By libstdc++ I am of course referring to the *system* libstdc++. I
 apologize if that was not clear.
 
 I was talking about explicitly needing libc++, not C++11 support. I assume 
 webkit-gtk and llvm-3.7 only need libc++ by extension because they are using 
 C++11 features. Naturally, system libstdc++ won't cut it for these, but 
 there's no immediate reason why they wouldn't in theory compile with a more 
 recent libstdc++.

Yes, but that's not a supported configuration, and I don't plan on putting any 
effort into trying to support that.

Note that pretty much *ALL* of MacPorts C++ ports need to be compiled using the 
same C++ runtime.


 Yes, but then you'd need to use the FSF GCC compilers from MacPorts
 to build all of your C++ ports in order for them to interoperate, and
 those ports would all have a new dependency on the libgcc port.
 
 Furthermore, nobody has bothered to update the gcc ports to use the
 Apple gcc driver driver, so the use of multiple -arch options pretty
 much blocks +universal which is a big issue for ports like wine that
 have heavy dependencies and are i386.
 
 Yes, that would be adding a new dependency on libgcc and FSF GCC for all C++ 
 ports. But so does using libc++ on 10.6.

But the libc++ runtime that we install on 10.6 is signifigantly different in 
installation method than the libstdc++ runtime that is installed by libgcc.  It 
is designed to be compatible with future OS versions.  The port just installs a 
root, and activation installs the root.

 Implicitly at least. Fortunately that doesn't add dependencies on 10.7 and 
 higher.
 
 For specific ports, yes. In general, muniversal might take of that. But it 
 doesn't make a lot of sense to change our ports base to muniversal, if we can 
 salvage the current state by using clang. Which implies libc++. Gotcha.

What does muniversal have to do with anything?


 On 15.04.2015 10:45 AM, Mojca Miklavec wrote:
 On Wed, Apr 15, 2015 at 9:42 AM, Mihai Moldovan wrote:
 On 14.04.2015 10:02 AM, Jeremy Huddleston Sequoia wrote:
 Because the above is completely entirely true.  You can have
 multiple versions of C++ runtimes in the same process (even
 libc++ and libstdc++).  The issue arrises when you try to pass
 objects between them.  For example, assume libA links libstdc++
 and libB links another copy of libstdc++ as well as libA.  If
 libA exports C++ API that libB consumes, then it will be
 interacting with them through the wrong runtime.
 
 Re-iterating: is this not the case for multiple copies of libc++?
 
 I don't know enough to answer, but at the moment we don't have
 multiple copies of libc++ anywhere. (Yet. I'm not sure what C++1z
 will bring.)
 
 On 15.04.2015 12:55 PM, Jeremy Huddleston Sequoia wrote:
 It is certainly be the case for multiple copies of the libc++
 runtime.  But we're not dealing with multiple copies of libc++.
 However, you are considering multiple copies of libstdc++.
 
 How would you end up with two different versions of libc++?
 
 Yes, I was explicitly thinking of C++1z support, which would (as far as I can 
 tell) potentially lead to multiple copies of libc++.

Why would that potentially lead to multiple copies of libc++?

 Ok, so that's a problem. Not an immediate one, but maybe coming up some time 
 later. I realize this is slightly off-topic for *this thread*, but I'd like 
 to understand when and why this is a problem in general (multiple copies of 
 some C++ runtime.)
 I haven't yet understood it completely. Maybe I'm too stupid to do so in 
 general, but I'm still very fuzzy on that aspect.

Each runtime manages its internal data structures independently of the other.  
If you allocate an object in one runtime and release it in another, you may 
mess up accounting or worse because the second runtime does not own the memory 
of the object you are trying to free.

 On 15.04.2015 12:55 PM, Jeremy Huddleston Sequoia wrote:
 Do you have evidence of any such issues? If so, that is a bug that
 should be filed. If you notice, our headers are heavily annotated
 with '#ifdef __BLOCKS__' around such cases.
 
 No. No hard evidence as such. I can only remember seeing this happen before 
 with... the wine ports IIRC? That's why we blacklisted FSF GCC on the wine* 
 ports quite a while ago.

If so, it's a bug and deserves a radar.


 On 15.04.2015 12:55 PM, Jeremy Huddleston Sequoia wrote:
 What the system libraries link against is irrelevant.  It is the
 interfaces provided by the system libraries that matters.
 
 So... uhm, to know if things could potentially go awry, I'd need to check the 
 API if functions take C++ objects directly and guess what these functions 
 might do with the objects?

You could just dump global symbols and see if any of them 

Re: standard way to require c++11?

[Ryan Schmidt]

On Apr 15, 2015, at 3:45 AM, Mojca Miklavec wrote:

 (b) I've been suggesting for a long time already that we should set up
 three new buildbots to build packages against libc++ on 10.6-10.8. The
 lack of a buildbot is a showstopper for me, preventing me from
 globally switching to libc++ (on an old OS). And as more and more
 software is now shifting to C++11, the situation will just get much
 worse with time. If we start supporting libc++ in such a way that:
 - buildbots will build packages against libc++
 - users will be able to download a pre-configured MacPorts dmg
 (including the proper configuration)
 then it will no longer be a problem for users to switch to libc++. Of

And I think I've replied a couple times that, assuming you're wanting binary 
packages from these new buildbot builders to be uploaded to 
packages.macports.org, then before we can set that up, MacPorts base needs to 
be enhanced so that there is differentiation in the package filenames for the 
C++ library being used (e.g. add libc++ or libstdc++ to the package 
filename). But not all ports need that differentiation (i.e. those that don't 
use C++ don't need it). We can either add the differentiation to all package 
filenames, understanding that this will result in unnecessary duplication of 
files server-side, or we can try to find a way to identify which ports need the 
differentiation. Certainly noarch ports don't need it, but other ports are 
trickier. It's easy enough when creating the package (e.g. use `otool -L` to 
see if any files in the destroot link with /usr/lib/libc++.1.dylib or 
/usr/lib/libstdc++.6.dylib) but how would it work when trying to download a 
package to inst
 all? One solution would be for MacPorts to try two package filenames: look for 
the file with the C++ library differentiation, and if not found, then look 
again without it. That's not ideal but could work. Another option is that the 
port must use some new keyword to indicate that it uses or does not use C++, 
but it would be very easy for a portfile author to forget to do this or to do 
it wrong.



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[Mihai Moldovan]

[This message is merging Mojca's and Jeremy's answers]


On 14.04.2015 09:11 AM, Mojca Miklavec wrote:
 On Tue, Apr 14, 2015 at 8:18 AM, Mihai Moldovan wrote:
 On 14.04.2015 07:44 AM, Mojca Miklavec wrote:
 On Tue, Apr 14, 2015 at 3:54 AM, Mihai Moldovan wrote: Could 
 something like that be added to the compiler_blacklist
 PortGroup? I believe that pure C++11 projects need consistent
 handling and it would be very handy to allow a keyword like
 compiler.c++11 or compiler.something c++11 to replace all
 of the logic above inside a port.
 
 Yes, I should make that a PortGroup, iff it turns out to be good 
 enough to be one.
 
 In my opinion this could/should be part of compiler_blacklist. No 
 real need for a separate PortGroup.

Whatever makes most sense, really. The implementation is the same, only
details differ (using a variable like use_c++11 in compiler_blacklist
vs. just including PortGroup cxx11 1.0.)


 I don't fully understand that part. What if someone sets libc++ 
 globally? And: won't that pull in libstdc++ from gcc?
 
 .= 10.9: libstdc++? error
 .= 10.9: libc++? continue

 .= 10.8: libstdc++? continue
 .= 10.8: libc++? error
 
 This by itself is not pulling in anything yet. What I wanted to 
 express is that I assume using libstdc++ on = 10.9 an error and 
 using libc++ on = 10.8 an error.
 
 While I do understand 10.9: libstdc++? error, I disagree with = 
 10.8: libc++? error for at least two reasons: - A bunch of my ports 
 explicitly switch to libc++ (just because they need C++11) - Users 
 can set to use libc++ globally

On 14.04.2015 10:02 AM, Jeremy Huddleston Sequoia wrote:
 Yes, I actually have libc++ on all of my SL+ machines except a couple
 VMs I keep around for testing the default configuration.  IMO, it
 seems far easier to live on libc++ on SL than libstdc++ because so 
 many ports these days require it.

What are they actually requiring? libc++ or C++11? I don't know any port
that fails to build with libstdc++ but is happy with libc++ offhand.


 If someone on = 10.8 set libc++ globally... tough luck. He'll get 
 an error when trying to install the port.
 
 Which is stupid. Users would set libc++ globally precisely for the 
 reason you are trying to address: to avoid issues with the lack of 
 C++11 support in libstdc++. And then you are ruling out exactly the 
 users who care about C++11 most.

It's not stupid if you consider my point that libstdc++ is well able to
compile C++11 code if using the FSF GCC in MacPorts. That will leave the
problem if choking on Apple's headers that make use of their Blocks
extension, though. (Which is practically all Cocoa/Carbon stuff, I
guess?) For that reason (and +universal), clang + libc++ are indeed
the superior choice. I agree. There are problems with that approach as
well, though. More to that later in this message...


 But given that, in the case of hardcoding configure.cxx_stdlib to 
 another C++ runtime than the autodetected/default value, the 
 selected C++ runtime not matching the system C++ runtime and this 
 potentially leading to a variety of subtle to not so subtle bugs, 
 erroring out looked like the best thing to do.

On 14.04.2015 10:02 AM, Jeremy Huddleston Sequoia wrote:
 What do you mean by the system runtime?  There is no system 
 runtime.  There are two runtimes available on the system, an ancient
 libstdc++ kept around for binary compatibility, and a more modern
 libc++.

With system runtime, I mean the runtime that gets linked by Apple's
libraries. For instance:

/usr/lib/libobjc.dylib:
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current
version 228.0.0)
/usr/lib/libauto.dylib (compatibility version 1.0.0, current
version 1.0.0)
/usr/lib/libc++abi.dylib (compatibility version 1.0.0, current
version 48.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
version 120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1197.1.1)

Anything that links against -lobjc will also pull-in the system
runtime libc++. This is a problem, because we cannot provide an libobjc
alternative in MacPorts, so you may end up with two different versions
of libc++ instead. Is that any better?


 Jeremy did extensive testing of that configuration and I'm running a
  copy of MacPorts with those changes as well. I hardly experienced
 any problems (other than initial build failures that had to be
 polished out every now and then). I believe that this should become
 the default setting in not too distant future if we want to keep
 MacPorts working on older systems.

On 14.04.2015 10:02 AM, Jeremy Huddleston Sequoia wrote:
 To be fair, I did most of the work in MacPorts only after extensive 
 testing of the configuration and transition by Apple in Mountain Lion
 (or maybe it was Mavericks).  On newer OSX versions, we have an added
 benefit of having libstdc++ on top of libc++abi.  We don't have that
 benefit on SL, but other than that, installing the libcxx 

Re: standard way to require c++11?

[Mojca Miklavec]

On Wed, Apr 15, 2015 at 9:42 AM, Mihai Moldovan wrote:
 On 14.04.2015 10:02 AM, Jeremy Huddleston Sequoia wrote:
 Yes, I actually have libc++ on all of my SL+ machines except a couple
 VMs I keep around for testing the default configuration.  IMO, it
 seems far easier to live on libc++ on SL than libstdc++ because so
 many ports these days require it.

 What are they actually requiring? libc++ or C++11? I don't know any port
 that fails to build with libstdc++ but is happy with libc++ offhand.

That was probably a question for Jeremy, but my guess is C++11. And
using libc++ is simply one of the easiest way to provide native
support for C++11 (maybe with less crashes than if using GCC 4.9; and
certainly with more caring love from Apple developers that are
forbidden to touch GPL 3).

 No, libstdc++ is explicitly designed to allow multiple,
 incompatible libstdc++ version being in use at the same time.

 On 14.04.2015 10:02 AM, Jeremy Huddleston Sequoia wrote:
 I think you misunderstand.  This is not entirely true.

 Why do people report problems then?

 Because the above is completely entirely true.  You can have multiple
 versions of C++ runtimes in the same process (even libc++ and
 libstdc++).  The issue arrises when you try to pass objects between
 them.  For example, assume libA links libstdc++ and libB links
 another copy of libstdc++ as well as libA.  If libA exports C++ API
 that libB consumes, then it will be interacting with them through the
 wrong runtime.

 Re-iterating: is this not the case for multiple copies of libc++?

I don't know enough to answer, but at the moment we don't have
multiple copies of libc++ anywhere. (Yet. I'm not sure what C++1z will
bring.)

 In my experiments with a 10.6 VM, mp-clang-3.4 -std=c++11
 -stdlib=libstdc++ chokes on #include type_traits.

 I would suspect some misconfiguration. I successfully compiled
 many C++11 projects with mp-clang-3.4 (and libc++ of course).

 On OS X lower than 10.9? I can take out my VM for a test spin
 tonight and see if I can reproduce the issue (as a minimal
 testcase without MacPorts.)

 Maybe I didn't express it properly (or maybe I didn't read your
 statement carefully enough in the first place). Yes, you can compile
  #include type_traits on  10.9 with clang++-mp-3.4, but not with
  the system libstdc++ and I'm not sure how you would compile against
  libstdc++ as shipped by libgcc/gcc-4.9.

 Ok. We have a consensus here. clang and libstdc++ on  10.9 doesn't work.

True.

 This problem could probably be solved by
 patching clang (but it's not elegant or very sane.)

I wouldn't dare even attempting anything in that area.

 On 14.04.2015 10:02 AM, Jeremy Huddleston Sequoia wrote:
 'sudo port -v -s install libcxx' is fairly automatic ;)

 If you want to configure MacPorts to use the compiler by default,
 that isn't automatic but is fairly easy with steps laid out at:
 http://trac.macports.org/wiki/LibcxxOnOlderSystems

 It is not. A user must edit macports.conf multiple time while
 bootstrapping the MacPorts system for libc++, (re-) build clang/llvm
 ports multiple times to make them use the correct stdlib, will not be
 able to use binary archives etc.

This is only true for 10.5. It works automatically on 10.6 and later
as soon as the user changes three lines in macports.conf (before
installing anything). The complicated bootstraping procedure is only
needed for 10.5. 10.6 and later is a piece of cake.

(It would also be nice if someone could provide bootstrapped version
of MacPorts for 10.5 with all the binaries that are needed to continue
from there.)

 The needed compile time alone is inconvenient for users. And users will
 need to actually *know* about having to change options and maybe even
 re-compile all ports/bootstrap somehow. My goal was to provide C++11
 support transparently, without needing to change the macports.conf or
 rebuilding the whole system.

Of course we need to solve two different problems:

(a) Trying to patch the ports just enough to allow users to use C++11
software on default MacPorts installation with libstdc++. Taking
into account all the limitations.

(b) I've been suggesting for a long time already that we should set up
three new buildbots to build packages against libc++ on 10.6-10.8. The
lack of a buildbot is a showstopper for me, preventing me from
globally switching to libc++ (on an old OS). And as more and more
software is now shifting to C++11, the situation will just get much
worse with time. If we start supporting libc++ in such a way that:
- buildbots will build packages against libc++
- users will be able to download a pre-configured MacPorts dmg
(including the proper configuration)
then it will no longer be a problem for users to switch to libc++. Of
course that doesn't mean turning off the old buildbots right away. We
need sufficient testing first and we'll certainly need quite a bit of
adapting of the Portfiles before we are able to provide a smooth user
experience.

If you are trying to 

Re: standard way to require c++11?

[Jeremy Huddleston Sequoia]

 On 14.04.2015 10:02 AM, Jeremy Huddleston Sequoia wrote:
 Yes, I actually have libc++ on all of my SL+ machines except a couple
 VMs I keep around for testing the default configuration.  IMO, it
 seems far easier to live on libc++ on SL than libstdc++ because so 
 many ports these days require it.
 
 What are they actually requiring? libc++ or C++11?

They are requiring C++11 which by extension means libc++ in our current 
situation.

 I don't know any port
 that fails to build with libstdc++ but is happy with libc++ offhand.

llvm-3.7 and webkit-gtk are two such ports that I can point to off the top of 
my head.

By libstdc++ I am of course referring to the *system* libstdc++.  I apologize 
if that was not clear.

 If someone on = 10.8 set libc++ globally... tough luck. He'll get 
 an error when trying to install the port.
 
 Which is stupid. Users would set libc++ globally precisely for the 
 reason you are trying to address: to avoid issues with the lack of 
 C++11 support in libstdc++. And then you are ruling out exactly the 
 users who care about C++11 most.
 
 It's not stupid if you consider my point that libstdc++ is well able to
 compile C++11 code if using the FSF GCC in MacPorts.

Yes, but then you'd need to use the FSF GCC compilers from MacPorts to build 
all of your C++ ports in order for them to interoperate, and those ports would 
all have a new dependency on the libgcc port.

Furthermore, nobody has bothered to update the gcc ports to use the Apple gcc 
driver driver, so the use of multiple -arch options pretty much blocks 
+universal which is a big issue for ports like wine that have heavy 
dependencies and are i386.

 That will leave the
 problem if choking on Apple's headers that make use of their Blocks
 extension, though.

Do you have evidence of any such issues?  If so, that is a bug that should be 
filed.  If you notice, our headers are heavily annotated with '#ifdef 
__BLOCKS__' around such cases.

 (Which is practically all Cocoa/Carbon stuff, I
 guess?) For that reason (and +universal), clang + libc++ are indeed
 the superior choice. I agree. There are problems with that approach as
 well, though. More to that later in this message...
 
 
 But given that, in the case of hardcoding configure.cxx_stdlib to 
 another C++ runtime than the autodetected/default value, the 
 selected C++ runtime not matching the system C++ runtime and this 
 potentially leading to a variety of subtle to not so subtle bugs, 
 erroring out looked like the best thing to do.
 
 On 14.04.2015 10:02 AM, Jeremy Huddleston Sequoia wrote:
 What do you mean by the system runtime?  There is no system 
 runtime.  There are two runtimes available on the system, an ancient
 libstdc++ kept around for binary compatibility, and a more modern
 libc++.
 
 With system runtime, I mean the runtime that gets linked by Apple's
 libraries.

What the system libraries link against is irrelevant.  It is the interfaces 
provided by the system libraries that matters.

 For instance:
 
 /usr/lib/libobjc.dylib:
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current
 version 228.0.0)
/usr/lib/libauto.dylib (compatibility version 1.0.0, current
 version 1.0.0)
/usr/lib/libc++abi.dylib (compatibility version 1.0.0, current
 version 48.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
 version 120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
 version 1197.1.1)
 
 Anything that links against -lobjc will also pull-in the system
 runtime libc++.

libobjc is a *client* of libc++.  It does not expose any C++ interfaces to its 
clients.  As I mentioned in my earlier response, it is perfectly valid to have 
any number of various C++ runtimes in the same process so long as they are 
isolated from eachother.

 This is a problem, because we cannot provide an libobjc
 alternative in MacPorts, so you may end up with two different versions
 of libc++ instead. Is that any better?

How would you end up with two different versions of libc++?

 On 14.04.2015 10:02 AM, Jeremy Huddleston Sequoia wrote:
 To be fair, I did most of the work in MacPorts only after extensive 
 testing of the configuration and transition by Apple in Mountain Lion
 (or maybe it was Mavericks).  On newer OSX versions, we have an added
 benefit of having libstdc++ on top of libc++abi.  We don't have that
 benefit on SL, but other than that, installing the libcxx port on SL
 gets you a pretty modern and well tested C++ runtime that is forwards
 compatible with the system libc++ on Lion and later.
 
 What does mean forward compatible here? Does it mean that programs
 linked against libc++ will continue to work if you upgrade libc++ (which
 is AFAIK also the case with libstdc++), or does it mean that you can mix
 multiple libc++ versions in the same process? If I read port info
 libcxx correctly, the latter case doesn't work even with libc++.

It means that if you use 'clang++-mp-3.4 

Re: standard way to require c++11?

[Mihai Moldovan]

On 14.04.2015 07:44 AM, Mojca Miklavec wrote:
 On Tue, Apr 14, 2015 at 3:54 AM, Mihai Moldovan io...@macports.org wrote:
 Could something like that be added to the compiler_blacklist
 PortGroup? I believe that pure C++11 projects need consistent handling
 and it would be very handy to allow a keyword like compiler.c++11 or
 compiler.something c++11 to replace all of the logic above inside
 a port.

Yes, I should make that a PortGroup, iff it turns out to be good enough
to be one.


 -

 Human-readable explanation:

 I've added the compiler_blacklist_versions PortGroup and blacklisted GCC
  4.6 and clang  3.3, as only newer versions than that are fully
 C++11-compatible for all platforms.

 Then, I'm patching out -lc++ added by upstream for not very smart
 reasons (I need this on my machine) -- AND CHANGED -std=gnu++11 TO
 -std=c++11. This is getting important soonish.

 Next up: checking the OS X version. For 10.9 (darwin 13) and higher, I
 error out if configure.cxx_stdlib is set to libstdc++. Likewise, I error
 out on 10.8 (darwin 12) and lower if configure.cxx_stdlib is set to libc++.
 I don't fully understand that part. What if someone sets libc++
 globally? And: won't that pull in libstdc++ from gcc?

= 10.9: libstdc++? error
= 10.9: libc++? continue

= 10.8: libstdc++? continue
= 10.8: libc++? error

This by itself is not pulling in anything yet. What I wanted to express
is that I assume using libstdc++ on = 10.9 an error and using libc++ on
= 10.8 an error.

If someone on = 10.8 set libc++ globally... tough luck. He'll get an
error when trying to install the port. But given that, in the case of
hardcoding configure.cxx_stdlib to another C++ runtime than the
autodetected/default value, the selected C++ runtime not matching the
system C++ runtime and this potentially leading to a variety of subtle
to not so subtle bugs, erroring out looked like the best thing to do.


 This leaves us with libc++ on 10.9+ and libstdc++ on 10.8-. Compatible
 with the system C++ runtime. Good.

 For 10.9+ with libc++, only blacklisting all GCC versions is necessary
 to not pull in libstdc++ accidentally.

 ===
 Caveat: make sure the port does not use -std=gnu++11 on 10.9+. It WILL
 make clang link to libstdc++ (even if passing -stdlib=libc++!), because
 gnu++11 is c++11 with GNU extensions, which libc++ naturally does not
 provide.
 ===

 10.8- is a little bit more complicated. We need to make sure a recent
 libstdc++ is available. What Apple ships might not be recent enough,
 especially on 10.7 and 10.6.
 But then you'll run into problems that are more or less equivalent (or
 worse) to mixing libc++ and libstdc++.

No, libstdc++ is explicitly designed to allow multiple, incompatible
libstdc++ version being in use at the same time.

At least this is how I understood
https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html (Goals section)

I may have misunderstood it. If I did, please (anyone) enlighten me.


 Thus comes:

 depends_lib-append  {path:lib/libstdc\\+\\+.6.dylib:libgcc}

 In my experiments with a 10.6 VM, mp-clang-3.4 -std=c++11
 -stdlib=libstdc++ chokes on #include type_traits.
 I would suspect some misconfiguration. I successfully compiled many
 C++11 projects with mp-clang-3.4 (and libc++ of course).

On OS X lower than 10.9? I can take out my VM for a test spin tonight
and see if I can reproduce the issue (as a minimal testcase without
MacPorts.)


 Hence, I blacklist all clang versions on 10.8-.

 This will leave us with quite a mess. Now all compilers are blacklisted
 on older systems. Great.

 Not a big deal, though. We can set compiler.fallback to macports-gcc-4.9
 and port will use this specific compiler, given all others are blacklisted.

 With that, compiling C++11 code on 10.8- works great (I've tested it in
 a 10.6 VM) -- and the binaries even run correctly.
 I still believe that if the code was moved to a PortGroup, one would
 have to allow building with clang against libc++.

Maybe... I mean, coupled with Jeremy's efforts getting libc++ to work on
10.5 and 10.6. That procedure isn't exactly automatic, though. And even
then -- won't you be mixing libc++ and libstdc++ when linking anything
system-related that happens to be written in C++ and links libstdc++?

My idea is: stay with libstdc++ on legacy platforms and avoid the
problems created by mixing C++ runtimes, messing with user systems in a
non-interactive way and creating a new buildslave infrastructure. Why
would you not use libstdc++, if it works *and* can be used -- together
with GCC -- to compile C++11 code? (Yes, I'm avoiding your PPC
problem. I'm seriously sorry GCC is not building there, but there's not
much I can do about that.)



Mihai



signature.asc
Description: OpenPGP digital signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org

Re: standard way to require c++11?

[Mojca Miklavec]

On Tue, Apr 14, 2015 at 8:18 AM, Mihai Moldovan wrote:
 On 14.04.2015 07:44 AM, Mojca Miklavec wrote:
 On Tue, Apr 14, 2015 at 3:54 AM, Mihai Moldovan wrote:
 Could something like that be added to the compiler_blacklist
 PortGroup? I believe that pure C++11 projects need consistent handling
 and it would be very handy to allow a keyword like compiler.c++11 or
 compiler.something c++11 to replace all of the logic above inside
 a port.

 Yes, I should make that a PortGroup, iff it turns out to be good enough
 to be one.

In my opinion this could/should be part of compiler_blacklist. No real
need for a separate PortGroup.

 I don't fully understand that part. What if someone sets libc++
 globally? And: won't that pull in libstdc++ from gcc?

= 10.9: libstdc++? error
= 10.9: libc++? continue

 = 10.8: libstdc++? continue
 = 10.8: libc++? error

 This by itself is not pulling in anything yet. What I wanted to express
 is that I assume using libstdc++ on = 10.9 an error and using libc++ on
 = 10.8 an error.

While I do understand 10.9: libstdc++? error, I disagree with =
10.8: libc++? error for at least two reasons:
- A bunch of my ports explicitly switch to libc++ (just because they need C++11)
- Users can set to use libc++ globally

 If someone on = 10.8 set libc++ globally... tough luck. He'll get an
 error when trying to install the port.

Which is stupid. Users would set libc++ globally precisely for the
reason you are trying to address: to avoid issues with the lack of
C++11 support in libstdc++. And then you are ruling out exactly the
users who care about C++11 most.

 But given that, in the case of
 hardcoding configure.cxx_stdlib to another C++ runtime than the
 autodetected/default value, the selected C++ runtime not matching the
 system C++ runtime and this potentially leading to a variety of subtle
 to not so subtle bugs, erroring out looked like the best thing to do.

Jeremy did extensive testing of that configuration and I'm running a
copy of MacPorts with those changes as well. I hardly experienced any
problems (other than initial build failures that had to be polished
out every now and then). I believe that this should become the default
setting in not too distant future if we want to keep MacPorts working
on older systems.

 No, libstdc++ is explicitly designed to allow multiple, incompatible
 libstdc++ version being in use at the same time.

Why do people report problems then?

 In my experiments with a 10.6 VM, mp-clang-3.4 -std=c++11
 -stdlib=libstdc++ chokes on #include type_traits.
 I would suspect some misconfiguration. I successfully compiled many
 C++11 projects with mp-clang-3.4 (and libc++ of course).

 On OS X lower than 10.9? I can take out my VM for a test spin tonight
 and see if I can reproduce the issue (as a minimal testcase without
 MacPorts.)

Maybe I didn't express it properly (or maybe I didn't read your
statement carefully enough in the first place). Yes, you can compile
#include type_traits on  10.9 with clang++-mp-3.4, but not with
the system libstdc++ and I'm not sure how you would compile against
libstdc++ as shipped by libgcc/gcc-4.9. But the idea is that you *can*
compile that if you use libc++. My main point was that there should be
no need to blacklist clang.

 cat test.cpp
#include type_traits

int main()
{
return 0;
}

 clang++-mp-3.5 test.cpp -o test
test.cpp:1:10: fatal error: 'type_traits' file not found
#include type_traits
 ^
1 error generated.

 clang++-mp-3.5 test.cpp -o test -stdlib=libc++
[success]


 Hence, I blacklist all clang versions on 10.8-.

 This will leave us with quite a mess. Now all compilers are blacklisted
 on older systems. Great.

 Not a big deal, though. We can set compiler.fallback to macports-gcc-4.9
 and port will use this specific compiler, given all others are blacklisted.

 With that, compiling C++11 code on 10.8- works great (I've tested it in
 a 10.6 VM) -- and the binaries even run correctly.
 I still believe that if the code was moved to a PortGroup, one would
 have to allow building with clang against libc++.

 Maybe... I mean, coupled with Jeremy's efforts getting libc++ to work on
 10.5 and 10.6.

It already works (perfectly) on 10.6. His recent efforts were
addressing 10.5 and I'm not sure if the work is finished by now, but
yes, 10.5 might be doable.

 That procedure isn't exactly automatic, though.

It is on 10.6.

 And even
 then -- won't you be mixing libc++ and libstdc++ when linking anything
 system-related that happens to be written in C++ and links libstdc++?

In your case one would be mixing libstdc++ shipped by apple and
libstdc++ as shipped by gcc. From what I understand from fellow
macports developers/maintainers mixing different libstdc++ is worse.

 My idea is: stay with libstdc++ on legacy platforms and avoid the
 problems created by mixing C++ runtimes, messing with user systems in a
 non-interactive way and creating a new buildslave infrastructure. Why
 would you not use libstdc++, if it works 

Re: standard way to require c++11?

[Jeremy Huddleston Sequoia]

 On Apr 14, 2015, at 00:11, Mojca Miklavec mo...@macports.org wrote:
 
 On Tue, Apr 14, 2015 at 8:18 AM, Mihai Moldovan wrote:
 On 14.04.2015 07:44 AM, Mojca Miklavec wrote:
 On Tue, Apr 14, 2015 at 3:54 AM, Mihai Moldovan wrote:
 Could something like that be added to the compiler_blacklist
 PortGroup? I believe that pure C++11 projects need consistent handling
 and it would be very handy to allow a keyword like compiler.c++11 or
 compiler.something c++11 to replace all of the logic above inside
 a port.
 
 Yes, I should make that a PortGroup, iff it turns out to be good enough
 to be one.
 
 In my opinion this could/should be part of compiler_blacklist. No real
 need for a separate PortGroup.
 
 I don't fully understand that part. What if someone sets libc++
 globally? And: won't that pull in libstdc++ from gcc?
 
 = 10.9: libstdc++? error
 = 10.9: libc++? continue
 
 = 10.8: libstdc++? continue
 = 10.8: libc++? error
 
 This by itself is not pulling in anything yet. What I wanted to express
 is that I assume using libstdc++ on = 10.9 an error and using libc++ on
 = 10.8 an error.
 
 While I do understand 10.9: libstdc++? error, I disagree with =
 10.8: libc++? error for at least two reasons:
 - A bunch of my ports explicitly switch to libc++ (just because they need 
 C++11)
 - Users can set to use libc++ globally
 
 If someone on = 10.8 set libc++ globally... tough luck. He'll get an
 error when trying to install the port.
 
 Which is stupid. Users would set libc++ globally precisely for the
 reason you are trying to address: to avoid issues with the lack of
 C++11 support in libstdc++. And then you are ruling out exactly the
 users who care about C++11 most.

Yes, I actually have libc++ on all of my SL+ machines except a couple VMs I 
keep around for testing the default configuration.  IMO, it seems far easier to 
live on libc++ on SL than libstdc++ because so many ports these days require it.

 But given that, in the case of
 hardcoding configure.cxx_stdlib to another C++ runtime than the
 autodetected/default value, the selected C++ runtime not matching the
 system C++ runtime and this potentially leading to a variety of subtle
 to not so subtle bugs, erroring out looked like the best thing to do.

What do you mean by the system runtime?  There is no system runtime.  There 
are two runtimes available on the system, an ancient libstdc++ kept around for 
binary compatibility, and a more modern libc++.

 Jeremy did extensive testing of that configuration and I'm running a
 copy of MacPorts with those changes as well. I hardly experienced any
 problems (other than initial build failures that had to be polished
 out every now and then). I believe that this should become the default
 setting in not too distant future if we want to keep MacPorts working
 on older systems.

To be fair, I did most of the work in MacPorts only after extensive testing of 
the configuration and transition by Apple in Mountain Lion (or maybe it was 
Mavericks).  On newer OSX versions, we have an added benefit of having 
libstdc++ on top of libc++abi.  We don't have that benefit on SL, but other 
than that, installing the libcxx port on SL gets you a pretty modern and well 
tested C++ runtime that is forwards compatible with the system libc++ on Lion 
and later.

 No, libstdc++ is explicitly designed to allow multiple, incompatible
 libstdc++ version being in use at the same time.

I think you misunderstand.  This is not entirely true.

 Why do people report problems then?

Because the above is completely entirely true.  You can have multiple versions 
of C++ runtimes in the same process (even libc++ and libstdc++).  The issue 
arrises when you try to pass objects between them.  For example, assume libA 
links libstdc++ and libB links another copy of libstdc++ as well as libA.  If 
libA exports C++ API that libB consumes, then it will be interacting with them 
through the wrong runtime.

 In my experiments with a 10.6 VM, mp-clang-3.4 -std=c++11
 -stdlib=libstdc++ chokes on #include type_traits.

Yeah.  That's because C++11 isn't supported by libstdc++ on SL.

 I would suspect some misconfiguration. I successfully compiled many
 C++11 projects with mp-clang-3.4 (and libc++ of course).
 
 On OS X lower than 10.9? I can take out my VM for a test spin tonight
 and see if I can reproduce the issue (as a minimal testcase without
 MacPorts.)

See http://trac.macports.org/wiki/LibcxxOnOlderSystems

 Maybe I didn't express it properly (or maybe I didn't read your
 statement carefully enough in the first place). Yes, you can compile
 #include type_traits on  10.9 with clang++-mp-3.4, but not with
 the system libstdc++ and I'm not sure how you would compile against
 libstdc++ as shipped by libgcc/gcc-4.9. But the idea is that you *can*
 compile that if you use libc++. My main point was that there should be
 no need to blacklist clang.
 
 cat test.cpp
 #include type_traits
 
 int main()
 {
 return 0;
 }
 
 clang++-mp-3.5 test.cpp -o test
 

Re: standard way to require c++11?

[Brandon Allbery]

On Tue, Apr 14, 2015 at 10:23 AM, René J.V. rjvber...@gmail.com wrote:

 The main problem is that Apple's own C++ stuff is based on either a
 pre-C++11 libstdc++ or a C++11 libc++. You could probably build an
 official
 GPL3-d libstdc++ with C++11 support and it would probably even work (that

 If that is equivalent to replacing the system libstdc++ with the one from
 port:gcc-4x then no, that doesn't work. Or rather, it seemed to work just
 fine until I had to reboot. Then things started to fail.


I was not talking about actually replacing the system libstdc++; you get
what you deserve if you do that. I would expect something linking against
an alternative libstdc++ to have some chance to work, though.


 being one of the points of C++11) but might not be able to distribute the
 resulting objects/binaries because of conflicts between GPL and Apple's
 licenses.

 How large an intersection would there be between the users on old(er) OS X
 versions who require a C++11 compatible libstdc++ and those who ship
 commercial binaries?


I was thinking more (a) buildbots (b) tossing the result on a web page for
others to download instead of having to do the whole weird setup themselves.


 (PS: we're talking about the equivalent of Microsoft's msvc runtimes, no?)


Not exactly, as that includes libc. This is just the glue that allows C++
objects to work and be shared between components; things blow up if some
components expect a C++11-compatible object and get a pre-C++11 object, or
vice versa.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[René J . V . Bertin]

On Tuesday April 14 2015 10:32:32 Brandon Allbery wrote:

I was not talking about actually replacing the system libstdc++; you get
what you deserve if you do that. I would expect something linking against

:)

an alternative libstdc++ to have some chance to work, though.

I've used macports-gcc-4.x to build certain ports with C++11 code of 
non-trivial complexity (QtCurve, KDevelop) on 10.6 and never ran into the 
slightest issue because of it.

I was thinking more [...] (b) tossing the result on a web page for
others to download instead of having to do the whole weird setup themselves.

Sounds like a special case of Finagle's law to me ;)

Not exactly, as that includes libc. This is just the glue that allows C++

Ah, right.

R
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[René J . V . Bertin]

On Tuesday April 14 2015 10:01:05 Brandon Allbery wrote:

Why would they? They don't use it and you can get it from the gcc project
easily enough.

Heh, no, it's us users who'd be using it (with all that implies O:-) )

The main problem is that Apple's own C++ stuff is based on either a
pre-C++11 libstdc++ or a C++11 libc++. You could probably build an official
GPL3-d libstdc++ with C++11 support and it would probably even work (that

If that is equivalent to replacing the system libstdc++ with the one from 
port:gcc-4x then no, that doesn't work. Or rather, it seemed to work just fine 
until I had to reboot. Then things started to fail.
I seem to recall from the discussions at the time that there are indeed Apple 
additions to the system libstdc++ that are not in the FSF version.

being one of the points of C++11) but might not be able to distribute the
resulting objects/binaries because of conflicts between GPL and Apple's
licenses.

How large an intersection would there be between the users on old(er) OS X 
versions who require a C++11 compatible libstdc++ and those who ship commercial 
binaries?

(PS: we're talking about the equivalent of Microsoft's msvc runtimes, no?)

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[Mihai Moldovan]

On 14.04.2015 04:01 PM, Brandon Allbery wrote:
 The main problem is that Apple's own C++ stuff is based on either a
 pre-C++11 libstdc++ or a C++11 libc++. You could probably build an
 official GPL3-d libstdc++ with C++11 support and it would probably even
 work (that being one of the points of C++11) but might not be able to
 distribute the resulting objects/binaries because of conflicts between
 GPL and Apple's licenses.

That's the way I tried to go down with audacious. However, obviously the
general feedback is that people prefer to use libc++ instead. I still
have to answer to the main thread and will try to catch up with replies
as soon as I have more time than just 5 minutes.



Mihai



signature.asc
Description: OpenPGP digital signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[René J . V . Bertin]

On Tuesday April 14 2015 08:56:48 Brandon Allbery wrote:

 would you not use libstdc++, if it works *and* can be used -- together
 with GCC -- to compile C++11 code?


Last I checked, it doesn't work; Apple does not and will not ship a
libstdc++ that is C++11-compatible, because all such are GPL3.

It's a pity they don't even provide the source code for such a libstdc++ 
version, IIUC there are no legal naggles with doing that. And I think even the 
average Joe User who would have need for it would be capable of following build 
and install instructions or execute a script that does all the work.
Anyway, it is how it is (and providing free OS upgrades means you can feel like 
getting away with not maintaining older versions and all that O:-) ).

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[Brandon Allbery]

On Tue, Apr 14, 2015 at 9:54 AM, René J.V. rjvber...@gmail.com wrote:

 It's a pity they don't even provide the source code for such a libstdc++
 version


Why would they? They don't use it and you can get it from the gcc project
easily enough.

The main problem is that Apple's own C++ stuff is based on either a
pre-C++11 libstdc++ or a C++11 libc++. You could probably build an official
GPL3-d libstdc++ with C++11 support and it would probably even work (that
being one of the points of C++11) but might not be able to distribute the
resulting objects/binaries because of conflicts between GPL and Apple's
licenses.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[Brandon Allbery]

On Tue, Apr 14, 2015 at 2:18 AM, Mihai Moldovan io...@macports.org wrote:

 This by itself is not pulling in anything yet. What I wanted to express
 is that I assume using libstdc++ on = 10.9 an error and using libc++ on
 = 10.8 an error.


10.7 supports libc++.

Why
 would you not use libstdc++, if it works *and* can be used -- together
 with GCC -- to compile C++11 code?


Last I checked, it doesn't work; Apple does not and will not ship a
libstdc++ that is C++11-compatible, because all such are GPL3.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[Mihai Moldovan]

As a reply to what we discussed on IRC today, here's the relevant
changes for the C++11 on steroids part of one of my ports
(audacious-core):

Revision: 135031
  https://trac.macports.org/changeset/135031
Author:   ionic at macports.org
Date: 2015-04-13 09:24:21 -0700 (Mon, 13 Apr 2015)
Log Message:
---
audacious{,-{core,plugins}}: update to 3.6.1. Also:

  - Upstream now uses C++11. Insert abomination to make that work on
10.6+.
  - Re-do patches. Replace -std=gnu++11 with -std=c++11 to not pull in
libstdc++ unnecessarily.
[...]

Modified: trunk/dports/multimedia/audacious-core/Portfile
===
--- trunk/dports/multimedia/audacious-core/Portfile 2015-04-13 16:07:33
UTC (rev 135030)
+++ trunk/dports/multimedia/audacious-core/Portfile 2015-04-13 16:24:21
UTC (rev 135031)
@@ -3,12 +3,13 @@

 PortSystem  1.0
 PortGroup   conflicts_build 1.0
+PortGroup   compiler_blacklist_versions 1.0

 nameaudacious-core
[...]
@@ -31,12 +32,15 @@
 master_siteshttp://distfiles.audacious-media-player.org
 distname${real_name}-${version}
 use_bzip2   yes
[...]

-patchfiles  patch-buildsys.diff
+patchfiles  patch-buildsys.diff \
+
patch-acinclude.m4-drop-libc++-switch-from-gnu++11-to-c++11.diff

 depends_build   path:bin/pkg-config:pkgconfig \
 path:bin/aclocal:automake \
@@ -59,17 +62,48 @@
 autoreconf.cmd  ./autogen.sh
 autoreconf.args

+# A compiler supporting C++11 is required to build audacious and its
plugins.
+# The newer, the merrier.
+# Compilers supporting C++11 are GCC = 4.6 and clang = 3.3.
+# We do not know what cc is, so blacklist it as well.
+compiler.blacklist-append   {*gcc-4.[0-5]} {clang  500}
macports-clang-2.* \
+{macports-clang-3.[0-2]} cc
+
 platform darwin {
[...]
+if {${os.major} = 13} {
+if {${configure.cxx_stdlib} ne {} 
+[string equal ${configure.cxx_stdlib} libc++]} {
+# Blacklist all GCC compilers to not accidentally pull in
libstdc++.
+compiler.blacklist-append {*gcc*}
+
+# Make sure binary runs on 10.9+ only.
+configure.ldflags-append  -mmacosx-version-min=10.9
 } else {
[...]
+ui_error The system libraries in OS X 10.9 and higher use
libc++. Thus, libstdc++ is not supported for this port.
+error libstdc++ supported on = 10.8 only.
 }
 } else {
[...]
+if {${configure.cxx_stdlib} ne {} 
+[string equal ${configure.cxx_stdlib} libc++]} {
+ui_error The system libraries in OS X 10.8 and lower use
libstdc++. Thus, libstdc++ is not supported for this port.
+error libc++ supported on = 10.9 only.
+} else {
+# Shameless copy from rust.
+depends_lib-append
{path:lib/libstdc\\+\\+.6.dylib:libgcc}
+
+# Force GCC 4.9.
+compiler.blacklist-append   {*clang*}
+compiler.fallback-appendmacports-gcc-4.9
+
+# Make sure binary runs on 10.5+ only.
+configure.ldflags-append-mmacosx-version-min=10.5
+
+notes-append {
+Upstream for some reason requires libc++.
+Your build will use libstdc++. The
maintainer assumes this
+to be OK, but you're on your own if stuff
breaks.\
+}
+}
 }
 }

Added:
trunk/dports/multimedia/audacious-core/files/patch-acinclude.m4-drop-libc++-switch-from-gnu++11-to-c++11.diff
===
---
trunk/dports/multimedia/audacious-core/files/patch-acinclude.m4-drop-libc++-switch-from-gnu++11-to-c++11.diff
(rev 0)
+++
trunk/dports/multimedia/audacious-core/files/patch-acinclude.m4-drop-libc++-switch-from-gnu++11-to-c++11.diff
2015-04-13 16:24:21 UTC (rev 135031)
@@ -0,0 +1,22 @@
+--- acinclude.m4.orig
 acinclude.m4
+@@ -83,8 +83,8 @@ AC_REQUIRE([AC_SYS_LARGEFILE])
+ if test x$GCC = xyes; then
+ CFLAGS=$CFLAGS -std=gnu99 -ffast-math -Wall -pipe
+ if test x$HAVE_DARWIN = xyes; then
+-CXXFLAGS=$CXXFLAGS -stdlib=libc++ -std=gnu++11 -ffast-math
-Wall -pipe
+-LDFLAGS=$LDFLAGS -lc++ -stdlib=libc++
++CXXFLAGS=$CXXFLAGS -std=c++11 -ffast-math -Wall -pipe
++LDFLAGS=$LDFLAGS
+ else
+ CXXFLAGS=$CXXFLAGS -std=gnu++11 -ffast-math -Wall -pipe
+ fi
+@@ -101,7 +101,7 @@ if test x$HAVE_DARWIN = xyes; then
+ AC_PROG_OBJCXX
+ AC_PROG_OBJCXXCPP
+
+-OBJCXXFLAGS=$OBJCXXFLAGS -stdlib=libc++ -std=c++11
++OBJCXXFLAGS=$OBJCXXFLAGS -std=c++11
+ fi
+
+ dnl Enable -Wl,-z,defs only on Linux


-

Human-readable explanation:

I've added the compiler_blacklist_versions PortGroup and blacklisted GCC
 4.6 and 

Re: standard way to require c++11?

[Mojca Miklavec]

On Tue, Apr 14, 2015 at 3:54 AM, Mihai Moldovan io...@macports.org wrote:
 As a reply to what we discussed on IRC today, here's the relevant
 changes for the C++11 on steroids part of one of my ports
 (audacious-core):

 /.../

 +# A compiler supporting C++11 is required to build audacious and its
 plugins.
 +# The newer, the merrier.
 +# Compilers supporting C++11 are GCC = 4.6 and clang = 3.3.
 +# We do not know what cc is, so blacklist it as well.
 +compiler.blacklist-append   {*gcc-4.[0-5]} {clang  500}
 macports-clang-2.* \
 +{macports-clang-3.[0-2]} cc
 +
  platform darwin {
 [...]
 +if {${os.major} = 13} {
 +if {${configure.cxx_stdlib} ne {} 
 +[string equal ${configure.cxx_stdlib} libc++]} {
 +# Blacklist all GCC compilers to not accidentally pull in
 libstdc++.
 +compiler.blacklist-append {*gcc*}
 +
 +# Make sure binary runs on 10.9+ only.
 +configure.ldflags-append  -mmacosx-version-min=10.9
  } else {
 [...]
 +ui_error The system libraries in OS X 10.9 and higher use
 libc++. Thus, libstdc++ is not supported for this port.
 +error libstdc++ supported on = 10.8 only.
  }
  } else {
 [...]
 +if {${configure.cxx_stdlib} ne {} 
 +[string equal ${configure.cxx_stdlib} libc++]} {
 +ui_error The system libraries in OS X 10.8 and lower use
 libstdc++. Thus, libstdc++ is not supported for this port.
 +error libc++ supported on = 10.9 only.
 +} else {
 +# Shameless copy from rust.
 +depends_lib-append
 {path:lib/libstdc\\+\\+.6.dylib:libgcc}
 +
 +# Force GCC 4.9.
 +compiler.blacklist-append   {*clang*}
 +compiler.fallback-appendmacports-gcc-4.9

Could something like that be added to the compiler_blacklist
PortGroup? I believe that pure C++11 projects need consistent handling
and it would be very handy to allow a keyword like compiler.c++11 or
compiler.something c++11 to replace all of the logic above inside
a port.

 -

 Human-readable explanation:

 I've added the compiler_blacklist_versions PortGroup and blacklisted GCC
  4.6 and clang  3.3, as only newer versions than that are fully
 C++11-compatible for all platforms.

 Then, I'm patching out -lc++ added by upstream for not very smart
 reasons (I need this on my machine) -- AND CHANGED -std=gnu++11 TO
 -std=c++11. This is getting important soonish.

 Next up: checking the OS X version. For 10.9 (darwin 13) and higher, I
 error out if configure.cxx_stdlib is set to libstdc++. Likewise, I error
 out on 10.8 (darwin 12) and lower if configure.cxx_stdlib is set to libc++.

I don't fully understand that part. What if someone sets libc++
globally? And: won't that pull in libstdc++ from gcc?

 This leaves us with libc++ on 10.9+ and libstdc++ on 10.8-. Compatible
 with the system C++ runtime. Good.

 For 10.9+ with libc++, only blacklisting all GCC versions is necessary
 to not pull in libstdc++ accidentally.

 ===
 Caveat: make sure the port does not use -std=gnu++11 on 10.9+. It WILL
 make clang link to libstdc++ (even if passing -stdlib=libc++!), because
 gnu++11 is c++11 with GNU extensions, which libc++ naturally does not
 provide.
 ===

 10.8- is a little bit more complicated. We need to make sure a recent
 libstdc++ is available. What Apple ships might not be recent enough,
 especially on 10.7 and 10.6.

But then you'll run into problems that are more or less equivalent (or
worse) to mixing libc++ and libstdc++.
 Thus comes:

 depends_lib-append  {path:lib/libstdc\\+\\+.6.dylib:libgcc}

 In my experiments with a 10.6 VM, mp-clang-3.4 -std=c++11
 -stdlib=libstdc++ chokes on #include type_traits.

I would suspect some misconfiguration. I successfully compiled many
C++11 projects with mp-clang-3.4 (and libc++ of course).
 Hence, I blacklist all clang versions on 10.8-.

 This will leave us with quite a mess. Now all compilers are blacklisted
 on older systems. Great.

 Not a big deal, though. We can set compiler.fallback to macports-gcc-4.9
 and port will use this specific compiler, given all others are blacklisted.

 With that, compiling C++11 code on 10.8- works great (I've tested it in
 a 10.6 VM) -- and the binaries even run correctly.

I still believe that if the code was moved to a PortGroup, one would
have to allow building with clang against libc++.

(And I still believe that we need to set up buildbots to build the
complete macports against libc++ on 10.6-10.8.)

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[Chris Jones]

On 19/03/15 18:44, Michael Dickens wrote:

On Thu, Mar 19, 2015, at 02:06 PM, Lawrence Velázquez wrote:

On Mar 19, 2015, at 1:56 PM, Michael Dickens michae...@macports.org
wrote:

Exactly. If we key off of {${configure.cxx_stdlib} eq libstdc++}, then
I think this can be made to work; er, mostly.


I believe this is only safe if you're absolutely sure that all the C++
objects your code uses or links with uses MacPorts' libstdc++ /
libc++.


I know it is possible to select configure.stdlib on a per-port basis ...
but, it's certainly not wise in general  how many folks or ports really
-try- to do this? I know it fails for me (on 10.8 and 10.10:
cross-linking libc++ and libstdc++ from Apple and MacPorts) way more
often than it works, so I just don't do it. I don't really see this as a
major issue, given how well it doesn't work. - MLD


Using Macports gcc you will still have the problem of mixing different 
C++ runtimes, the macports stdlibc++ used by the gcc ports, and the 
system one. They are not the same and if you try use at the same time 
ports built with the normal compiler, to yours, problems can happen.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[Michael Dickens]

On Fri, Mar 20, 2015, at 04:38 AM, Chris Jones wrote:
 Using Macports gcc you will still have the problem of mixing different 
 C++ runtimes, the macports stdlibc++ used by the gcc ports, and the 
 system one. They are not the same and if you try use at the same time 
 ports built with the normal compiler, to yours, problems can happen.

I appreciate your concern, Chris. And, I agree in a general sense: in my
experience, mixing C++ runtime libraries results in failures  is
frustrating as a user and developer. That said, I think that the current
way we've determined (discussions here and on IRC) of forcing a C++11
compiler should work for the vast vast majority of users, because it
uses GCC when the C++ runtime is libstdc++ and Clang when libc++ -- so,
we're -not- mixing C++ runtime libraries any more than normal for those
platforms. This mixing will not work in extreme cases, but I expect
there to be very few such cases if any -- and, mostly developers testing
odd combinations of OSX and C++ runtime support. Hence, I'm not
concerned any more than usual about mixing the C++ runtime libraries in
these few, specific ports that will use and require C++11 support. I
will start pushing this style of forcing C++11 into a few ports that I
maintain  don't work on 10.8 and prior  we'll see if I get any failure
reports back; I doubt I will. - MLD
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[Chris Jones]

On 19/03/15 17:54, René J.V. Bertin wrote:

On Thursday March 19 2015 17:01:02 Chris Jones wrote:


Using gcc is a bad idea, this can lead to C++ runtime issues.


On newer OS X versions where libc++ is the default (or only) C++ runtime.


No, its problematic on all OSX releases.




Which means newer systems use the compatible system clang compiler, and
older system use the macports clang compiler. I think this is the 'best
effort' solution. It doesn't work on OSX10.6 though, there we simply
given up support, as least with the root6 port.


I don't see what's against using port:gcc4x on 10.6 or 10.7 as long as you 
don't need Apple-specific compiler extensions (probably including universal 
builds).


IFAIU, its still a problem as you will then be mixing the libstdc++ from 
macports with the system one. Not as bad as mixing libc++ with 
libstdc++, but still far from ideal and can lead to problems.


It's how I built relatively complex ports like kdevplatform and 
kdevelop, without any issues. Oh, and (favourite topic of mine), it's 
also a lot faster than the clang ports O:-)


Speed is not a concern for most, as they get most ports via the binary 
tarballs, and who cares how long it takes on the buildbots ;)


Speed also should never trump correctness, and again AFAIK, its more 
correct to use Macports clang in these cases, than macports GCC.


Chris


I've never managed to use the blacklisting feature to force port to use 
g++-mp-4.{7,8,9}, though.

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[Michael Dickens]

On Thu, Mar 19, 2015, at 01:54 PM, René J.V. Bertin wrote:
 On Thursday March 19 2015 17:01:02 Chris Jones wrote:
 
  Using gcc is a bad idea, this can lead to C++ runtime issues.
 
 On newer OS X versions where libc++ is the default (or only) C++ runtime.

Exactly. If we key off of {${configure.cxx_stdlib} eq libstdc++}, then
I think this can be made to work; er, mostly.

  Which means newer systems use the compatible system clang compiler, and 
  older system use the macports clang compiler. I think this is the 'best 
  effort' solution. It doesn't work on OSX10.6 though, there we simply 
  given up support, as least with the root6 port.
 
 I don't see what's against using port:gcc4x on 10.6 or 10.7 as long as
 you don't need Apple-specific compiler extensions (probably including
 universal builds). It's how I built relatively complex ports like
 kdevplatform and kdevelop, without any issues. Oh, and (favourite topic
 of mine), it's also a lot faster than the clang ports O:-)
 I've never managed to use the blacklisting feature to force port to use
 g++-mp-4.{7,8,9}, though.

Yes to all the above. In my test (just now), I can get GCC 4.[789] via:
{{{
compiler.fallback-append macports-gcc-4.9 macports-gcc-4.8
macports-gcc-4.7
}}}
where this list is in priority order, too. - MLD
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[Michael Dickens]

So, here's what I have thus far:

{{{
if {${configure.cxx_stdlib} eq libstdc++} {
# *clang* when using libstdc++ do not seem to support C++11;
# C++11 support seems to need GCC 4.7+ when using libstdc++;
# could use C++0x support on GCC4.[56], but just ignore it since
# there are newer compilers already in place as defaults.
# Blacklist GCC compilers not supporting C++11 and all CLANG.
compiler.blacklist-append *clang* {*gcc-3*} {*gcc-4.[0-6]}
compiler.fallback-append macports-gcc-4.9 macports-gcc-4.8
macports-gcc-4.7
} else {
# using libc++;
# Blacklist Clang not supporting C++11 in some form and all GCC.
compiler.blacklist-append *gcc* {clang  500}
}
}}}

This seems to work for me, without using variants; at least on 10.8.
I'll test on 10.10 shortly. I don't see it as having C++ runtime library
issues, since it maintains correct usage of either libc++ or libstdc++.
- MLD
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[René J . V . Bertin]

On Thursday March 19 2015 14:06:21 Lawrence Velázquez wrote:

 On newer OS X versions where libc++ is the default (or only) C++ runtime.
 
 Exactly. If we key off of {${configure.cxx_stdlib} eq libstdc++}, then
 I think this can be made to work; er, mostly.

I believe this is only safe if you're absolutely sure that all the C++ objects 
your code uses or links with uses MacPorts' libstdc++ / libsupc++.
 You may be right, but I think we can be quite sure that with Qt4 having been 
built with Apple's gcc-4.2, those KDE ports I built with g++-mp-4.8 were rather 
... metrosexual :)
Unless MacPorts tweaks the environment and commandline arguments sufficiently 
to guarantee that the link editor finds the MacPorts libstdc++ first (which 
still wouldn't explain how binaries would get at the Apple-specific stuff in 
Apple's libstdc++)?

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[Chris Jones]

Hi,

The bottom line is there is no clean way of supporting C++11 on 10.8 or 
older. Its can only be done on a best try basis.


Using gcc is a bad idea, this can lead to C++ runtime issues.

In the root6 port we use

# Force a compatible compiler
compiler.blacklist-append *gcc* {clang  500} macports-clang-2.9 
macports-clang-3.0 macports-clang-3.1 macports-clang-3.2

compiler.fallback-append macports-clang-3.4 macports-clang-3.5

Which means newer systems use the compatible system clang compiler, and 
older system use the macports clang compiler. I think this is the 'best 
effort' solution. It doesn't work on OSX10.6 though, there we simply 
given up support, as least with the root6 port.


Chris

On 19/03/15 16:04, Michael Dickens wrote:

I have a few ports that have recently moved to requiring c++11 (or,
maybe, c++0x), and a few to-be-submitted ports that do too, so I'm
wondering if there's a standard way to specify this requirement -- for
example, something like:
{{{
PortGroup   compilers 1.0
compilers.setup  require_cxx11
}}}
and, then port does the right thing by selecting the compiler and
cxxflags no matter the OS.

I did a quick search through the dports tree, and couldn't come up with
a single standard way to do this. The closest I found was something
like:
{{{
 PortGroup compiler_blacklist_versions 1.0
 compiler.blacklist-append *gcc-4.0 *gcc-4.2 {clang  300}
}}}
but, the above does not work on my 10.8 install.


From what I can gather via testing on my 10.8 install, the clang ports

support -std=c++11 only when -stdlib=libc++ -- which is not the
default in MacPorts for 10.8 and prior. I haven't tried moving my ports
install to using libc++, instead leaving it with the default. Hence, it
looks like I'm stuck using GCC.

GCC 4.7+ do provide full support for -std=c++11, and it looks like GCC
4.[56] provide support for -std=c++0x (but, that's old enough now that
I think I can just limit support to actual c++11).

Anyway, wondering how others have provided c++11 support to the variety
of OSs MacPorts supports. Thanks! - MLD
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[René J . V . Bertin]

On Thursday March 19 2015 17:01:02 Chris Jones wrote:

 Using gcc is a bad idea, this can lead to C++ runtime issues.

On newer OS X versions where libc++ is the default (or only) C++ runtime.

 Which means newer systems use the compatible system clang compiler, and 
 older system use the macports clang compiler. I think this is the 'best 
 effort' solution. It doesn't work on OSX10.6 though, there we simply 
 given up support, as least with the root6 port.

I don't see what's against using port:gcc4x on 10.6 or 10.7 as long as you 
don't need Apple-specific compiler extensions (probably including universal 
builds). It's how I built relatively complex ports like kdevplatform and 
kdevelop, without any issues. Oh, and (favourite topic of mine), it's also a 
lot faster than the clang ports O:-)
I've never managed to use the blacklisting feature to force port to use 
g++-mp-4.{7,8,9}, though.

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[Lawrence Velázquez]

On Mar 19, 2015, at 1:56 PM, Michael Dickens michae...@macports.org wrote:

 On Thu, Mar 19, 2015, at 01:54 PM, René J.V. Bertin wrote:
 On Thursday March 19 2015 17:01:02 Chris Jones wrote:
 
 Using gcc is a bad idea, this can lead to C++ runtime issues.
 
 On newer OS X versions where libc++ is the default (or only) C++ runtime.
 
 Exactly. If we key off of {${configure.cxx_stdlib} eq libstdc++}, then
 I think this can be made to work; er, mostly.

I believe this is only safe if you're absolutely sure that all the C++ objects 
your code uses or links with uses MacPorts' libstdc++ / libsupc++.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: standard way to require c++11?

[Michael Dickens]

On Thu, Mar 19, 2015, at 02:06 PM, Lawrence Velázquez wrote:
 On Mar 19, 2015, at 1:56 PM, Michael Dickens michae...@macports.org
 wrote:
  Exactly. If we key off of {${configure.cxx_stdlib} eq libstdc++}, then
  I think this can be made to work; er, mostly.
 
 I believe this is only safe if you're absolutely sure that all the C++
 objects your code uses or links with uses MacPorts' libstdc++ /
 libc++.

I know it is possible to select configure.stdlib on a per-port basis ...
but, it's certainly not wise in general  how many folks or ports really
-try- to do this? I know it fails for me (on 10.8 and 10.10:
cross-linking libc++ and libstdc++ from Apple and MacPorts) way more
often than it works, so I just don't do it. I don't really see this as a
major issue, given how well it doesn't work. - MLD
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev