In article 69d2e4c6-38df-4a86-a650-856ac9dac...@macports.org,
Ryan Schmidt ryandes...@macports.org wrote:
On Dec 4, 2013, at 20:16, Joshua Root wrote:
And there are machines with 64-bit processors but 32-bit EFI that can't
go past 10.7.
Which machines are you thinking of?
The system
Am 04.12.2013 01:24, schrieb Christopher Jones:
Hi,
This is more what I was thinking for this case. Have the port use a newer c++11
enabled version on OSX versions that support it, and a older version where they
don’t.
Hi,
maybe I got lost in this thread but I think multiple issues
get
Hi,
- The only C++ runtime that Apple provides on all systems since 10.5(?)
is the one delivered with gcc 4.2.1. I really doubt that Apple
will change that to a recent libc++
You are wrong on this point. Apple have been abandoning gcc in favour of
clang/LLVM over the last few OSX
On Wed, Dec 04, 2013 at 10:00:48AM +, Chris Jones wrote:
In fact, its the only C++ runtime in 10.9.
That's incorrect. 10.9 still has the same libstdc++ runtime that
previous versions of OS X had. In fact, you can still use the old
runtime (and some of our ports do, because they fail with
Hi,
On Wed, Dec 04, 2013 at 10:52:28AM +0100, Titus von Boxberg wrote:
maybe I got lost in this thread but I think multiple issues get mixed
up.
Yes, I think some things are getting mixed up here, but only because we
cannot handle them separately. The available C++ runtimes are in fact
Am 04.12.2013 11:00, schrieb Chris Jones:
Hi,
On OSX Macports explicitly links using the libc++ runtime, where as on
older releases it
This is exactly why c++11 code is fine on OSX10.9, as the default
compiler libc++ used there supports it, but not on older OSC releases.
This is why the c++
On Wed, Dec 04, 2013 at 12:48:13PM +0100, Titus von Boxberg wrote:
libc++ is available since 10.7. clang is available from Apple way
before Xcode 5.
It's just that the libc++ of 10.9 and clang of Xcode 5 are the first
versions by Apple that have had a chance to use the clang/libc++ that
has
On 04/12/13 11:48, Titus von Boxberg wrote:
Am 04.12.2013 11:00, schrieb Chris Jones:
Hi,
On OSX Macports explicitly links using the libc++ runtime, where as on
older releases it
This is exactly why c++11 code is fine on OSX10.9, as the default
compiler libc++ used there supports it, but not
On Dec 4, 2013, at 05:29, Clemens Lang wrote:
Obviously C++11 support is a problem we're going to face sooner or
later. It is a problem now and I don't think just avoiding C++11 on
older systems is going to cut it.
I’m not entirely opposed to that actually. There are already many ports that
Hi,
On 04/12/13 12:01, Ryan Schmidt wrote:
On Dec 4, 2013, at 05:29, Clemens Lang wrote:
Obviously C++11 support is a problem we're going to face sooner or
later. It is a problem now and I don't think just avoiding C++11 on
older systems is going to cut it.
I’m not entirely opposed to that
On Dec 4, 2013, at 06:11, Chris Jones wrote:
10.6 is perhaps slightly different in that it is the last release to support
PowerPC applications. Maybe some users have a need to stick with this because
of that (but then, any application that *still* hasn't provided an intel
version now,
Hi Clemens, all,
you dropped the last text block from my mail where I said
that I think that macports shouldn't care much
about users using macports libraries for their own software.
This is why also in your mail quoted below in my opinion these
things get mixed up: you mix up users of macports
Hi,
you dropped the last text block from my mail where I said
that I think that macports shouldn't care much
about users using macports libraries for their own software.
I very much disagree here. MacPorts is *not* just about providing a
bunch of applications for users to run, but also about
On Wed, Dec 04, 2013 at 02:52:02PM +0100, Titus von Boxberg wrote:
you dropped the last text block from my mail where I said that I think
that macports shouldn't care much about users using macports libraries
for their own software.
This is why also in your mail quoted below in my opinion
Boxberg ti...@v9g.de
Cc: macports-dev@lists.macosforge.org
Subject: Re: C++11 on Mountain Lion and lower?
Hi,
you dropped the last text block from my mail where I said
that I think that macports shouldn't care much
about users using macports libraries for their own software.
I very much disagree
On Dec 4, 2013, at 08:46, Clemens Lang wrote:
Consider a developer who wants C++11 support on 10.8. He might find out
that he can use libc++ (from MacPorts or from the host) and clang. Then
he tries to use boost, tries to use the MacPorts version and experiences
weird crashes, because
Am 04.12.2013 15:46, schrieb Clemens Lang:
They are lost if they need to link against a C++ library, e.g. boost
compiled against a runtime that supports C++11. And these libraries are
probably the reason they were trying to use MacPorts in the first place.
Consider a developer who wants C++11
In article 529f1c08.4000...@hep.phy.cam.ac.uk,
Chris Jones jon...@hep.phy.cam.ac.uk
wrote:
10.6 is perhaps slightly different in that it is the last release to
support PowerPC applications. Maybe some users have a need to stick with
this because of that (but then, any application that
Hi,
On 4 Dec 2013, at 09:14 pm, Ned Deily n...@acm.org wrote:
In article 529f1c08.4000...@hep.phy.cam.ac.uk,
Chris Jones jon...@hep.phy.cam.ac.uk
wrote:
10.6 is perhaps slightly different in that it is the last release to
support PowerPC applications. Maybe some users have a need to
On Wed, Dec 04, 2013 at 03:46:49PM +0100, Clemens Lang wrote:
Of the system libraries in /usr/lib/system, only a single one exports
C++ symbols (and that seems to be related to kernel extension stuff).
I haven't checked for the libraries in /usr/lib, but I'll try to come
up with a shell script
Hi,
On 5 Dec 2013, at 12:22 am, Clemens Lang c...@macports.org wrote:
On Wed, Dec 04, 2013 at 03:46:49PM +0100, Clemens Lang wrote:
Of the system libraries in /usr/lib/system, only a single one exports
C++ symbols (and that seems to be related to kernel extension stuff).
I haven't checked
On 2013-12-5 08:14 , Ned Deily wrote:
In article 529f1c08.4000...@hep.phy.cam.ac.uk,
Chris Jones jon...@hep.phy.cam.ac.uk
wrote:
10.6 is perhaps slightly different in that it is the last release to
support PowerPC applications. Maybe some users have a need to stick with
this because of
On 2013-12-5 11:22 , Clemens Lang wrote:
- libcupsppdc.1.dylib (what is this anyway?)
Something to do with the CUPS ppd compiler I would say.
- libmecab.1.0.0.dylib (only a few symbols, what is this?)
Looks like some version of what's provided by the mecab-base port.
- Josh
On Dec 4, 2013, at 20:16, Joshua Root wrote:
And there are machines with 64-bit processors but 32-bit EFI that can't
go past 10.7.
Which machines are you thinking of?
The system requirements of Mavericks are pretty liberal:
http://support.apple.com/kb/ht5842
For example, the mid-2007
On Dec 4, 2013, at 18:32, Chris Jones wrote:
I guess a version of libc++ from MacPorts would have the advantage it would
allow the use of a complete c++11 implementation on systems where the host
version is lacking.
Do we know which host versions are lacking?
Could this be done by just
Hi,
does anybody know how I can compile C++11 code on Mountain Lion and
lower without using libc++?
The problem I face is that rethinkdb uses std::move (and probably other
features) from C++11. To do this, it checks for the clang compiler and
passes -stdlib=libc++ in CXXFLAGS if it detects clang
Hi,
I am not an expert, but based on the discussion in
https://trac.macports.org/ticket/39975
my understanding is there is no easy way to enable c++11 on systems
older than 10.9 using the current MacPorts release. You need to use the
libc++ runtime by default everywhere, not, libstdc++, and
On Tue, Dec 03, 2013 at 03:09:10PM +0100, Clemens Lang wrote:
does anybody know how I can compile C++11 code on Mountain Lion and
lower without using libc++?
The problem I face is that rethinkdb uses std::move (and probably other
features) from C++11. To do this, it checks for the clang
Hi,
To follow up: the ML buildbot just succeeded building rethinkdb using
FSF GCC 4.8 (obviously using MacPorts libstdc++). I guess the binaries
will now use both
- /opt/local/lib/libstdc++.dylib and
- /usr/lib/libstdc++.dylib,
but I suppose that will cause a lot less problems than mixing
On Tue, Dec 03, 2013 at 05:00:25PM +, Christopher Jones wrote:
Is this really a good idea though. My recollection is, whilst not as
bad as mixing libc++ and libstdc++ runtimes, mixing the two different
libstd++ runtimes can still lead to problems…. ?
Under the constraints we have I think
What about using the libcxx and libcxxabi ports for libc++? Is there any
way to make that work?
On Tue, Dec 3, 2013 at 1:38 PM, Clemens Lang c...@macports.org wrote:
On Tue, Dec 03, 2013 at 05:00:25PM +, Christopher Jones wrote:
Is this really a good idea though. My recollection is,
Hi,
Under the constraints we have I think its the best solution possible.
Alternatives would be
- Mark the port as broken on systems darwin13 :(
- Build a private copy of all dependencies of rethinkdb against
macports libstdc++. Since that includes boost and a couple of other
rather
On Tue, Dec 03, 2013 at 01:59:35PM -0500, Eric Gallager wrote:
What about using the libcxx and libcxxabi ports for libc++? Is there
any way to make that work?
Only if we rebuilt all ports against libcxx/libcxxabi. We could do that,
but we could also just rebuild everything against the host
On Tue, Dec 03, 2013 at 07:48:48PM +, Christopher Jones wrote:
For that last one, it is not necessary to have Apple make that
decision. macPorts could decide to release the current trunk, and
force the use of libc++ on systems older than OSX10.9. This of course
would force all users to
Hi,
On 3 Dec 2013, at 8:13pm, Clemens Lang c...@macports.org wrote:
On Tue, Dec 03, 2013 at 07:48:48PM +, Christopher Jones wrote:
For that last one, it is not necessary to have Apple make that
decision. macPorts could decide to release the current trunk, and
force the use of libc++ on
On Dec 3, 2013, at 13:48, Christopher Jones wrote:
For that last one, it is not necessary to have Apple make that decision.
macPorts could decide to release the current trunk, and force the use of
libc++ on systems older than OSX10.9. This of course would force all users to
recompile all
Hi,
On 3 Dec 2013, at 9:55pm, Ryan Schmidt ryandes...@macports.org wrote:
On Dec 3, 2013, at 13:48, Christopher Jones wrote:
For that last one, it is not necessary to have Apple make that decision.
macPorts could decide to release the current trunk, and force the use of
libc++ on
On Tue, Dec 03, 2013 at 03:55:08PM -0600, Ryan Schmidt wrote:
First we would need to write more code in base that could identify
when ports are installed with a different C++ runtime than that
selected in macports.conf, and rebuild those ports. Users will not
know they need to rebuild ports
On Dec 3, 2013, at 16:23, Christopher Jones wrote:
Part of the problem, for me, is MacPorts insists on all OSX versions using
the same set of port versions. There is no way, I think, of having different
versions on different OSX releases. Note this is quite different to say the
Linux
Hi,
On 3 Dec 2013, at 11:43pm, Ryan Schmidt ryandes...@macports.org wrote:
On Dec 3, 2013, at 16:23, Christopher Jones wrote:
Part of the problem, for me, is MacPorts insists on all OSX versions using
the same set of port versions. There is no way, I think, of having different
versions
40 matches
Mail list logo
