Re: VLC cannot play MKV files?

[Vincent Habchi]

>> I was under the impression that Apple already compressed the files and 
>> programs installed with the operating system, using HFS compression, ever 
>> since taking up less disk space was listed as a feature of Snow Leopard.
> Yeah, I thought so too, but I also have the impression that may not always 
> work as advertised after a few updates have been applied. Easy enough to 
> check with `ls -lO` (/usr/bin/ls that is).

I’ve applied René method, disabling SIP while compressing /Applications. It 
gave me some significant savings, thus I surmise all the applications are not 
compressed. Xcode is, though, but things like iWorks (Pages, etc.) are not.

I am not space savings in Snow Leopard were the result of using file 
compression. I’d rather wager Apple get rid of some universal code (ppc/ppc64) 
in 10.6. 10.5 was the final version usable with ppc, AFAIR.

Vincent

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

Re: VLC cannot play MKV files?

[Chris Jones]

Hi,


On 26/01/16 09:47, Vincent Habchi wrote:

I was under the impression that Apple already compressed the files and programs 
installed with the operating system, using HFS compression, ever since taking 
up less disk space was listed as a feature of Snow Leopard.

Yeah, I thought so too, but I also have the impression that may not always work 
as advertised after a few updates have been applied. Easy enough to check with 
`ls -lO` (/usr/bin/ls that is).


I’ve applied René method, disabling SIP while compressing /Applications. It 
gave me some significant savings, thus I surmise all the applications are not 
compressed. Xcode is, though, but things like iWorks (Pages, etc.) are not.

I am not space savings in Snow Leopard were the result of using file 
compression. I’d rather wager Apple get rid of some universal code (ppc/ppc64) 
in 10.6. 10.5 was the final version usable with ppc, AFAIR.


I have in the past used Xslimmer to save a fair amount of space on old 
OSX versions where PPC versions etc. where still shipped.


http://www.xslimmer.com/

With it you can slim down fat binaries to the exact version you require 
(PP, 32bit, 64bit) but also remove, if you want, all the 
internationalization a lot of applications come with. Some applications 
can really be reduced in size...


Chris

p.s. I have nothing to do with them...



Vincent

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


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

Re: [145141] trunk/dports/python

[Ryan Schmidt]

On Jan 26, 2016, at 13:50, adfernan...@macports.org wrote:
> 
> Revision
> 145141
> Author
> adfernan...@macports.org
> Date
> 2016-01-26 13:50:47 -0800 (Tue, 26 Jan 2016)
> Log Message
> 
> new port: py-pyinstaller 3.1 closes #42693
> Added Paths
> 
> trunk/dports/python/py-pyinstaller/
> trunk/dports/python/py-pyinstaller/Portfile
> Diff
> 
> Added: trunk/dports/python/py-pyinstaller/Portfile (0 => 145141)
> 
> 
> --- trunk/dports/python/py-pyinstaller/Portfile   
> (rev 0)
> +++ trunk/dports/python/py-pyinstaller/Portfile   2016-01-26 21:50:47 UTC 
> (rev 145141)
> @@ -0,0 +1,31 @@
> +# $Id: Portfile 114324 2013-12-05 08:44:51Z ryandes...@macports.org $
> +
> +PortSystem  1.0
> +PortGroup python1.0
> +PortGroup github1.0
> +
> +namepy-pyinstaller
> +version 3.1
> +
> +fetch.type  git

Why do you need fetch.type git?

> +github.setuppyinstaller PyInstaller ${version} v
> +
> +platforms   darwin
> +supported_archs noarch
> +maintainers openmaintainer adfernandes
> +description converts (packages) Python programs into stand-alone 
> executables
> +long_description${description}
> +license GPL license with a special exception which allows to use 
> PyInstaller to build and distribute non-free programs (including commercial 
> ones)

MacPorts interprets the license field as a space-separated list of valid 
license names. You should probably only list licenses known to the 
port_binary_distributable.tcl script. You can add notes about the license in a 
portfile comment. 

> +homepagehttp://www.pyinstaller.org/
> +
> +if {${name} ne ${subport}} {
> +
> +python.versions 27 33 34 35

Doesn't the python.versions line have to be outside this block?

> +livecheck.type  none
> +
> +} else {
> +livecheck.type  regex
> +livecheck.url   ${homepage}
> +livecheck.regex "The latest stable release of PyInstaller is 
> (\\d+(?:\\.\\d+)*)"
> +}
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Using cxx11 PortGroup on < 10.9

[Michael Dickens]

My bad for thinking Mojca wanted support for libstdc++. Somehow I really
misinterpreted the original postings. Happens sometimes. - MLD

On Mon, Jan 25, 2016, at 12:11 PM, Jeremy Huddleston Sequoia wrote:
> "libstdc++" means /usr/lib/libstdc++.6.dylib, and it doesn't support
> C++11, so it is not possible to use the system libstdc++ for C++11 code. 
> I don't think we want to start supporting people using
> ${prefix}/lib/libstdc++.6.dylib from libgcc as that is quite untested and
> aiming for a world of hurt.
> 
> > compiler.whitelist macports-gcc-5 macports-gcc-4.9
> 
> This is surely not what you want.  This will cause the build to use
> ${prefix}/lib/libstdc++.6.dylib.  I could see this being useful for 10.5
> and earlier or ppc builds (because libc++ doesn't work on those
> platforms), but we don't really support those platforms any more anyways.
>  You might as well use the more-tested path of using libc++ and a
> macports-clang compiler in these cases.
> 
> To be clear, setting configure.cxx_stdlib to "libstdc++" means
> /usr/lib/libstdc++.6.dylib, it does not mean use any libstdc++ available.
>  The macports-gcc compilers don't quite work well for this scenario.  If
> you really want to support this, we'll need some new option for this
> (maybe macports-libstdc++), and dependency tracking will become quite
> difficult.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: -stdlib=libc++ added to configure.cxxflags but not configure.ldflags

[Ryan Schmidt]

On Jan 26, 2016, at 4:35 AM, René J.V. Bertin wrote:

> I just ran into a situation (building a Qt5 port) where for some reason 
> -stdlib=libc++ was added to configure.cxxflags but not to configure.ldflags . 
> That led to a failing final link.
> 
> I worked around the issue by adding the option myself if it is detected in 
> cxxflags, but I wonder why this isn't an issue more often.
> 
> I'm running "base" 2.3.4 rev. 140804 ; the port in question is 
> https://github.com/RJVB/macstrop/tree/master/devel/xxdiff .

I agree that MacPorts base only adds -stdlib=${configure.cxx_stdlib} to 
configure.cxxflags, not configure.ldflags, but that's not necessarily wrong, is 
it? If the build system just wants to link already-compiled objects, it doesn't 
need compiler flags. If the build system wants to compile and link at the same 
time, it's the build system's responsibility to add both the compiler flags 
(CFLAGS or CXXFLAGS) and the linker flags (LDFLAGS) to the compile/link command.


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

Re: VLC cannot play MKV files?

[Ryan Schmidt]

> On Jan 26, 2016, at 1:47 AM, Vincent Habchi  wrote:
> 
>>> I was under the impression that Apple already compressed the files and 
>>> programs installed with the operating system, using HFS compression, ever 
>>> since taking up less disk space was listed as a feature of Snow Leopard.
>> Yeah, I thought so too, but I also have the impression that may not always 
>> work as advertised after a few updates have been applied. Easy enough to 
>> check with `ls -lO` (/usr/bin/ls that is).
> 
> I’ve applied René method, disabling SIP while compressing /Applications. It 
> gave me some significant savings, thus I surmise all the applications are not 
> compressed. Xcode is, though, but things like iWorks (Pages, etc.) are not.
> 
> I am not space savings in Snow Leopard were the result of using file 
> compression.

According to the Ars Technica review of Snow Leopard, 97% of executable files 
in Snow Leopard are compressed.

http://arstechnica.com/apple/2009/08/mac-os-x-10-6/3/


> I’d rather wager Apple get rid of some universal code (ppc/ppc64) in 10.6. 
> 10.5 was the final version usable with ppc, AFAIR.

10.6 removed ppc64 code but kept ppc code. 10.7 removed ppc code.


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

Re: VLC cannot play MKV files?

[Ryan Schmidt]

> On Jan 26, 2016, at 2:26 AM, René J.V. Bertin  wrote:
> 
> Given the disk savings it can give I really don't understand why the patch 
> that adds HFS compression to port activation was never accepted.

For reference, that was this ticket:

https://trac.macports.org/ticket/36560

There were performance concerns earlier in the discussion but I'm not sure if 
the latest version of the patch attached there resolves them.

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

Re: -stdlib=libc++ added to configure.cxxflags but not configure.ldflags

[René J . V . Bertin]

On Tuesday January 26 2016 08:27:12 Ryan Schmidt wrote:

>If the build system just wants to link already-compiled objects, it doesn't 
>need compiler flags. If the build system wants to compile and link at the same 
>time, it's the build system's responsibility to add both the compiler flags 
>(CFLAGS or CXXFLAGS) and the linker flags (LDFLAGS) to the compile/link 
>command.

That's not what's happening in the case I had. Instead, I got a whole slew of 
missing symbol errors, mostly "standard" symbols. Whatever the reason, the C++ 
runtime library wasn't pulled in by the linker, and adding -stdlib=libc++ 
resolved that. Regardless of whether I built with or without LTO.

What still surprises me is that libc++ isn't pulled in by default (this is on 
10.9) because there is no other C++ runtime.

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

Re: VLC cannot play MKV files?

[Daniel J. Luke]

On Jan 26, 2016, at 11:55 AM, Ryan Schmidt  wrote:
> There were performance concerns earlier in the discussion but I'm not sure if 
> the latest version of the patch attached there resolves them.

the latest comment that mentions it says it's a 2x slowdown (better than the 
original 10x slowdown).

As mentioned in the ticket - this is really something that needs to be 
configurable if it's added (I can see how one might want this on a small SSD, 
but I  don't want it set on my large disk array...)

-- 
Daniel J. Luke  
 
++ 
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++ 
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++





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

Re: VLC cannot play MKV files?

[Joshua Root]

On 2016-1-27 04:04 , Daniel J. Luke wrote:
> On Jan 26, 2016, at 11:55 AM, Ryan Schmidt  wrote:
>> There were performance concerns earlier in the discussion but I'm not sure 
>> if the latest version of the patch attached there resolves them.
> 
> the latest comment that mentions it says it's a 2x slowdown (better than the 
> original 10x slowdown).
> 
> As mentioned in the ticket - this is really something that needs to be 
> configurable if it's added (I can see how one might want this on a small SSD, 
> but I  don't want it set on my large disk array...)

Not really thrilled by the inline hex file and shelling out to run a
command pipeline before every extract either. Seems like this could be a
configure check for the system bsdtar supporting the feature instead.

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

Re: VLC cannot play MKV files?

[Daniel J. Luke]

On Jan 26, 2016, at 12:12 PM, Joshua Root  wrote:
> Not really thrilled by the inline hex file and shelling out to run a
> command pipeline before every extract either. Seems like this could be a
> configure check for the system bsdtar supporting the feature instead.

+1

I didn't review the patches - I had thought that that was how the latest one 
worked (if not, it really should work that way).

-- 
Daniel J. Luke  
 
++ 
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++ 
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++





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

Re: VLC cannot play MKV files?

[René J . V . Bertin]

On Tuesday January 26 2016 08:55:20 Ryan Schmidt wrote:

>https://trac.macports.org/ticket/36560

Yeah, that was the one.

>There were performance concerns earlier in the discussion but I'm not sure if 
>the latest version of the patch attached there resolves them.

Activating hfsCompression is still noticeably slower, and that's inevitable. 
The cost can be reduced by using an accelerated zlib, but that's a delicate 
issue on here that I'm not going to reignite. That said, I do use the 
CloudFlare patches locally, and find that the cost is perfectly acceptable once 
you take the disk savings into account. That's using a big spinning disk 
though, so the cycles lost compressing data are compensated partly by less 
cycles writing the data to disk.
In any case, the performance difference becomes something of an issue only on 
(very) large ports like Qt, where the savings are the most important. I don't 
de/reactivate (big) ports often enough for this to be an issue.

> Not really thrilled by the inline hex file and shelling out to run a

Isn't that simply a test to see if the bsdtar command found "does the trick"?

> command pipeline before every extract either

I think the system bsdtar doesn't support this on all OS X versions that do 
support hfs compression.

I've never looked in detail at how activation works without this patch; does it 
always use a temporary folder in ${prefix}/var/macports/software/${subport} 
from which items are then moved into place? If so, the easiest approach to 
making this optional would be to run a version of afsctool on the extraction 
folder. Afsctool being apparent abandonware I've developed it further, letting 
it process files in parallel. Combined with an accelerated zlib that makes fast 
enough that even a post-build compression of Qt's build.dir is insignificant 
w.r.t. to build time (for very appreciable savings).

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

Re: Using cxx11 PortGroup on < 10.9

[Mojca Miklavec]

On 25 January 2016 at 20:17, Ryan Schmidt wrote:
> On Jan 24, 2016, at 11:15 PM, Jeremy Huddleston Sequoia wrote:
>
>> What benefit does "cxx.require_global_libc++ no" have over the current 
>> approach of just doing:
>>
>>configure.cxx_stdlib libc++
>>depends_lib-append port:libcxx
>
> Or I was going to suggest:
>
> PortGroupcxx11 1.0
> configure.cxx_stdlib libc++
>
> which is what the mongodb port does. The cxx11 1.0 portgroup ensures that 
> compilers that don't do C++11 are blacklisted, which I think just depending 
> on the libcxx port wouldn't do.

My experience is that the second command is not needed because using
"PortGroup cxx11 1.0" fails on < 10.9 anyway (unless libc++ is
default).

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

Re: -stdlib=libc++ added to configure.cxxflags but not configure.ldflags

[Rainer Müller]

On 2016-01-26 17:27, Ryan Schmidt wrote:
> I agree that MacPorts base only adds -stdlib=${configure.cxx_stdlib}
> to configure.cxxflags, not configure.ldflags, but that's not
> necessarily wrong, is it?

Actually -stdlib=libc++ is also needed for linking to ensure the
correct library will be linked in.

$ clang++ -stdlib=libc++ -o foo foo.o
$ otool -L foo
foo:
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current 
version 104.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1213.0.0)

$ clang++ -stdlib=libc++ -o foo foo.o
$ otool -L foo
foo:
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 
120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1213.0.0)


> If the build system just wants to link
> already-compiled objects, it doesn't need compiler flags. If the
> build system wants to compile and link at the same time, it's the
> build system's responsibility to add both the compiler flags (CFLAGS
> or CXXFLAGS) and the linker flags (LDFLAGS) to the compile/link
> command.

-stdlib=... is a linker flag not for ld itself, but for the clang++ to
pass the correct library to ld.

I think this should be added to configure.ldflags in the same way it is
handled for configure.cxxflags.

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

Re: -stdlib=libc++ added to configure.cxxflags but not configure.ldflags

[Joshua Root]

On 2016-1-27 04:55 , Rainer Müller wrote:
> -stdlib=... is a linker flag not for ld itself, but for the clang++ to
> pass the correct library to ld.
> 
> I think this should be added to configure.ldflags in the same way it is
> handled for configure.cxxflags.

Does that work (or even make sense) when linking is not being done with
clang++?

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

Re: Using cxx11 PortGroup on < 10.9

[Mojca Miklavec]

On 25 January 2016 at 18:55, Ryan Schmidt wrote:
>> On Jan 25, 2016, at 09:29, Mojca Miklavec wrote:
>>
>> (Even more than that I would really like to see the buildbots with
>> libc++ as their default stdlib being set up.)
>
> As far as I know nothing has changed on this front. I'm totally willing to 
> set up libc++ build slaves for 10.6, 10.7 and 10.8, but cannot do so until we 
> agree on a naming scheme to differentiate libc++ packages from libstdc++ 
> packages, implement that in base, and release it.
>
> Well, that would be a prerequisite for *distributing* such packages. I 
> suppose we could set up build slaves that just build and don't distribute 
> their packages. But that wouldn't be as helpful.

I opened a new ticket:
http://trac.macports.org/ticket/50448

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

Re: -stdlib=libc++ added to configure.cxxflags but not configure.ldflags

[Rainer Müller]

On 2016-01-26 19:13, Joshua Root wrote:
> On 2016-1-27 04:55 , Rainer Müller wrote:
>> -stdlib=... is a linker flag not for ld itself, but for the clang++ to
>> pass the correct library to ld.
>>
>> I think this should be added to configure.ldflags in the same way it is
>> handled for configure.cxxflags.
> 
> Does that work (or even make sense) when linking is not being done with
> clang++?

How else would you link C++ code if not with clang/clang++?

The -stdlib=libc++ option is already specific to clang/clang++,
gcc/g++ do not understand it.

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

Re: -stdlib=libc++ added to configure.cxxflags but not configure.ldflags

[Joshua Root]

On 2016-1-27 05:52 , Rainer Müller wrote:
> On 2016-01-26 19:13, Joshua Root wrote:
>> On 2016-1-27 04:55 , Rainer Müller wrote:
>>> -stdlib=... is a linker flag not for ld itself, but for the clang++ to
>>> pass the correct library to ld.
>>>
>>> I think this should be added to configure.ldflags in the same way it is
>>> handled for configure.cxxflags.
>>
>> Does that work (or even make sense) when linking is not being done with
>> clang++?
> 
> How else would you link C++ code if not with clang/clang++?

LDFLAGS is not only used when linking C++ code.

> The -stdlib=libc++ option is already specific to clang/clang++,
> gcc/g++ do not understand it.

But the current check only considers the value of configure.cxx.

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

Re: -stdlib=libc++ added to configure.cxxflags but not configure.ldflags

[Rainer Müller]

On 2016-01-26 20:01, Joshua Root wrote:
> On 2016-1-27 05:52 , Rainer Müller wrote:
>> On 2016-01-26 19:13, Joshua Root wrote:
>>> On 2016-1-27 04:55 , Rainer Müller wrote:
 -stdlib=... is a linker flag not for ld itself, but for the clang++ to
 pass the correct library to ld.

 I think this should be added to configure.ldflags in the same way it is
 handled for configure.cxxflags.
>>>
>>> Does that work (or even make sense) when linking is not being done with
>>> clang++?
>>
>> How else would you link C++ code if not with clang/clang++?
> 
> LDFLAGS is not only used when linking C++ code.

Ah, of course, now I understand what you are hinting at. At least in my
test, linking C code with -stdlib=libc++ did not add any superfluous
dependency:

$ clang -stdlib=libc++ -o foo foo.c
$ otool -L foo
foo:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1213.0.0)

>> The -stdlib=libc++ option is already specific to clang/clang++,
>> gcc/g++ do not understand it.
> 
> But the current check only considers the value of configure.cxx.

It seems like we are getting to the point again at which a compiler
wrapper that only adds the -stdlib=... option for clang++ would be the
better way to implement this...

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

Re: Using cxx11 PortGroup on < 10.9

[Rainer Müller]

On 2016-01-25 18:55, Ryan Schmidt wrote:
>> On Jan 25, 2016, at 09:29, Mojca Miklavec wrote:
>> 
>> (Even more than that I would really like to see the buildbots with 
>> libc++ as their default stdlib being set up.)
> 
> As far as I know nothing has changed on this front. I'm totally
> willing to set up libc++ build slaves for 10.6, 10.7 and 10.8, but
> cannot do so until we agree on a naming scheme to differentiate
> libc++ packages from libstdc++ packages, implement that in base, and
> release it.

We also need changes to add cxx_stdlib to the parameters in
archive_sites.conf/archive_sites.tcl.

> Well, that would be a prerequisite for *distributing* such packages.
> I suppose we could set up build slaves that just build and don't
> distribute their packages. But that wouldn't be as helpful. 

With more and more ports requiring C++11, how many ports do we have that
have a hard requirement on libstdc++? This only happens when a port
wants to link against system libraries linked with libstdc++. Such a
buildbot with "cxx_stdlib libc++" could be helpful to find these ports.

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

Re: VLC cannot play MKV files?

[René J . V . Bertin]

On Tuesday January 26 2016 10:47:10 Vincent Habchi wrote:

>I’ve applied René method, disabling SIP while compressing /Applications. It 
>gave me some significant savings, thus I surmise all the applications are not 
>compressed. Xcode is, though, but things like iWorks (Pages, etc.) are not.

Xcode can be slimmed down significantly by getting rid of unneeded SDKs (and 
IIRC that doesn't require you to re-codesign it).
HFS compression is unstable in the sense that it gets lost when you rewrite the 
file. That's why commands like rsync have options to preserve compression. The 
lack of a user-space command to compress files shows that it isn't really 
intended as a tool for mere mortal users to save disk space. You could say 
that's because it's not in Apple's interest (they also sell disk space) but it 
becomes a bit easier to understand when you look at afsctool.c . Applying HFS 
compression to a file isn't a trivial matter *at all*, so I've added a bit more 
failsafe protections to the version I'm using myself.

Given the disk savings it can give I really don't understand why the patch that 
adds HFS compression to port activation was never accepted.

>I am not space savings in Snow Leopard were the result of using file 
>compression. I’d rather wager Apple get rid of some universal code (ppc/ppc64) 
>in 10.6. 10.5 was the final version usable with ppc, AFAIR.

Yes, but lots of apps and most all libraries/frameworks still had PPC code in 
them because 10.6 was the last version providing Rosetta.

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

-stdlib=libc++ added to configure.cxxflags but not configure.ldflags

[René J . V . Bertin]

Hi,

I just ran into a situation (building a Qt5 port) where for some reason 
-stdlib=libc++ was added to configure.cxxflags but not to configure.ldflags . 
That led to a failing final link.

I worked around the issue by adding the option myself if it is detected in 
cxxflags, but I wonder why this isn't an issue more often.

I'm running "base" 2.3.4 rev. 140804 ; the port in question is 
https://github.com/RJVB/macstrop/tree/master/devel/xxdiff .

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