Re: Of C++ (and other) runtimes

[René J . V . Bertin]

On Sunday October 09 2016 01:04:39 Jeremy Huddleston Sequoia wrote:

>That being said, it's technically possible and they should be binary 
>compatible.

Oh, and what about using DYLD_LIBRARY_PRELOAD? Not for systematic use, but 
shouldn't it be useful for testing purposes, or for debugging for instance when 
your code triggers one of those dynamic_cast errors (cf. 
https://llvm.org/svn/llvm-project/libcxxabi/trunk/src/private_typeinfo.cpp)?

R
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Of C++ (and other) runtimes

[René J . V . Bertin]

On Sunday October 09 2016 01:04:39 Jeremy Huddleston Sequoia wrote:

>My advice is to not mess with the base OS.  There is a very good reason why I 
>force the user to use a variant and don't even give instructions on how to use 
>darwinup to install the libcxxabi and libcxx tarballs.
>
>That being said, it's technically possible and they should be binary 
>compatible.

>> And since we're talking about runtimes: is it even possible to upgrade the 
>> ObjectiveC runtime, as far as that is of any interest when you don't upgrade 
>> the rest of the SDK using it?
>
>It's all code and objc4 is OSS.  Go nuts 
>(http://opensource.apple.com/source/objc4/objc4-680/).  Make backups.  YMMV.

Heh. I see no mention of ARC in the release notes; is that not part of 
(supported in) the runtime?

Still, is there a point in taking the risk? Not that it should be particularly 
hard to back out as long as you keep copies of the originals as well as a way 
to boot the system so you can mount the updated root and restore those original 
copies. I suppose that building with more than the standard optimisation 
settings will not make a significant difference in runtime performance?

Are these supposed to be signed, btw?

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Of C++ (and other) runtimes

[Jeremy Huddleston Sequoia]

> On Oct 7, 2016, at 08:59, René J.V. Bertin  wrote:
> 
> On Friday October 07 2016 11:43:48 Lawrence Velázquez wrote:
> 
> [was Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of 
> using libstdc++]
> 
>> it might be useful to refine this mechanism to allow something like
>> "configure.compiler.cxx macports-gcc-XYZ", which would add a direct
>> library dependency on libgcc (among other things).
> 
> Yep, that sounds like a good idea, but can that not be handled by the 
> existing configure.cxx syntax?
> 
> BTW: how risky is it to replace libc++ on newer OS X versions which do in 
> fact provide them?

My advice is to not mess with the base OS.  There is a very good reason why I 
force the user to use a variant and don't even give instructions on how to use 
darwinup to install the libcxxabi and libcxx tarballs.

That being said, it's technically possible and they should be binary compatible.

I was actually using the newer libcxxabi and libcxx ports on Lion and Mountain 
Lion for a while.  The only issue I saw was that a system process (helpd or 
something like that) was crashing (I think on ML).  I didn't dig into the 
issue, but it's possible it was just a bug in the daemon that was revealed by 
the newer C++ runtime.  It's also quite possible there was a serious regression 
in the C++ runtime.  I never got around to looking into it more closely.

> And since we're talking about runtimes: is it even possible to upgrade the 
> ObjectiveC runtime, as far as that is of any interest when you don't upgrade 
> the rest of the SDK using it?

It's all code and objc4 is OSS.  Go nuts 
(http://opensource.apple.com/source/objc4/objc4-680/).  Make backups.  YMMV.

> 
> R.
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev



smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Of C++ (and other) runtimes

[Lawrence Velázquez]

> On Oct 7, 2016, at 11:59 AM, René J.V. Bertin  wrote:
> 
> On Friday October 07 2016 11:43:48 Lawrence Velázquez wrote:
> 
> [was Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because
> of using libstdc++]
> 
>> it might be useful to refine this mechanism to allow something like
>> "configure.compiler.cxx macports-gcc-XYZ", which would add a direct
>> library dependency on libgcc (among other things).
> 
> Yep, that sounds like a good idea, but can that not be handled by the
> existing configure.cxx syntax?

The "configure.cxx" option is meant to directly set the CXX environment
variable for the configure stage. Technically it is possible to add
traces to it to add dependencies automatically, which would be the
inverse of what we currently do (explicitly specify the compiler
collection and update configure.* accordingly). That might be fragile,
though.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Of C++ (and other) runtimes

[René J . V . Bertin]

On Friday October 07 2016 11:43:48 Lawrence Velázquez wrote:

[was Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of using 
libstdc++]

> it might be useful to refine this mechanism to allow something like
> "configure.compiler.cxx macports-gcc-XYZ", which would add a direct
> library dependency on libgcc (among other things).

Yep, that sounds like a good idea, but can that not be handled by the existing 
configure.cxx syntax?

BTW: how risky is it to replace libc++ on newer OS X versions which do in fact 
provide them?

And since we're talking about runtimes: is it even possible to upgrade the 
ObjectiveC runtime, as far as that is of any interest when you don't upgrade 
the rest of the SDK using it?

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev