[C++11 conversation moved to macports-dev. You can all relax now.]
vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
On Sun, Sep 7, 2014 at 12:52 AM, Ryan Schmidt wrote:
> On Sep 6, 2014, at 5:51 AM, Mojca Miklavec wrote:
>
>> I already argued that we really need a libc++-based buildbot for 10.6-10.8.
>>
>> From what I understood all we need is a fix in binary package
>> signature + time and resources to set up t
On Sun, Sep 7, 2014 at 8:36 PM, Lawrence Velázquez wrote:
>
> All this talk about keeping track of C++ runtimes and switching to libc++ is
> dangerous because it proposes a huge amount of work that deftly dances around
> the actual problem.
It's not a huge amount of work. It already works. The q
On Sep 7, 2014, at 4:11 AM, René J.V. Bertin wrote:
> Debian's package generation system is very intricate and can keep track of
> ABI changes in shared libraries (exported symbols, really) so I'd not be
> amazed if it could also keep track of dependencies on C++ runtimes and the
> like. (Just
On Sat, Sep 6, 2014 at 6:52 PM, Ryan Schmidt
wrote:
> Do we already record the C++ runtime in the registry with each installed
> port? If not, we should do that, in addition to getting it into the binary
> filenames. And just as we do for architectures, maybe we should have an
> indication for so
On Sep 6, 2014, at 4:18 AM, René J.V. Bertin wrote:
> On Friday September 05 2014 22:41:42 Lawrence Velázquez wrote:
>
>> Judging from your comments, your crashes are probably caused because you're
>> mixing up C++ runtime libraries. Binaries compiled with MacPorts' gcc48 use
>> libgcc's libra
On Sep 6, 2014, at 5:51 AM, Mojca Miklavec wrote:
> I already argued that we really need a libc++-based buildbot for 10.6-10.8.
>
> From what I understood all we need is a fix in binary package
> signature + time and resources to set up the buildbots. Once the
> buildbots run, people can start t
On Sep 6, 2014, at 7:15 AM, René J.V. Bertin wrote:
>
> If moving to libc++ also aids upgrading MacPorts after upgrading the OS, that
> just gives an additional reason ...
I don't see why it would do anything like that. Upgrading the OS to a new major
version always requires reinstalling MacP
On Sep 6, 2014, at 3:12 PM, René J.V. Bertin wrote:
> Who decides whether or not a universal variant binary port is made available
> via the buildbots? O:-)
If a port depends on a universal port, then that dependency will be built
universal on the buildbot and provided as a binary package, lic
On Saturday September 06 2014 13:10:40 Lawrence Velázquez wrote:
> > Hacking alert:
> > Par of me now wonders if I couldn't "simply" replace the system runtime(s)
> > with the current MacPorts one(s) (C++ and/or libgcc_s). I suppose that has
> > been tried?
>
> I do not know if anyone has tried
On Sep 6, 2014, at 1:37 PM, René J.V. Bertin wrote:
> On Debian/Ubuntu, there are x86_64, i386 and x32 versions of libstdc++, and
> they're clearly the version belonging to the default gcc version (4.8x atm on
> Ubuntu 14.04). All new packages are built with that compiler, but there isn't
> ne
On Sat, Sep 6, 2014 at 1:37 PM, René J.V. wrote:
> OTOH, I just noticed that the binaries Qt5 distributes are linked against
> libstdc++, which I do have in /usr/lib on my 10.9 VM. A remnant of the OS
> upgrade, or is it still distributed by Apple, for older software?
> Question is then, how do Q
On Saturday September 06 2014 13:10:40 Lawrence Velázquez wrote:
> I do not know if anyone has tried that. You're welcome to volunteer for
> guinea pig duty.
Initial impression is that it works fine (and I found a trace of having
relinked a version on 10.3 or 10.4, from a self-build gcc, though
On Sat, Sep 6, 2014 at 1:21 PM, Brandon Allbery wrote:
> > On 10.6 or earlier already? I just wonder, this kind of situation is not
>> at all uncommon on Linux, how come it doesn't bite there?
>>
>> You'd have to ask someone who uses Linux and knows how Linux package
>> managers link up their GCC
On Sat, Sep 6, 2014 at 1:10 PM, Lawrence Velázquez
wrote:
> >> The FSF GCC ports each used to include their own runtime and support
> >> libraries (libstdc++, libgcc_s, etc.). This caused problems when, for
> >> example, a port using gcc44's libraries linked against a port using
> gcc45's
> >> li
On Sep 6, 2014, at 6:51 AM, Mojca Miklavec
wrote:
> I already argued that we really need a libc++-based buildbot for 10.6-10.8.
>
> From what I understood all we need is a fix in binary package
> signature + time and resources to set up the buildbots. Once the
> buildbots run, people can start
Before I start, I should make something clear: Given that this mixed runtime
problem is definitively a problem on Lion and newer, I do not think MacPorts
should jump through hoops to cater to Snow Leopard. We technically do not
support Snow Leopard. In a month or two, Snow Leopard will be two ve
On Fri, Sep 5, 2014 at 9:05 PM, Ryan Schmidt wrote:
>> On Sep 5, 2014, at 1:45 PM, René J.V. Bertin wrote:
>>
>> Starting with kdevelop 4.7, C++11 is going to be required
>
> Currently, that means the port will have require OS X 10.9 and later. Support
> for 10.7 and 10.8 would involve moving all
Yes, if you want C++11 on Snow Leopard, you need to install the libcxx port and
use clang-3.3 or later.
Also, I believe you may need to add -stdlib=libc++ in addition to -std=c++11.
I think it should be implied, but I forget if it is.
--Jeremy
> On Sep 5, 2014, at 08:23, Lawrence Velázquez w
On Sep 5, 2014, at 12:36 PM, René J.V. Bertin wrote:
> I wonder though, that ticket has discussion about how runtimes will be
> removed from the gcc ports, but I have been building kdevelop-git with
> gcc-4.8 and running it successfully (apart from crashes not occurring on
> Linux, which is th
On Sep 5, 2014, at 4:54 PM, René J.V. Bertin wrote:
> So that leaves macports-gcc-4.8 and higher ... I wonder if some of the
> crashes I've seen are due to using an outdated C++ runtime;
Judging from your comments, your crashes are probably caused because you're
mixing up C++ runtime libraries
On Friday September 05 2014 14:05:15 Ryan Schmidt wrote:
> > Starting with kdevelop 4.7, C++11 is going to be required
>
> Currently, that means the port will have require OS X 10.9 and later. Support
> for 10.7 and 10.8 would involve moving all of MacPorts from libstdc++ to
> libc++ on those s
> On Sep 5, 2014, at 1:45 PM, René J.V. Bertin wrote:
>
> Starting with kdevelop 4.7, C++11 is going to be required
Currently, that means the port will have require OS X 10.9 and later. Support
for 10.7 and 10.8 would involve moving all of MacPorts from libstdc++ to libc++
on those systems, w
On Friday September 05 2014 18:36:08 René J.V. Bertin wrote:
> On Friday September 05 2014 11:23:45 Lawrence Velázquez wrote:
Re: libcxx port and using it ...
I had to finagle out that the only way to get -stdlib=libc++ into the compile
options was to use configure.cxx_stdlib on the commandline
On Friday September 05 2014 11:23:45 Lawrence Velázquez wrote:
> From what I recall, Snow Leopard doesn't have a C++11 runtime. You may have
> to install the libcxx port manually; clang-3.4 and earlier don't pull it in
> automatically.
No, indeed it doesn't. I keep mixing up runtime and shared
On Sep 5, 2014, at 11:23 AM, Lawrence Velázquez wrote:
> From what I recall, Snow Leopard doesn't have a C++11 runtime. You may have
> to install the libcxx port manually; clang-3.4 and earlier don't pull it in
> automatically.
To be clear, I don't actually know whether this is causing your co
On Sep 5, 2014, at 8:23 AM, René J.V. Bertin wrote:
> It's all in the title; MacPorts' clang-3.4 doesn't seem to find the
> initializer_list header on 10.6, whether I specify -std=c++11 or not. It's as
> if it doesn't search in ${prefix}/libexec/llvm-3.4/include/c++/v1 because if
> I add that
It's all in the title; MacPorts' clang-3.4 doesn't seem to find the
initializer_list header on 10.6, whether I specify -std=c++11 or not. It's as
if it doesn't search in ${prefix}/libexec/llvm-3.4/include/c++/v1 because if I
add that path via -I the compilation succeeds.
Of course I then get mi
28 matches
Mail list logo
