On Sep 11, 2013, at 23:00, Jeremy Huddleston Sequoia
wrote:
>
> On Sep 11, 2013, at 22:45, Lawrence Velázquez wrote:
>
>> If you do choose to switch to libc++ and rebuild all your ports, keep in
>> mind that a successful build does not necessarily mean a successful build
>> against libc++.
On Sep 11, 2013, at 22:45, Lawrence Velázquez wrote:
> If you do choose to switch to libc++ and rebuild all your ports, keep in mind
> that a successful build does not necessarily mean a successful build against
> libc++. A misbehaving port might quietly link against libstdc++ behind your
> b
On Sep 12, 2013, at 12:11 AM, Jeremy Huddleston Sequoia
wrote:
> On Sep 11, 2013, at 18:47, Eric A. Borisch wrote:
>
>> As mentioned elsewhere in this email chain, it's not intended to be a
>> supported switch for users, it's a tool to help developers with
>> transitioning to a future where
On Sep 11, 2013, at 16:01, Ted Kord wrote:
> :info:build "_environ", referenced from:
> :info:build _CPLSpawnAsync in cpl_spawn.o
> :info:build _CPLSpawnAsync in cpl_spawn.o
>
I will commit a fix shortly
https://trac.macports.org/ticket/40334
_
On Sep 11, 2013, at 18:47, Eric A. Borisch wrote:
> On Wednesday, September 11, 2013, William Gallafent wrote:
> Hi Eric,
>
> On 11 September 2013 17:05, Eric A. Borisch wrote:
> > It's being worked on. If you run off of trunk, you can try it out:
> > https://lists.macosforge.org/pipermail/mac
On Sep 11, 2013, at 8:17, William Gallafent wrote:
> On 11 September 2013 16:07, Jakub Sochor wrote:
>> So I would like to compile these packages with libc++ support. And probably
>> it will be required to build with this support also their dependences.
>
> Apologies for the “me too”, but me
On Wednesday, September 11, 2013, William Gallafent wrote:
> Hi Eric,
>
> On 11 September 2013 17:05, Eric A. Borisch
> >
> wrote:
> > It's being worked on. If you run off of trunk, you can try it out:
> >
> https://lists.macosforge.org/pipermail/macports-dev/2013-August/024161.html
>
> Excellent
On Wed, Sep 11, 2013 at 4:57 AM, Jakub Sochor wrote:
> Hello,
>
> i have a question about the c++11 support.
> Is in MacPorts some configuration that will force use all c++ sources to
> be compiled by host clang with flags '-std=c++11 -stdlib=libc++'.
> I tried configure.cxxflags but that had no
On 11 September 2013 16:07, Jakub Sochor wrote:
> So I would like to compile these packages with libc++ support. And probably
> it will be required to build with this support also their dependences.
Apologies for the “me too”, but me too :)
As Lawrence has said, there doesn't appear to be a sta
Hi Eric,
On 11 September 2013 17:05, Eric A. Borisch wrote:
> It's being worked on. If you run off of trunk, you can try it out:
> https://lists.macosforge.org/pipermail/macports-dev/2013-August/024161.html
Excellent! I notice that this allows one to set which runtime to use
(e.g. -stdlib=libstd
I would like to use c++11 features from libc++ mainly the smart pointers. Not
using them is not option for me, because I have to adopt a library where the
smart pointers are already used.
So I have to compile my program with -stdlib=libc++. However if the OpenCV and
Boost is not compiled also
Hi
Uprading the ports fails at gdal with the error:
---> Fetching distfiles for gdal
---> Verifying checksums for gdal
---> Extracting gdal
---> Applying patches to gdal
---> Configuring gdal
---> Building gdal
Error: org.macports.build for port gdal returned: command execution failed
The
On Sep 11, 2013, at 5:57 AM, Jakub Sochor wrote:
> i have a question about the c++11 support.
> Is in MacPorts some configuration that will force use all c++ sources to be
> compiled by host clang with flags '-std=c++11 -stdlib=libc++'.
> I tried configure.cxxflags but that had no effect in Ope
On Sep 11, 2013, at 6:22 AM, Tabitha McNerney wrote:
> What's preventing Apple from having a third party independent audit of their
> developer tools (which MacPorts depends on, and the rest of the world also
> depends on for a wide range of apps either for OS X or iOS)? Seriously, how
> hard
On 11 September 2013 22:54, Lawrence Velázquez wrote:
> The cxx_stdlib option is intended to aid port developers in migrating C++
> ports to libc++, which is currently a priority due to issues mixing STL
> implementations (libstdc++ vs. libc++) and ABIs (libsupc++ vs. libc++abi), as
> well as t
On Sep 11, 2013, at 5:13 PM, William Gallafent wrote:
> On 11 September 2013 17:05, Eric A. Borisch wrote:
>> It's being worked on. If you run off of trunk, you can try it out:
>> https://lists.macosforge.org/pipermail/macports-dev/2013-August/024161.html
>
> Excellent! I notice that this allo
On Sep 11, 2013, at 8:18 AM, Lawrence Velázquez wrote:
> On Sep 11, 2013, at 6:22 AM, Tabitha McNerney wrote:
>
>> What's preventing Apple from having a third party independent audit of their
>> developer tools (which MacPorts depends on, and the rest of the world also
>> depends on for a wi
On 11/09/2013, at 8:22 PM, Tabitha McNerney wrote:
> I have been doing some more research and spoke with some people in the
> industry about certified compilers. Apparently a lot of progress has been
> made in the recent past and money has been flowing into the arena of
> certified compilers. W
As someone else pointed out, why worty about the compiler? The OS is the very
first thing you need to worry about.
And how do you know that those certifying are not ordered to secrecy and
overlook nsa backdoors? ;)
Dom
> Am 11.09.2013 um 12:22 schrieb Tabitha McNerney :
>
> Ian and all,
>
> I
Ian and all,
I have been doing some more research and spoke with some people in the
industry about certified compilers. Apparently a lot of progress has been
made in the recent past and money has been flowing into the arena of
certified compilers. What's preventing Apple from having a third party
Hello,
i have a question about the c++11 support.
Is in MacPorts some configuration that will force use all c++ sources to be
compiled by host clang with flags '-std=c++11 -stdlib=libc++'.
I tried configure.cxxflags but that had no effect in OpenCV for example.
Can you please give me some poin
On Sep 11, 2013, at 02:24, Degang Wu wrote:
> :info:build TclInterp.m:271: error: 'Tcl_Interp' has no member named 'result'
This is one of the errors you see when a program written for older Tcl (< 8.6 I
think) is used with newer Tcl (≥ 8.6 I think). Tcl_Interp became an opaque
structure that
Hi,
Mountain Lion 10.8.4.
The most relevant part of the log:
:info:build libtool: compile: /usr/bin/llvm-gcc-4.2 -DHAVE_CONFIG_H -I.
-I../.. -I../../libobjc -I../../libobjc -I./../misc -I.. -I./.. -I./../defobj
-I/opt/local/include -I/opt/local/include -I/usr/include/ffi
-I/opt/local/include
23 matches
Mail list logo
