Re: Why is one compiler on 10.6 able to generate PPC binaries and not the other?

[Brandon Allbery]

On Thu, Mar 10, 2016 at 8:20 PM, Mojca Miklavec  wrote:

> >> on 10.6/x86_64 I tried to install clang 3.7 (thinking that version 3.7
> >> might have an even better support for PPC than 3.6).


I just noticed this... my own assumption would be that, as availability of
PPC test hosts is ever-decreasing, newer versions of things would be more
likely to have bitrotted PPC support.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Why is one compiler on 10.6 able to generate PPC binaries and not the other?

[Mojca Miklavec]

On 10 March 2016 at 21:26, Ryan Schmidt wrote:
>> On Mar 10, 2016, at 1:00 PM, Mojca Miklavec wrote:
>>
>> Hi,
>>
>> While following
>>https://trac.macports.org/wiki/LibcxxOnOlderSystems#Leopardppc
>> on 10.6/x86_64 I tried to install clang 3.7 (thinking that version 3.7
>> might have an even better support for PPC than 3.6).
>>
>> The problem is that clang-mp-3.7 doesn't want to produce ppc binaries,
>> so I wasn't able to install libcxx. I get:
>>
>>> clang++-mp-3.7 a.cc -arch ppc
>> ld: unknown/unsupported architecture name for: -arch ppc
>> clang: error: linker command failed with exit code 1 (use -v to see 
>> invocation)
>>
>> At the same time clang++-mp-3.4 works fine even though both clang 3.4
>> and 3.7 are x86_64 only.
>>
>> I'm now trying to rebuild everything as +universal (with ppc included
>> in the list of universal architectures) and hope that it will work
>> afterwards. But I would be grateful for ideas about why clang 3.4
>> would be able to create ppc binaries and clang 3.7 not.
>>
>> Thank you,
>>   Mojca
>>
>> PS: I'm not actually using the PPC, I'm doing this all for fun and as
>> a challenge. But I don't have any VM with 10.5, so I wanted to do the
>> cross-compiling step on VM with 10.6.
>
> Maybe:
>
> https://trac.macports.org/changeset/129356

Weird. This changes predates the initial version of
https://trac.macports.org/wiki/LibcxxOnOlderSystems
that suggests cross-compiling libcxxabi with ppc support.

Judging from
http://www.csl.cornell.edu/~fang/sw/llvm/
I would imagine that there must be a way to compile libc++ (even on
10.4 and even if from another repository). The problem is a bit of a
chicken-and-egg, requiring a working clang-3.6 (3.7?) compiler to
build libc++; but 3.7 would refuse to do the linking step. Maybe I'll
need to do that in multiple stages as described on that website.

I'm waiting for the universal build of clang 3.4 to finish first. I
don't know if that will make any difference, but let's see.

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

Re: port:libclang (and libLLVM)

[Jack Howarth]

On Thu, Mar 10, 2016 at 4:47 PM, René J.V.  wrote:
> On Thursday March 10 2016 14:24:00 Ryan Schmidt wrote:
>
>> > CMake does something similar for all 4 built-in presets, so the only way I 
>> > know to control the exact compiler flags is to set CMAKE_BUILD_TYPE to a 
>> > custom value. Debian/Ubuntu do that in their packaging scripts 
>> > (-DCMAKE_BUILD_TYPE=Debian); I've proposed a modified CMake PortGroup that 
>> > uses -DCMAKE_BUILD_TYPE=MacPorts (and parses configure.cppflags because 
>> > CMake doesn't have a dedicated variable for preprocessor options).
>>
>> If so, that would be yet another bug, or yet another broken-by-design 
>> feature, of cmake.
>
> I tend to agree, but it depends on how you look at the concept of presets ...
>

From http://opensource.apple.com/source/clang/clang-700.0.72/Makefile,
it appears that Apple builds llvm/clang at -O2 rather than -Os.

>> > Here's something much more interesting though: I just discovered that llvm 
>> > and clang 3.8 are both about TEN times smaller than they were in 3.6 and 
>> > 3.7:

The difference is that the builds of llvm prior to 3.8 release was
done with the configure based build system. The configure based build
was deprecated out in favor of the cmake build starting with 3.8.

$ du -k /opt/local/libexec/llvm-3.7/lib
...
1675924 /opt/local/libexec/llvm-3.7/lib

$ du -k /opt/local/libexec/llvm-3.8/lib
...
16 /opt/local/libexec/llvm-3.8/lib

This bloat in the prior releases is due to the default usage of
--enable-debug-symbols  in the configure build whereas the cmake build
defaults to the -debug variant.

> ...
>> >
>> > What's going on here??
>
>>
>> My llvm-3.4 is 436MB, llvm-3.7 765MB.
>
> Are those the tarball sizes, or the unpacked sizes?
>
>>
>> I don't know why mine are the size they are and yours are the size they are.
>
> Differences due to OS version and thus the used compiler?
>
>> You could untar your llvm-3.7 and llvm-3.7 and compare them to see where the 
>> size difference lies.
>
> You did notice that I repackaged the images as xz'ed tarballs, right? That 
> does make a considerable difference for llvm and clang.
>
> According to xz, the llvm-3.7 tarball is 1628.6Mb uncompressed, llvm-3.6 
> 1326Mb, llvm-3.8 107.3Mb . The llvm-3.8 destroot I just built (without shared 
> libllvm and without RTTI support, using MacPorts clang 3.7 and -O3 
> -march=native) is 387Mb.
>
> R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Checking for problems before committing

[Joshua Root]

On 2016-3-11 08:41 , David Evans wrote:

On 3/10/16 12:29 PM, Ryan Schmidt wrote:


On Mar 10, 2016, at 12:48 AM, Mojca Miklavec wrote:


On 10 March 2016 at 05:48, Ryan Schmidt wrote:


Obviously nobody is going to commit something they believe is broken, but it 
does sometimes end up being the case for some subset of users. When it does, 
and we learn that it has happened, we try to fix it. If everybody had to test 
everything on a clean system on every version of OS X and every version of 
Xcode before committing, nobody would ever commit anything because nobody has 
the time and resources to do all that testing. We do have automated build 
machines that do build every commit on a clean system with no ports installed 
with several versions of OS X and the latest version of Xcode for those 
systems. That automated system did catch this webkit2-gtk build problem on El 
Capitan,



When I was testing wxWidgets, discovered a problem and submitted a
patch, I noticed what they are doing now (which is some light years
more advanced compared to what they did a few years back when most of
the tickets were stuck ignored at their Trac; similar to what happens
in many cases in MacPorts).

- user submits a patch
- the system checks whether the patch applies cleanly
- the system automatically builds wxWidgets on Windows in 6 different
ways (cygwin, mingw32 with msys, mingw, nmake with VS 14, nmake with
VS 9, msbuild), on Linux in five different ways (one is with clang
3.5), and on OS X 10.9
- I'm not sure whether wxWidgets does it as well, but it is also
possible to run tests as part of the build

The developers then only apply the patch if all of the checks mentioned pass.

The point is that this is all done *in advance* and avoids a lot of
problems. I would love to see something similar being done for patches
submitted to our Trac. Of course they would have to be submitted in a
different way and I'm aware that this is not really trivial to set up.
But it would be extremely helpful.


Yes, this would be helpful. I intend to look into doing something like this. 
However right now and for the next several weeks there are a lot of other more 
pressing issues I need to be working on for Mac OS Forge.


One approach I have thought about is this:

Establish a "testing" instance of the port repository and have maintainers 
commit to it.  The buildbots would then build
from changes to this repo and, upon a successful build, move (copy, merge, whatever) the 
port to the "live" repository.
The rsync server would publish from the "live" repository.


I've thought about this too. One issue I can see is that a successful 
port update can still break dependents (see openssl). So unless you 
rebuild all dependents on every commit, you still don't have any sort of 
guarantee that the ports in the live repo work at any given time.



This is not a detailed proposal but you get the idea and I think could be 
implemented without too much work. The plus is
that it would be relatively automated without too many false positives.  Exception cases 
are ports that "fail" building
but are considered "good."

   * ports that "fail" because they require non-default dependencies (+quartz 
is one class, gtk-osx-application for instance)
   * ports that "fail" because they are meant to (obsolete ports, graveyards)
   * you can probably think of more

Not a really original idea but at least it would be some filter between 
maintainer commits and what the user gets


Another approach would be to add a 'try' scheduler to our buildbot config.



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

Re: port:libclang (and libLLVM)

[René J . V . Bertin]

On Thursday March 10 2016 14:24:00 Ryan Schmidt wrote:

> > CMake does something similar for all 4 built-in presets, so the only way I 
> > know to control the exact compiler flags is to set CMAKE_BUILD_TYPE to a 
> > custom value. Debian/Ubuntu do that in their packaging scripts 
> > (-DCMAKE_BUILD_TYPE=Debian); I've proposed a modified CMake PortGroup that 
> > uses -DCMAKE_BUILD_TYPE=MacPorts (and parses configure.cppflags because 
> > CMake doesn't have a dedicated variable for preprocessor options).
> 
> If so, that would be yet another bug, or yet another broken-by-design 
> feature, of cmake.

I tend to agree, but it depends on how you look at the concept of presets ... 

> > Here's something much more interesting though: I just discovered that llvm 
> > and clang 3.8 are both about TEN times smaller than they were in 3.6 and 
> > 3.7:
...
> > 
> > What's going on here??

> 
> My llvm-3.4 is 436MB, llvm-3.7 765MB. 

Are those the tarball sizes, or the unpacked sizes?

> 
> I don't know why mine are the size they are and yours are the size they are.

Differences due to OS version and thus the used compiler?

> You could untar your llvm-3.7 and llvm-3.7 and compare them to see where the 
> size difference lies.

You did notice that I repackaged the images as xz'ed tarballs, right? That does 
make a considerable difference for llvm and clang.

According to xz, the llvm-3.7 tarball is 1628.6Mb uncompressed, llvm-3.6 
1326Mb, llvm-3.8 107.3Mb . The llvm-3.8 destroot I just built (without shared 
libllvm and without RTTI support, using MacPorts clang 3.7 and -O3 
-march=native) is 387Mb.

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

Re: Checking for problems before committing

[David Evans]

On 3/10/16 12:29 PM, Ryan Schmidt wrote:
> 
> On Mar 10, 2016, at 12:48 AM, Mojca Miklavec wrote:
> 
>> On 10 March 2016 at 05:48, Ryan Schmidt wrote:
>>>
>>> Obviously nobody is going to commit something they believe is broken, but 
>>> it does sometimes end up being the case for some subset of users. When it 
>>> does, and we learn that it has happened, we try to fix it. If everybody had 
>>> to test everything on a clean system on every version of OS X and every 
>>> version of Xcode before committing, nobody would ever commit anything 
>>> because nobody has the time and resources to do all that testing. We do 
>>> have automated build machines that do build every commit on a clean system 
>>> with no ports installed with several versions of OS X and the latest 
>>> version of Xcode for those systems. That automated system did catch this 
>>> webkit2-gtk build problem on El Capitan,
>>
>>
>> When I was testing wxWidgets, discovered a problem and submitted a
>> patch, I noticed what they are doing now (which is some light years
>> more advanced compared to what they did a few years back when most of
>> the tickets were stuck ignored at their Trac; similar to what happens
>> in many cases in MacPorts).
>>
>> - user submits a patch
>> - the system checks whether the patch applies cleanly
>> - the system automatically builds wxWidgets on Windows in 6 different
>> ways (cygwin, mingw32 with msys, mingw, nmake with VS 14, nmake with
>> VS 9, msbuild), on Linux in five different ways (one is with clang
>> 3.5), and on OS X 10.9
>> - I'm not sure whether wxWidgets does it as well, but it is also
>> possible to run tests as part of the build
>>
>> The developers then only apply the patch if all of the checks mentioned pass.
>>
>> The point is that this is all done *in advance* and avoids a lot of
>> problems. I would love to see something similar being done for patches
>> submitted to our Trac. Of course they would have to be submitted in a
>> different way and I'm aware that this is not really trivial to set up.
>> But it would be extremely helpful.
> 
> Yes, this would be helpful. I intend to look into doing something like this. 
> However right now and for the next several weeks there are a lot of other 
> more pressing issues I need to be working on for Mac OS Forge.

One approach I have thought about is this:

Establish a "testing" instance of the port repository and have maintainers 
commit to it.  The buildbots would then build
from changes to this repo and, upon a successful build, move (copy, merge, 
whatever) the port to the "live" repository.
The rsync server would publish from the "live" repository.

This is not a detailed proposal but you get the idea and I think could be 
implemented without too much work. The plus is
that it would be relatively automated without too many false positives.  
Exception cases are ports that "fail" building
but are considered "good."

  * ports that "fail" because they require non-default dependencies (+quartz is 
one class, gtk-osx-application for instance)
  * ports that "fail" because they are meant to (obsolete ports, graveyards)
  * you can probably think of more

Not a really original idea but at least it would be some filter between 
maintainer commits and what the user gets

Dave




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

Re: Apache2 rev bump for OpenSSL update

[Daniel J. Luke]

On Mar 10, 2016, at 3:36 PM, Ryan Schmidt  wrote:
>>> but I'm not sure how to programmatically understand the coding style of a 
>>> given portfile.
>> 
>> It's possible (we load and execute portfiles today).
>> 
>> It would probably be easier if portfiles more consistently kept to key/value 
>> style (or if we didn't use tcl as our parser).
> 
> I don't see how we could possibly change away from tcl at this point.

I guess I'm not making myself clear.

We currently parse portfiles. If we could take the parsed version and write it 
back out, we could reliably do something over many ports. The fact that we 
currently use tcl as the parser isn't entirely relevant (other than it being a 
bunch of work that no one is volunteering for to change that).

We could probably make things easier by setting up some (new) constraints on 
portfiles to make this easier. You're clearly in favor of the arbitrary 
expressiveness of the current way things work, though. I would favor doing 
everything we can to make the Portfile syntax more declarative in all but 
unusual cases.

> If we balk at manually examining 300 portfiles to see if they're already been 
> revbumped for the openssl update, nobody is going to manually examine 10,000 
> portfiles to make them conform to a different parser.

As with everything we release, if it were implemented we would do a 'good 
enough' version and fix things that were broken as people found them (worse is 
better).

Do you have another idea to help automate this? Keeping track of metatdata 
about ports and the dependency tree is something that MacPorts should be able 
to do and we shouldn't have to expect every maintainer to do manually. 

>> distributing software that has known security bugs is a problem.
> 
> We'll have to agree to disagree.

:( tragedy of the commons.

> Most of the complexity comes from supporting more than one version. 
> Supporting more than two versions is no more difficult.

If there were fewer versions, it might not be unduly-burdonsome to just have 
individual portfiles for each version (especially if it solved other problems). 
Of course, there may be some other approach to reducing portfile duplication 
that would leave more simple/structured portfiles that would be easy to 
mass-update (I haven't spent any time thinking about it).

-- 
Daniel J. Luke



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

Re: Apache2 rev bump for OpenSSL update

[Ryan Schmidt]

On Mar 10, 2016, at 2:27 PM, Daniel J. Luke  wrote:
> 
> On Mar 10, 2016, at 3:18 PM, Ryan Schmidt  wrote:
>>> The general problem is something we should address.
>>> 
>>> (a 'compatibility version' we store for ports and make part of the 
>>> dependency engine? a better 'revbump a bunch of ports tool'? something 
>>> else?)
>>> 
>>> We should have a way to reliably force rebuilds
>> 
>> We do: increase the revision.
>> 
>> If you mean we should have a reliable way to programmatically increase the 
>> revision of a port, maybe,
> 
> reliably programmatically increasing the revision is one possible solution to 
> the actual problem (which is "I need to force any ports that depend on my 
> port to rebuild.")
> 
> Today, we do that by increasing the revision of all affected ports (manually, 
> or with some help from a script).
> 
>> but I'm not sure how to programmatically understand the coding style of a 
>> given portfile.
> 
> It's possible (we load and execute portfiles today).
> 
> It would probably be easier if portfiles more consistently kept to key/value 
> style (or if we didn't use tcl as our parser).

I don't see how we could possibly change away from tcl at this point. If we 
balk at manually examining 300 portfiles to see if they're already been 
revbumped for the openssl update, nobody is going to manually examine 10,000 
portfiles to make them conform to a different parser.


 e.g. the php port is definitely a special case.
>>> 
>>> (and is otherwise problematic since it has us distributing versions of php 
>>> that no longer have upstream support)
>> 
>> I don't consider that a problem.
> 
> distributing software that has known security bugs is a problem.

We'll have to agree to disagree. The unsupported php ports print a message that 
they're unsupported. Someone installing an old php port despite those messages 
must really want that version, for example in order to test and perhaps update 
an old web site designed with that version. Removing the old php subports from 
MacPorts just wastes the user's time as the user is forced to manually locate 
and figure out how to patch and compile the old version.


>> The php web site also still distributes versions of php that they no longer 
>> support. In any case it does not relate to the discussion at hand.
> 
> http://php.net/downloads.php lists 7.0.4, 5.6.19, and 5.5.33 (older releases 
> are still there, but with the disclaimer "listed for archival purposes only").

http://museum.php.net

> We can split the thread if you want to discuss further. You're right that 
> it's only tangentially related (the port would be less complicated if it 
> didn't have to support as many php versions).

Not substantially. Most of the complexity comes from supporting more than one 
version. Supporting more than two versions is no more difficult.

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

Re: Checking for problems before committing

[Ryan Schmidt]

On Mar 10, 2016, at 12:48 AM, Mojca Miklavec wrote:

> On 10 March 2016 at 05:48, Ryan Schmidt wrote:
>> 
>> Obviously nobody is going to commit something they believe is broken, but it 
>> does sometimes end up being the case for some subset of users. When it does, 
>> and we learn that it has happened, we try to fix it. If everybody had to 
>> test everything on a clean system on every version of OS X and every version 
>> of Xcode before committing, nobody would ever commit anything because nobody 
>> has the time and resources to do all that testing. We do have automated 
>> build machines that do build every commit on a clean system with no ports 
>> installed with several versions of OS X and the latest version of Xcode for 
>> those systems. That automated system did catch this webkit2-gtk build 
>> problem on El Capitan,
> 
> 
> When I was testing wxWidgets, discovered a problem and submitted a
> patch, I noticed what they are doing now (which is some light years
> more advanced compared to what they did a few years back when most of
> the tickets were stuck ignored at their Trac; similar to what happens
> in many cases in MacPorts).
> 
> - user submits a patch
> - the system checks whether the patch applies cleanly
> - the system automatically builds wxWidgets on Windows in 6 different
> ways (cygwin, mingw32 with msys, mingw, nmake with VS 14, nmake with
> VS 9, msbuild), on Linux in five different ways (one is with clang
> 3.5), and on OS X 10.9
> - I'm not sure whether wxWidgets does it as well, but it is also
> possible to run tests as part of the build
> 
> The developers then only apply the patch if all of the checks mentioned pass.
> 
> The point is that this is all done *in advance* and avoids a lot of
> problems. I would love to see something similar being done for patches
> submitted to our Trac. Of course they would have to be submitted in a
> different way and I'm aware that this is not really trivial to set up.
> But it would be extremely helpful.

Yes, this would be helpful. I intend to look into doing something like this. 
However right now and for the next several weeks there are a lot of other more 
pressing issues I need to be working on for Mac OS Forge.



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

Re: Why is one compiler on 10.6 able to generate PPC binaries and not the other?

[Ryan Schmidt]

> On Mar 10, 2016, at 1:00 PM, Mojca Miklavec  wrote:
> 
> Hi,
> 
> While following
>https://trac.macports.org/wiki/LibcxxOnOlderSystems#Leopardppc
> on 10.6/x86_64 I tried to install clang 3.7 (thinking that version 3.7
> might have an even better support for PPC than 3.6).
> 
> The problem is that clang-mp-3.7 doesn't want to produce ppc binaries,
> so I wasn't able to install libcxx. I get:
> 
>> clang++-mp-3.7 a.cc -arch ppc
> ld: unknown/unsupported architecture name for: -arch ppc
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> 
> At the same time clang++-mp-3.4 works fine even though both clang 3.4
> and 3.7 are x86_64 only.
> 
> I'm now trying to rebuild everything as +universal (with ppc included
> in the list of universal architectures) and hope that it will work
> afterwards. But I would be grateful for ideas about why clang 3.4
> would be able to create ppc binaries and clang 3.7 not.
> 
> Thank you,
>   Mojca
> 
> PS: I'm not actually using the PPC, I'm doing this all for fun and as
> a challenge. But I don't have any VM with 10.5, so I wanted to do the
> cross-compiling step on VM with 10.6.

Maybe:

https://trac.macports.org/changeset/129356



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

Re: Apache2 rev bump for OpenSSL update

[Daniel J. Luke]

On Mar 10, 2016, at 3:18 PM, Ryan Schmidt  wrote:
>> The general problem is something we should address.
>> 
>> (a 'compatibility version' we store for ports and make part of the 
>> dependency engine? a better 'revbump a bunch of ports tool'? something else?)
>> 
>> We should have a way to reliably force rebuilds
> 
> We do: increase the revision.
> 
> If you mean we should have a reliable way to programmatically increase the 
> revision of a port, maybe,

reliably programmatically increasing the revision is one possible solution to 
the actual problem (which is "I need to force any ports that depend on my port 
to rebuild.")

Today, we do that by increasing the revision of all affected ports (manually, 
or with some help from a script).

> but I'm not sure how to programmatically understand the coding style of a 
> given portfile.

It's possible (we load and execute portfiles today).

It would probably be easier if portfiles more consistently kept to key/value 
style (or if we didn't use tcl as our parser).

>>> e.g. the php port is definitely a special case.
>> 
>> (and is otherwise problematic since it has us distributing versions of php 
>> that no longer have upstream support)
> 
> I don't consider that a problem.

distributing software that has known security bugs is a problem.

> The php web site also still distributes versions of php that they no longer 
> support. In any case it does not relate to the discussion at hand.

http://php.net/downloads.php lists 7.0.4, 5.6.19, and 5.5.33 (older releases 
are still there, but with the disclaimer "listed for archival purposes only").

We can split the thread if you want to discuss further. You're right that it's 
only tangentially related (the port would be less complicated if it didn't have 
to support as many php versions).

-- 
Daniel J. Luke



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

Re: Apache2 rev bump for OpenSSL update

[Ryan Schmidt]

On Mar 10, 2016, at 2:15 PM, Daniel J. Luke  wrote:

> On Mar 10, 2016, at 2:05 PM, Ryan Schmidt  wrote:
>>> That's probably safe, but I don't think there is a compelling reason to try 
>>> and only revbump the minimal set of ports (better to have some needless 
>>> rebuilds/downloads of binary archives than to have mysteriously broken 
>>> ports).
>> 
>> You can't programmatically revbump safely,
> 
> with existing tool(s).
> 
>> because in ports with subports you have to manually determine which 
>> subport(s) to revbump and how to do so.
> 
> The general problem is something we should address.
> 
> (a 'compatibility version' we store for ports and make part of the dependency 
> engine? a better 'revbump a bunch of ports tool'? something else?)
> 
> We should have a way to reliably force rebuilds

We do: increase the revision.

If you mean we should have a reliable way to programmatically increase the 
revision of a port, maybe, but I'm not sure how to programmatically understand 
the coding style of a given portfile.


>> e.g. the php port is definitely a special case.
> 
> (and is otherwise problematic since it has us distributing versions of php 
> that no longer have upstream support)

I don't consider that a problem. The php web site also still distributes 
versions of php that they no longer support. In any case it does not relate to 
the discussion at hand.


>> So if you're manually examining all ports that depend on openssl, you can 
>> run an "svn log" on them to see if any commits after r146162 updated the 
>> version or revision.
> 
> ick.

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

Re: port:libclang (and libLLVM)

[Ryan Schmidt]

> On Mar 10, 2016, at 9:26 AM, René J.V. Bertin  wrote:
> 
> On Thursday March 10 2016 10:13:16 Jack Howarth wrote:
> 
>> A simple test with 'sudo port -d -s build llvm-3.8' reveals that -Os
>> is in fact used during the compiles on Intel. This is unsurprising as
>> MacPorts has standardized on -Os.
>> 
>> CFLAGS='-pipe -Os'
>> CXXFLAGS='-pipe -Os -std=c++11 -stdlib=libc++'
>> F90FLAGS='-pipe -Os -m64'
>> FCFLAGS='-pipe -Os -m64'
>> FFLAGS='-pipe -Os'
>> OBJCFLAGS='-pipe -Os'
>> OBJCXXFLAGS='-pipe -Os -stdlib=libc++'
> 
> Did you look at the actual compile commands? Again, cmake is used, and when 
> you generate a makefile with CMAKE_BUILD_TYPE=Release it will *append* the 
> preset compiler options to whatever is fetched from CFLAGS, CXXFLAGS, etc. It 
> is my experience that setting -O3 in CFLAGS or CXXFLAGS has no point, because 
> those presets will override it with -O2 .
> 
> CMake does something similar for all 4 built-in presets, so the only way I 
> know to control the exact compiler flags is to set CMAKE_BUILD_TYPE to a 
> custom value. Debian/Ubuntu do that in their packaging scripts 
> (-DCMAKE_BUILD_TYPE=Debian); I've proposed a modified CMake PortGroup that 
> uses -DCMAKE_BUILD_TYPE=MacPorts (and parses configure.cppflags because CMake 
> doesn't have a dedicated variable for preprocessor options).

If so, that would be yet another bug, or yet another broken-by-design feature, 
of cmake.


> Here's something much more interesting though: I just discovered that llvm 
> and clang 3.8 are both about TEN times smaller than they were in 3.6 and 3.7:
> 
> /opt/local/var/macports/software/llvm-3.6:
> total 158M
> 158M -rw-r--r--1 bertin admin 158M Nov 15 19:10 
> llvm-3.6-3.6.2_2.darwin_13.x86_64.txz
> 
> /opt/local/var/macports/software/llvm-3.7:
> total 188M
> 188M -rw-r--r--1 bertin admin 188M Jan  9 21:11 
> llvm-3.7-3.7.0_0.darwin_13.x86_64.txz
> 
> /opt/local/var/macports/software/llvm-3.8:
> total 15M
> 15M -rw-r--r--1 bertin admin 15M Mar 10 16:08 
> llvm-3.8-3.8-r262722_1.darwin_13.x86_64.txz
> 
> /opt/local/var/macports/software/clang-3.6:
> total 169M
> 169M -rw-r--r--1 bertin admin 169M Nov 15 19:17 
> clang-3.6-3.6.2_2+analyzer.darwin_13.x86_64.txz
> 
> /opt/local/var/macports/software/clang-3.7:
> total 182M
> 182M -rw-r--r--1 bertin admin 182M Jan  9 21:34 
> clang-3.7-3.7.0_2+analyzer.darwin_13.x86_64.txz
> 
> /opt/local/var/macports/software/clang-3.8:
> total 17M
> 17M -rw-r--r--1 bertin admin 17M Mar 10 16:14 
> clang-3.8-3.8-r262722_1+analyzer.darwin_13.x86_64.txz
> 
> 
> What's going on here??
> 
> If that means that building from source also takes comparatively less time 
> and resources I might be inclined to experiment with non-shared builds, or a 
> build without RTTI support (even if that apparently should account for no 
> more than 5% performance loss).

My llvm-3.4 is 436MB, llvm-3.7 765MB. 

I don't know why mine are the size they are and yours are the size they are.

You could untar your llvm-3.7 and llvm-3.7 and compare them to see where the 
size difference lies.

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

Re: Apache2 rev bump for OpenSSL update

[Daniel J. Luke]

On Mar 10, 2016, at 2:05 PM, Ryan Schmidt  wrote:
>> That's probably safe, but I don't think there is a compelling reason to try 
>> and only revbump the minimal set of ports (better to have some needless 
>> rebuilds/downloads of binary archives than to have mysteriously broken 
>> ports).
> 
> You can't programmatically revbump safely,

with existing tool(s).

> because in ports with subports you have to manually determine which 
> subport(s) to revbump and how to do so.

The general problem is something we should address.

(a 'compatibility version' we store for ports and make part of the dependency 
engine? a better 'revbump a bunch of ports tool'? something else?)

We should have a way to reliably force rebuilds

> e.g. the php port is definitely a special case.

(and is otherwise problematic since it has us distributing versions of php that 
no longer have upstream support)

> So if you're manually examining all ports that depend on openssl, you can run 
> an "svn log" on them to see if any commits after r146162 updated the version 
> or revision.

ick.
 
-- 
Daniel J. Luke



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

Re: Apache2 rev bump for OpenSSL update

[Ryan Schmidt]

On Mar 10, 2016, at 12:04 PM, Daniel J. Luke wrote:
> On Mar 10, 2016, at 12:46 PM, Rainer Müller wrote:
>> On 2016-03-10 16:34, Ryan Schmidt wrote:
 The longer we wait, the harder it will be to catch these.
 Should we rev-bump all dependents of OpenSSL now?
>>> 
>>> Those that haven't already had their version or revision increased since 
>>> the openssl update, yes, I would say. 
>> 
>> That is difficult to determine now. To find that out requires going
>> through the list of dependents manually...
>> 
>> I will assume all ports with commits since the OpenSSL update in r146162
>> either already got a rev-bump or a version upgrade, so they do not need
>> it anymore:
> 
> That's probably safe, but I don't think there is a compelling reason to try 
> and only revbump the minimal set of ports (better to have some needless 
> rebuilds/downloads of binary archives than to have mysteriously broken ports).

You can't programmatically revbump safely, because in ports with subports you 
have to manually determine which subport(s) to revbump and how to do so. e.g. 
the php port is definitely a special case. So if you're manually examining all 
ports that depend on openssl, you can run an "svn log" on them to see if any 
commits after r146162 updated the version or revision.

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

Why is one compiler on 10.6 able to generate PPC binaries and not the other?

[Mojca Miklavec]

Hi,

While following
https://trac.macports.org/wiki/LibcxxOnOlderSystems#Leopardppc
on 10.6/x86_64 I tried to install clang 3.7 (thinking that version 3.7
might have an even better support for PPC than 3.6).

The problem is that clang-mp-3.7 doesn't want to produce ppc binaries,
so I wasn't able to install libcxx. I get:

> clang++-mp-3.7 a.cc -arch ppc
ld: unknown/unsupported architecture name for: -arch ppc
clang: error: linker command failed with exit code 1 (use -v to see invocation)

At the same time clang++-mp-3.4 works fine even though both clang 3.4
and 3.7 are x86_64 only.

I'm now trying to rebuild everything as +universal (with ppc included
in the list of universal architectures) and hope that it will work
afterwards. But I would be grateful for ideas about why clang 3.4
would be able to create ppc binaries and clang 3.7 not.

Thank you,
   Mojca

PS: I'm not actually using the PPC, I'm doing this all for fun and as
a challenge. But I don't have any VM with 10.5, so I wanted to do the
cross-compiling step on VM with 10.6.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Daniel J. Luke]

On Mar 10, 2016, at 12:46 PM, Rainer Müller  wrote:
> On 2016-03-10 16:34, Ryan Schmidt wrote:
>>> The longer we wait, the harder it will be to catch these.
>>> Should we rev-bump all dependents of OpenSSL now?
>> 
>> Those that haven't already had their version or revision increased since the 
>> openssl update, yes, I would say. 
> 
> That is difficult to determine now. To find that out requires going
> through the list of dependents manually...
> 
> I will assume all ports with commits since the OpenSSL update in r146162
> either already got a rev-bump or a version upgrade, so they do not need
> it anymore:

That's probably safe, but I don't think there is a compelling reason to try and 
only revbump the minimal set of ports (better to have some needless 
rebuilds/downloads of binary archives than to have mysteriously broken ports).

-- 
Daniel J. Luke



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

Re: Apache2 rev bump for OpenSSL update

[Rainer Müller]

On 2016-03-10 16:34, Ryan Schmidt wrote:
>> The longer we wait, the harder it will be to catch these.
>> Should we rev-bump all dependents of OpenSSL now?
> 
> Those that haven't already had their version or revision increased since the 
> openssl update, yes, I would say. 

That is difficult to determine now. To find that out requires going
through the list of dependents manually...

I will assume all ports with commits since the OpenSSL update in r146162
either already got a rev-bump or a version upgrade, so they do not need
it anymore:

---

# Find ports
for p in $(port -q echo depends_lib:openssl); do
c=$(svn log -r146162:HEAD $(port file $p) |grep -v '^---' |wc -l);
if [ $c -eq 0 ]; then
echo $p;
fi;
done > openssl-revbump.txt

# Rev-bump ports
xargs ./rev-bump.sh < openssl-revbump.txt

# Verify result
svn diff $(xargs port file < openssl-revbump.txt)

---

Committed in r146517.

For future reference, I attached the rev-bump.sh script.

Rainer


rev-bump.sh
Description: Bourne shell script
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: port:libclang (and libLLVM)

[Jack Howarth]

On Thu, Mar 10, 2016 at 10:26 AM, René J.V.  wrote:
> On Thursday March 10 2016 10:13:16 Jack Howarth wrote:
>
>> A simple test with 'sudo port -d -s build llvm-3.8' reveals that -Os
>> is in fact used during the compiles on Intel. This is unsurprising as
>> MacPorts has standardized on -Os.
>>
>> CFLAGS='-pipe -Os'
>> CXXFLAGS='-pipe -Os -std=c++11 -stdlib=libc++'
>> F90FLAGS='-pipe -Os -m64'
>> FCFLAGS='-pipe -Os -m64'
>> FFLAGS='-pipe -Os'
>> OBJCFLAGS='-pipe -Os'
>> OBJCXXFLAGS='-pipe -Os -stdlib=libc++'
>
> Did you look at the actual compile commands? Again, cmake is used, and when 
> you generate a makefile with CMAKE_BUILD_TYPE=Release it will *append* the 
> preset compiler options to whatever is fetched from CFLAGS, CXXFLAGS, etc. It 
> is my experience that setting -O3 in CFLAGS or CXXFLAGS has no point, because 
> those presets will override it with -O2 .


Of course I did...

DEBUG: Executing command line:  cd
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/build"
&& /opt/local/bin/cmake -DCMAKE_INSTALL_PREFIX=/opt/local
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_COLOR_MAKEFILE=ON
-DCMAKE_BUILD_TYPE=Release -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON
-DCMAKE_INSTALL_RPATH=/opt/local/lib
-DCMAKE_INSTALL_NAME_DIR=/opt/local/lib
-DCMAKE_SYSTEM_PREFIX_PATH="/opt/local;/usr"
-DCMAKE_MODULE_PATH=/opt/local/share/cmake/Modules
-DCMAKE_FIND_FRAMEWORK=LAST -Wno-dev -DLLVM_LINK_LLVM_DYLIB=ON
-DCMAKE_INSTALL_PREFIX="/opt/local/libexec/llvm-3.8"
-DLLVM_ENABLE_ASSERTIONS=OFF -DLLVM_ENABLE_RTTI=ON
-DLLVM_INCLUDE_TESTS=OFF -DLLVM_INCLUDE_EXAMPLES=OFF
-DLLVM_ENABLE_FFI=ON -DLLVM_BINDINGS_LIST=none
-DFFI_INCLUDE_DIR=/opt/local/include -DFFI_LIBRARY_DIR=/opt/local/lib
-DCMAKE_C_FLAGS_RELEASE="-DNDEBUG"
-DCMAKE_CXX_FLAGS_RELEASE="-DNDEBUG"
-DCMAKE_OSX_ARCHITECTURES="x86_64"
-DCMAKE_OSX_DEPLOYMENT_TARGET="10.11" -DCMAKE_OSX_SYSROOT="/"
../release_38

[  0%] Building CXX object
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/AsmMatcherEmitter.cpp.o

cd 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/build/utils/TableGen
&& 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
  -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/build/utils/TableGen
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/release_38/utils/TableGen
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/build/include
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/release_38/include
 -pipe -Os -std=c++11 -stdlib=libc++  -fPIC
-fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic
-Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor
-Wdelete-non-virtual-dtor -std=c++11 -DNDEBUG -arch x86_64
-mmacosx-version-min=10.11-fno-exceptions -o
CMakeFiles/obj.llvm-tblgen.dir/AsmMatcherEmitter.cpp.o -c
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/release_38/utils/TableGen/AsmMatcherEmitter.cpp


>
> CMake does something similar for all 4 built-in presets, so the only way I 
> know to control the exact compiler flags is to set CMAKE_BUILD_TYPE to a 
> custom value. Debian/Ubuntu do that in their packaging scripts 
> (-DCMAKE_BUILD_TYPE=Debian); I've proposed a modified CMake PortGroup that 
> uses -DCMAKE_BUILD_TYPE=MacPorts (and parses configure.cppflags because CMake 
> doesn't have a dedicated variable for preprocessor options).
>
> Here's something much more interesting though: I just discovered that llvm 
> and clang 3.8 are both about TEN times smaller than they were in 3.6 and 3.7:
>
> /opt/local/var/macports/software/llvm-3.6:
> total 158M
> 158M -rw-r--r--1 bertin admin 158M Nov 15 19:10 
> llvm-3.6-3.6.2_2.darwin_13.x86_64.txz
>
> /opt/local/var/macports/software/llvm-3.7:
> total 188M
> 188M -rw-r--r--1 bertin admin 188M Jan  9 21:11 
> llvm-3.7-3.7.0_0.darwin_13.x86_64.txz
>
> /opt/local/var/macports/software/llvm-3.8:
> total 15M
> 15M -rw-r--r--1 bertin admin 15M Mar 10 16:08 
> llvm-3.8-3.8-r262722_1.darwin_13.x86_64.txz
>
> /opt/local/var/macports/software/clang-3.6:
> total 169M
> 169M -rw-r--r--1 bertin admin 169M Nov 15 19:17 
> clang-3.6-3.6.2_2+analyzer.darwin_13.x86_64.txz
>
> /opt/local/var/macports/software/clang-3.7:
> total 182M
> 182M -rw-r--r--1 bertin admin 182M Jan  9 21:34 
> clang-3.7-3.7.0_2+analyzer.darwin_13.x86_64.txz
>
> 

Re: Apache2 rev bump for OpenSSL update

[Ryan Schmidt]

On Mar 10, 2016, at 09:14, Rainer Müller  wrote:
> 
>> On 2016-03-03 02:40, Ryan Schmidt wrote:
>> I consider it the responsibility of the committer who updated the
>> openssl port to the version that changed its library ABI to revbump
>> the ports that link with it, regardless of maintainer status. It
>> should have been done at the same time that openssl was updated of
>> course. I'm not working on it so someone else is welcome to do it.
> 
> I still see related errors such as this one:
> 
> $ sudo gem install
> ERROR:  Loading command: install (LoadError)
>dlopen(/opt/local/lib/ruby2.0/2.0.0/x86_64-darwin14/openssl.bundle, 9):
> Symbol not found: _SSLv2_client_method
>  Referenced from:
> /opt/local/lib/ruby2.0/2.0.0/x86_64-darwin14/openssl.bundle
>  Expected in: /opt/local/lib/libssl.1.0.0.dylib
> in /opt/local/lib/ruby2.0/2.0.0/x86_64-darwin14/openssl.bundle -
> /opt/local/lib/ruby2.0/2.0.0/x86_64-darwin14/openssl.bundle
> ERROR:  While executing gem ... (NoMethodError)
>undefined method `invoke_with_build_args' for nil:NilClass
> 
> 
> The longer we wait, the harder it will be to catch these.
> Should we rev-bump all dependents of OpenSSL now?

Those that haven't already had their version or revision increased since the 
openssl update, yes, I would say. 

> Is it already too late and we fix them case-by-case?

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

Re: port:libclang (and libLLVM)

[René J . V . Bertin]

On Thursday March 10 2016 10:13:16 Jack Howarth wrote:

> A simple test with 'sudo port -d -s build llvm-3.8' reveals that -Os
> is in fact used during the compiles on Intel. This is unsurprising as
> MacPorts has standardized on -Os.
> 
> CFLAGS='-pipe -Os'
> CXXFLAGS='-pipe -Os -std=c++11 -stdlib=libc++'
> F90FLAGS='-pipe -Os -m64'
> FCFLAGS='-pipe -Os -m64'
> FFLAGS='-pipe -Os'
> OBJCFLAGS='-pipe -Os'
> OBJCXXFLAGS='-pipe -Os -stdlib=libc++'

Did you look at the actual compile commands? Again, cmake is used, and when you 
generate a makefile with CMAKE_BUILD_TYPE=Release it will *append* the preset 
compiler options to whatever is fetched from CFLAGS, CXXFLAGS, etc. It is my 
experience that setting -O3 in CFLAGS or CXXFLAGS has no point, because those 
presets will override it with -O2 .

CMake does something similar for all 4 built-in presets, so the only way I know 
to control the exact compiler flags is to set CMAKE_BUILD_TYPE to a custom 
value. Debian/Ubuntu do that in their packaging scripts 
(-DCMAKE_BUILD_TYPE=Debian); I've proposed a modified CMake PortGroup that uses 
-DCMAKE_BUILD_TYPE=MacPorts (and parses configure.cppflags because CMake 
doesn't have a dedicated variable for preprocessor options).

Here's something much more interesting though: I just discovered that llvm and 
clang 3.8 are both about TEN times smaller than they were in 3.6 and 3.7:

/opt/local/var/macports/software/llvm-3.6:
total 158M
158M -rw-r--r--1 bertin admin 158M Nov 15 19:10 
llvm-3.6-3.6.2_2.darwin_13.x86_64.txz

/opt/local/var/macports/software/llvm-3.7:
total 188M
188M -rw-r--r--1 bertin admin 188M Jan  9 21:11 
llvm-3.7-3.7.0_0.darwin_13.x86_64.txz

/opt/local/var/macports/software/llvm-3.8:
total 15M
15M -rw-r--r--1 bertin admin 15M Mar 10 16:08 
llvm-3.8-3.8-r262722_1.darwin_13.x86_64.txz

/opt/local/var/macports/software/clang-3.6:
total 169M
169M -rw-r--r--1 bertin admin 169M Nov 15 19:17 
clang-3.6-3.6.2_2+analyzer.darwin_13.x86_64.txz

/opt/local/var/macports/software/clang-3.7:
total 182M
182M -rw-r--r--1 bertin admin 182M Jan  9 21:34 
clang-3.7-3.7.0_2+analyzer.darwin_13.x86_64.txz

/opt/local/var/macports/software/clang-3.8:
total 17M
17M -rw-r--r--1 bertin admin 17M Mar 10 16:14 
clang-3.8-3.8-r262722_1+analyzer.darwin_13.x86_64.txz


What's going on here??

If that means that building from source also takes comparatively less time and 
resources I might be inclined to experiment with non-shared builds, or a build 
without RTTI support (even if that apparently should account for no more than 
5% performance loss).

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

Re: Apache2 rev bump for OpenSSL update

[Rainer Müller]

On 2016-03-03 02:40, Ryan Schmidt wrote:
> I consider it the responsibility of the committer who updated the
> openssl port to the version that changed its library ABI to revbump
> the ports that link with it, regardless of maintainer status. It
> should have been done at the same time that openssl was updated of
> course. I'm not working on it so someone else is welcome to do it.

I still see related errors such as this one:

$ sudo gem install
ERROR:  Loading command: install (LoadError)
dlopen(/opt/local/lib/ruby2.0/2.0.0/x86_64-darwin14/openssl.bundle, 9):
Symbol not found: _SSLv2_client_method
  Referenced from:
/opt/local/lib/ruby2.0/2.0.0/x86_64-darwin14/openssl.bundle
  Expected in: /opt/local/lib/libssl.1.0.0.dylib
 in /opt/local/lib/ruby2.0/2.0.0/x86_64-darwin14/openssl.bundle -
/opt/local/lib/ruby2.0/2.0.0/x86_64-darwin14/openssl.bundle
ERROR:  While executing gem ... (NoMethodError)
undefined method `invoke_with_build_args' for nil:NilClass


The longer we wait, the harder it will be to catch these.
Should we rev-bump all dependents of OpenSSL now?
Is it already too late and we fix them case-by-case?

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

Re: port:libclang (and libLLVM)

[Jack Howarth]

On Thu, Mar 10, 2016 at 7:33 AM, René J.V.  wrote:
> On Wednesday March 09 2016 20:48:19 Jack Howarth wrote:
>>> Why? My understanding is that the optimizations for -Os are equivalent
>>> to -O2 with the emphasis on size reduction. The additional
>>> optimizations from -O2 to -O3 would seem sufficient to produce a 10%
>>> execution optimization, no?
>>
>
> Actually, this point is moot : -Os is used only on PPC machines from what I 
> can see. Other architectures use whatever optimisation the build system 
> decides to use (which is an interesting question when that system is based on 
> CMake and you use one of the built-in BUILD_TYPE presets).
>

A simple test with 'sudo port -d -s build llvm-3.8' reveals that -Os
is in fact used during the compiles on Intel. This is unsurprising as
MacPorts has standardized on -Os.

CFLAGS='-pipe -Os'
CXXFLAGS='-pipe -Os -std=c++11 -stdlib=libc++'
F90FLAGS='-pipe -Os -m64'
FCFLAGS='-pipe -Os -m64'
FFLAGS='-pipe -Os'
OBJCFLAGS='-pipe -Os'
OBJCXXFLAGS='-pipe -Os -stdlib=libc++'


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

Re: Checking for problems before committing

[Brandon Allbery]

On Thu, Mar 10, 2016 at 1:48 AM, Mojca Miklavec  wrote:

>
> When I was testing wxWidgets, discovered a problem and submitted a
> patch, I noticed what they are doing now (which is some light years
> more advanced compared to what they did a few years back when most of
> the tickets were stuck ignored at their Trac; similar to what happens
> in many cases in MacPorts).


Much of this now comes "for free" with github these days; just create a
data file in the repo with config information and add some "canned" commit
triggers. Apple/MacOSForge has the infrastructure but not the connections
you'd need to automate it quickly and cleanly.

(No, moving to github would not help us. They can build on El Cap only ---
and that service often simply disappears since Travis CI only offers the
free github service when they have spare capacity, and unlike the other
platforms they must use dedicated Apple hardware for the build slaves --
this due to Apple licensing. So there's a limited number of OS X
buildslaves, and if they're all in use for the commercial Travis customers
the free service on OS X gets dropped.)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Checking for problems before committing

[Bachsau]

> Am 10.03.2016 um 07:48 schrieb Mojca Miklavec :
> 
> The point is that this is all done *in advance* and avoids a lot of
> problems. I would love to see something similar being done for patches
> submitted to our Trac. Of course they would have to be submitted in a
> different way and I'm aware that this is not really trivial to set up.
> But it would be extremely helpful.

Well, I think that would be a great way to handle submissions. As MacPorts 
already has automated build systems able to check if a build succeeds, it might 
be not that hard to implement. I think its most important a port is always 
working on the latest OS version, which currently is El Capitan. However, when 
I opened this thread I wasn't aware there's a ticket system. Now posted a 
ticket with all the requested information for libbonoboui which also fails to 
build on my system with a similar error. Lets see what happens…

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: port:libclang (and libLLVM)

[René J . V . Bertin]

On Wednesday March 09 2016 20:48:19 Jack Howarth wrote:
>> Why? My understanding is that the optimizations for -Os are equivalent
>> to -O2 with the emphasis on size reduction. The additional
>> optimizations from -O2 to -O3 would seem sufficient to produce a 10%
>> execution optimization, no?
>

Actually, this point is moot : -Os is used only on PPC machines from what I can 
see. Other architectures use whatever optimisation the build system decides to 
use (which is an interesting question when that system is based on CMake and 
you use one of the built-in BUILD_TYPE presets).

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

Re: port:libclang (and libLLVM)

[René J . V . Bertin]

On Wednesday March 09 2016 20:48:19 Jack Howarth wrote:

>>> Frankly I'd be surprised if that leads to a 10% performance difference!
>>
>> Why? My understanding is that the optimizations for -Os are equivalent
>> to -O2 with the emphasis on size reduction. The additional
>> optimizations from -O2 to -O3 would seem sufficient to produce a 10%
>> execution optimization, no?

I think it's an accepted truth that using -O3 instead of -O2 rarely gives that 
kind of performance benefit, and that it's rather something that you'd reserve 
for cases where every percent gained counts (and you don't care about code 
size). That's speaking in general of course. AFAIK, -O3 also activates 
auto-vectorisation and that can indeed make a huge difference. Except of course 
the performance you can gain with that is rarely in algorithms that are the 
real performance bottleneck. A compiler is not the kind of application in which 
I'd expect to get a lot of benefit from auto-vectorisation.
There's one compiler option that has given me really surprising gains in the 
past (on top of -O2+ that is): -mdynamic-no-pic . I've seen that give 15% 
performance increases (thanks once more to Shark for pointing out the option). 
Of course that was on 32bit PPC hosts. I've never measured the option's effect 
on x86 and given how on x86_64 it can even be used for relocatable code (shared 
libraries) I tend to expect that it will no longer make much of a difference.

>The only other difference I see between the fink and MacPorts
>packaging is the use of -DLLVM_ENABLE_RTTI=ON in MacPorts. My
>understanding is that these additional virtual functions can introduce
>overhead in c++.

Yes, you're probably right. Combined with the (supposed) additional overhead of 
using a shared libLLVM that could well add up to the performance differences 
I've seen.
Except that I don't know if Apple build with LLVM_ENABLE_RTTI=ON or not; I've 
never compared Fink's clang builds.

R

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