clang: have -stdlib=libstdc++ refer to MacPorts libstdc++

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

I know libstdc++ vs. libc++ has been discusses extensively on the mailing list, but I do not 100% understand all of it.
Please forgive me if I am missing some important aspect with this proposal.
For my own projects, having -stdlib=libstdc++ refer to the MacPorts libstdc++ would (hopefully) solve a few problems.
Attached is a proposal based on ​this.

[jeremyhu (Jeremy Huddleston Sequoia)]

The goal with the clang toolchains (as opposed to gcc toolchains) is to be as compatible with the host as possible. As such, I don't intend to have -stdlib=libstdc++ refer to the MacPorts-provided libstdc++.

I would be willing to do something like -stdlib=macports-libstdc++ What do you think about that?

[kencu (Ken)]

or, as Jeremy suggested a few months back, comment:ticket:52468:45, use the moniker macports-libstdc++ to refer to the one from libgcc, use libstdc++ for the system's built-in one, and use libc++ for the system's libc++ and for the one provided by the libcxx.

And I see Jeremy is replying as well as I'm typing this :> So yes, that would work, I think.

[jeremyhu (Jeremy Huddleston Sequoia)]

Note that if that's non-trivial, we could do it your way (with a variant), but let's have it add the dependency on libgcc.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to jeremyhu:

The goal with the clang toolchains (as opposed to gcc toolchains) is to be as compatible with the host as possible. As such, I don't intend to have -stdlib=libstdc++ refer to the MacPorts-provided libstdc++.

I would be willing to do something like -stdlib=macports-libstdc++ What do you think about that?

That would certainly work for what I need.
I would submit a patch, but I have no idea how to do this.

Replying to jeremyhu:

Note that if that's non-trivial, we could do it your way (with a variant), but let's have it add the dependency on libgcc.

That sounds reasonable as well.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

There are now two proposals.

1. -stdlib=libstdc++ refers to MacPorts libstdc++ if variant if selected
2. -stdlib=macports-libstdc++ refers to MacPorts libstdc++ if variant is selected

For my needs, it makes no difference.
I am new to clang/llvm code, so any feedback would be appreciated.

[kencu (Ken)]

There is a lot of info on this topic here <​https://llvm.org/bugs/show_bug.cgi?id=23529>.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

May I apply one of these patches?
If so, which one is preferred?
Whichever patch is applied, are there any objections to making the new variant a default?

[jeremyhu (Jeremy Huddleston Sequoia)]

Approach #2 looks fine. Go ahead and push it to llvm-devel but don't make the variant default. Let's solicit feedback from macports-dev, and if folks find it useful, we should bring it back into llvm-3.9 as well.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In c68d69b8/macports-ports:

clang-devel: allow clang to use MacPorts libstdc++

See #53194

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

If I understand the ​conversation on the mailing list, there may be a grudging willingness to try #53330.
#53330, however, depends on this proposed variant being accepted and the default.
Any thoughts on the likelihood of this being accepted?

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Sorry to keep pestering about this.
If this patch is not to be accepted or the variant can not be made the default, would anyone mind if I created a subport of clang?

[jeremyhu (Jeremy Huddleston Sequoia)]

What do you mean by "If this patch is not to be accepted"? I previously said, "Approach #2 looks fine. Go ahead and push it to llvm-devel but don't make the variant default. Let's solicit feedback from macports-dev, and if folks find it useful, we should bring it back into llvm-3.9 as well."

If it turns out to not be too offensive to folks, we can flip it to being default. We won't know that until after you push the change and let it brew.

[jeremyhu (Jeremy Huddleston Sequoia)]

Oh, it's actually already in. I missed that. So why is this ticket still open?

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to jeremyhu:

What do you mean by "If this patch is not to be accepted"?

I simply meant that if the maintainers of clang do not want to maintain this particular patch, creating a ​subport compiler that was my responsibility would also work.
I do not want to presume to create more work for others.

I previously said, "Approach #2 looks fine. Go ahead and push it to llvm-devel but don't make the variant default.

As you noted, that happened ​a couple of weeks ago.
Through inertia, it was also copied into ​clang-4.9.

Let's solicit feedback from macports-dev, and if folks find it useful, we should bring it back into llvm-3.9 as well." If it turns out to not be too offensive to folks, we can flip it to being default. We won't know that until after you push the change and let it brew.

As I mentioned ​earlier, there was a ​discussion about the whole proposal a couple of weeks ago.

Replying to jeremyhu:

Oh, it's actually already in. I missed that. So why is this ticket still open?

Unfortunately, for my purposes (#53330), the variant must be default (​Portfile1.diff, or ​Portfile.2.diff) or a subport must be created (​Portfile.3.diff).
As llvm is not openmaintainer, I have been hesitant to make changes of this magnitude without explicit permission.

[jeremyhu (Jeremy Huddleston Sequoia)]

Oh, I'm perfectly happy maintaining this patch as part of clang-3.9+.

Unfortunately, for my purposes (#53330), the variant must be default

Ok. Let's make it default then on clang-4.0 and clang-devel. If there's not much resistance, we can remove it as a variant entirely in the future. Sound good?

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In 91a4e1bd/macports-ports:

llvm-{4.0,devel}: make variant libstdcxx default

See #53194

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In a83b4a2e/macports-ports:

llvm-3.9: allow clang to use MacPorts libstdc++

See #53194

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to jeremyhu:

Oh, I'm perfectly happy maintaining this patch as part of clang-3.9+.

Unfortunately, for my purposes (#53330), the variant must be default

Ok. Let's make it default then on clang-4.0 and clang-devel. If there's not much resistance, we can remove it as a variant entirely in the future. Sound good?

Thank you for the help.

[mojca (Mojca Miklavec)]

See also #53634.