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,
when trying to set up a new port I ran into a strange thing with cmake:
---
:info:configure -- Configuring done
:info:configure CMake Error: The inter-target dependency graph contains the
following strongly connected component (cycle):
:info:configure server of type SHARED_LIBRARY
On Dec 3, 2013, at 16:16, mk-macpo...@techno.ms wrote:
when trying to set up a new port I ran into a strange thing with cmake:
---
:info:configure -- Configuring done
:info:configure CMake Error: The inter-target dependency graph contains the
following strongly connected component (cycle):
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
On Nov 29, 2013, at 05:40, Peter Danecek peter.dane...@bo.ingv.it wrote:
On Nov 29, 2013, at 9:06 , Ryan Schmidt ryandes...@macports.org wrote:
+# testing only
+depends_run-append port:py${python.version}-nose \
+port:py${python.version}-pep8 \
+
18 matches
Mail list logo
