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
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 the
[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 Sep 7, 2014, at 4:11 AM, René J.V. Bertin rjvber...@gmail.com 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
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 of
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
On Sep 6, 2014, at 6:51 AM, Mojca Miklavec mojca.miklavec.li...@gmail.com
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
On Sat, Sep 6, 2014 at 1:10 PM, Lawrence Velázquez lar...@macports.org
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
On Sat, Sep 6, 2014 at 1:21 PM, Brandon Allbery allber...@gmail.com 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
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:37 PM, René J.V. rjvber...@gmail.com 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
On Sep 6, 2014, at 1:37 PM, René J.V. Bertin rjvber...@gmail.com 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
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 that.
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
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 libraries.
On Sat, Sep 6, 2014 at 6:52 PM, Ryan Schmidt ryandes...@macports.org
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
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 Sep 5, 2014, at 1:45 PM, René J.V. Bertin rjvber...@gmail.com 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
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
On Sep 5, 2014, at 4:54 PM, René J.V. Bertin rjvber...@gmail.com 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++
20 matches
Mail list logo
