Does clang support the use of _GLIBCXX_USE_CXX11_ABI ? If it does,
only in very recent releases.
https://llvm.org/bugs/show_bug.cgi?id=23529
But, OK. As long as the proposal is only for siutations where no other
solution is practical, and is not done by default and only when the user
requ
It's growing on me.
This will be quite useful on 10.4 and 10.5 PPC, where it's the only
way forward, for gtk3 for example.
I noticed this method enables thread-local storage on 10.6, which
until now was not available (at least I didnt' figure it out).
There is a flag to compile libgcc so it defa
> On Jan 19, 2017, at 2:04 PM, Chris Jones wrote:
>
> I don't think we should, under any circumstances, but making the use of gcc
> to build c++ ports a standard practise.
Just to be clear, the proposal is not to use gcc but to use clang with
libstdc++ and *only* on systems where it has been
Hi,
For me, the better approach is to
1. On systems where the default system compiler is clang and thus uses libc++,
when neccessary (such as c++14, 17, support, which over time will become
as much of an issues as c++11) use one of the macports clang compilers that
works on that platform
I do not know if this helps with your concerns or not, but in the current
proposal, _GLIBCXX_USE_CXX11_ABI is only set to 0 for
macOS prior to Mavericks, where libstdc++ is the default.
So _GLIBCXX_USE_CXX11_ABI is being used as it was intended, as a mechanism to
facilitate transition.
-Marcus
Hi,
See
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
For the details.
Set the ABI controls whether or not you compile using the new c++11 standards
compliant implementations of string and list. If you set the ABI back to 0 then
yes, you can then mix different std libs.
On 2017-01-17, at 7:43 PM, Marcus Calhoun-Lopez wrote:
> I think perhaps I am not being clear in what I am proposing.
I think it was me that was just missing something --
Basically, rather than think about it as which c++ standard library the file is
built against, think about it as which c++
> On 18 Jan 2017, at 4:15 pm, Mojca Miklavec wrote:
>
>> On 18 January 2017 at 04:43, Marcus Calhoun-Lopez wrote:
>> I think perhaps I am not being clear in what I am proposing.
>>
>> Currently, if cxx_stdlib is equal to libstdc++ then the cxx11PortGroup
>> returns an error and the port does
On 18 January 2017 at 04:43, Marcus Calhoun-Lopez wrote:
> I think perhaps I am not being clear in what I am proposing.
>
> Currently, if cxx_stdlib is equal to libstdc++ then the cxx11PortGroup
> returns an error and the port does not build.
> I am simply proposing that instead of returning an er
On 17 January 2017 at 21:08, Ken Cunningham wrote:
> Re: 10.5 Intel - for me, that platform is just a vehicle to 10.5 PPC.
> I use it for cross compiling for 10.5 PPC. All these intel machines
> can be upgraded to at least 10.7 (10.6 if you want Rosetta).
I'm sorry, I meant 10.5 PPC of course.
Th
What you propose is what I'm doing in various GNU Radio ports, e.g.,
gr-ieee802-11. If ${configure.cxx_stdlib} is "libstdc++, then default to
some MacPorts provided GCC (right now, 4.9 ... I need to update these to
gcc6); else use the cxx11 PortGroup. It's not the best solution, but it
works well e
On 2017-01-16 21:03, Ken Cunningham wrote:
> Rather than force the older systems to install gcc6 and libgcc and
> then find a roundabout and complicated way to support cxx11 with c++
> standard library inconsistencies, I would suggest we finally just
> change/add/modify/get the buildbots to libc++
I think perhaps I am not being clear in what I am proposing.
Currently, if cxx_stdlib is equal to libstdc++ then the cxx11PortGroup returns
an error and the port does not build.
I am simply proposing that instead of returning an error, the port build
instead.
In other words, the change is meant
Well, the entire c++ library on the buildbot would have to be rebuilt
against libgcc's libstdc++ for this to work -- all of octave's deps
and deps of deps would need to be built the same as octave, of course,
and so everything else too. The whole machine has to be configured the
same way (which is
> On Jan 17, 2017, at 1:08 PM, Ken Cunningham
> wrote:
>
> Anyway, point of all this is that I'm extremely impressed with the way
> the macports devs and Jeremy have enabled libc++ / modern llvm-clang
> on 10.6 and 10.7, and would hate to see us move very far away from
> that or overly confuse
Re: 10.5 Intel - for me, that platform is just a vehicle to 10.5 PPC.
I use it for cross compiling for 10.5 PPC. All these intel machines
can be upgraded to at least 10.7 (10.6 if you want Rosetta). Snow
Leopard DVDs on eBay are $15 if you don't have one (I have six or so
from various Apple Dev and
On 16 January 2017 at 21:03, Ken Cunningham wrote:
> Octave builds and runs great on older systems right now when they are
> upgraded to libc++ per the current instructions.
Except on 10.5, I guess?
Mojca
> Apple's lawyers don't think so, so you cannot redistribute anything combining
> Apple libraries with it. (Since you can't avoid libSystem, this means you
> cannot redistribute binaries.)
>
> It's not a question of what makes sense to you, it's not a question of what
> would be convenient. Ap
Octave builds and runs great on older systems right now when they are
upgraded to libc++ per the current instructions.
$ port -v installed octave
The following ports are currently installed:
octave @4.2.0_1+accelerate+app+docs+fltk+gfortran+graphicsmagick+qt4+sound
platform='darwin 10' archs='x8
On Mon, Jan 16, 2017 at 1:48 PM, Marcus Calhoun-Lopez wrote:
>
> > gcc 5.1 libstdc++ is GPL3 and poses significant license issues with
> respect to distributing binaries, among others.
> Again, there may be something important I am missing, but isn’t there a
> GCC runtime library exceptions that
> The *only* time you should use a libstdc++ different from the system-provided
> one (or ones, on 10.7) is the current LibcxxOnOlderSystems --- which
> explicitly loses compatibility with all Apple-provided C++ libraries
Please forgive my ignorance, but doesn’t setting _GLIBCXX_USE_CXX11_ABI=0
On Mon, Jan 16, 2017 at 1:21 PM, Marcus Calhoun-Lopez wrote:
> At the risk of rehashing a closed topic, I would like to propose a new way
> of handling C++11 (especially on older systems).
> I have opened three tickets that I hope, together, would solve some of the
> issues raise
At the risk of rehashing a closed topic, I would like to propose a new way of
handling C++11 (especially on older systems).
I have opened three tickets that I hope, together, would solve some of the
issues raised previously.
[1] https://trac.macports.org/ticket/53194
[2] https
23 matches
Mail list logo
