Re: Consequences of using MacPorts GCC as a fallback compiler on PowerPC

[Ryan Schmidt]

On Mar 22, 2018, at 20:23, Kenneth F. Cunningham wrote:

> On 2018-03-22, at 5:11 PM, Ryan Schmidt wrote:
> 
>> There are already ports out there, and installed on user systems, and 
>> binaries being distributed that were built by our buildbot, that were built 
>> with a MacPorts gcc without -D_GLIBCXX_USE_CXX11_ABI=0 set. These would be 
>> ports that do not use the cxx11 1.1 portgroup and that don't use C++11. 
> 
> I can't help but think that any ports where the change in LIBCXX ABI was an 
> issue have been identified as build failures on the buildbots < 10.9, and the 
> cxx11 1.1 PG was added.
> 
> Any of the very few others I might have upgraded separately to build with 
> gcc6 on PPC for C11 or other reasons, aren't using the changed c++11 features 
> of libstdc++ anyway, or they would be in the cxx11 1.1 PG.
> 
> So - do they all really need to be rebuilt? I'm trying to think if there are 
> any cases of incompatibility that might slip through this logic, and none are 
> coming to mind just now….

I am not talking about ports that require C++11 which are already using the 
cxx11 1.1 portgroup which forces the use of the old ABI.

I am talking about ports that do not require C++11, but which are configured to 
build using a MacPorts gcc for whatever reason, and which therefore at present 
are using the new ABI.


To get a list of portfiles that explicitly set the compiler to a MacPorts gcc, 
run:

port file all|sort -u|xargs grep -l 'configure\.compiler.*macports-gcc'

Not all of these use C++. Many of them may be doing this because they contain 
Fortran or Java code.

But gigabase, for example, mentions C++ in its description.


For a list of portfiles that use the compilers 1.0 portgroup, which creates 
compiler variants, which might include gcc variants if requested by the port, 
run:

port file all|sort -u|xargs grep -l 'PortGroup.*compilers.*1\.0'

Again probably not all of these contain C++ code, but I'll bet some of them do.

Re: Consequences of using MacPorts GCC as a fallback compiler on PowerPC

[Kenneth F. Cunningham]

On 2018-03-22, at 5:11 PM, Ryan Schmidt wrote:


> There are already ports out there, and installed on user systems, and 
> binaries being distributed that were built by our buildbot, that were built 
> with a MacPorts gcc without -D_GLIBCXX_USE_CXX11_ABI=0 set. These would be 
> ports that do not use the cxx11 1.1 portgroup and that don't use C++11. 

I can't help but think that any ports where the change in LIBCXX ABI was an 
issue have been identified as build failures on the buildbots < 10.9, and the 
cxx11 1.1 PG was added.

Any of the very few others I might have upgraded separately to build with gcc6 
on PPC for C11 or other reasons, aren't using the changed c++11 features of 
libstdc++ anyway, or they would be in the cxx11 1.1 PG.

So - do they all really need to be rebuilt? I'm trying to think if there are 
any cases of incompatibility that might slip through this logic, and none are 
coming to mind just now….

Ken

Consequences of using MacPorts GCC as a fallback compiler on PowerPC

[Ryan Schmidt]

Ken recently changed the compiler fallbacks for old systems to remove Xcode's 
gcc-3.3 entirely (presumably on the grounds that anything old enough to require 
it could just specify "configure.compiler gcc-3.3", as ports like anubis and 
stegdetect already do), and more importantly to add macports-gcc-6 and 
macports-gcc-7 when on PowerPC (instead of macports-clang-3.3 or 
macports-clang-3.4 which are now used only on Intel since clang does not work 
on PowerPC).

https://github.com/macports/macports-base/pull/62

I am concerned that this breaks C++ ports on PowerPC, and wrote this comment on 
the PR today:

> Ryan wrote:

> 

>> Doesn't this break C++ ports on PowerPC? You cannot share objects between 
>> C++ libraries; you will crash if you try. And this change makes it so that 
>> some ports (for example some library foolib) might compile with 
>> /usr/bin/g++-4.2 (and link with /usr/lib/libstdc++.6.dylib) as they did 
>> before, while ports that blacklist old GCC (for example a program barprog 
>> that uses the aforementioned library) might compile with 
>> /opt/local/bin/g++-mp-6 (and link with /opt/local/lib/libstdc++.6.dylib). 
>> When the barprogprogram allocates a C++ object using 
>> /usr/lib/libstdc++.6.dylib and passes it to the foolib library, and it tries 
>> to work with that object using /opt/local/lib/libstdc++.6.dylib, it will 
>> crash.
>> 
>> We have had a longstanding policy of not using FSF GCC as a general purpose 
>> compiler for exactly this reason and I'm very nervous not only about this 
>> change in general but also that this change was immediately merged to the 
>> stable 2.4 branch.
>> 
>> The only reason why we're able to use gcc6's C++ compiler in the cxx11 1.1 
>> portgroup is that we also put -D_GLIBCXX_USE_CXX11_ABI=0 into CXXFLAGS. 
>> Don't we need to do that in MacPorts base now as well, when macports-gcc-6 
>> is chosen due to the above changes (but not when it is chosen in any other 
>> existing way, as that would break all the ports that explicitly use gcc6 
>> today)? And if so, how do we do that?

Ken replied by private email, and subsequently gave me permission to share his 
reply on this list:

Ken wrote:

> Happy to work through this and any similar concerns with you.
> 
> The existing situation for 10.4 and 10.5 PPC was that if gcc-4* series was 
> blacklisted, then clang-3.4 was chosen, and this always failed. So that was 
> no good, and there are - how many - dozens of open tickets about this? So 
> gcc6 and gcc7 are the only other compilers available to use at present, and 
> we had to go down this road to fix this up.
> 
> You are correct that this might surreptitiously build c++11 software with the 
> wrong c++11ABI selected, if the port blacklisting lead to gcc6 being used and 
> if the port author didn't add the c++11 PortGroup to add the flag.  There is 
> really only a small subset of the c++11 ABI affected by this, but it could 
> happen.
> 
> 
> 
> To fix that, we could indeed always add -D_GLIBCXX_USE_CXX11_ABI=0 into 
> CXXFLAGS. on PPC if gcc6+ was being used. I would be in favour of that, and 
> as far as I can tell, there is nothing could break from doing that. 
> 
> c++11 software on PPC should ALWAYS by default be compiled in ABI4 compatible 
> mode. I fully agree. There is no situation I can think of where it should 
> ever be otherwise. I am happy to add that bit to portconfigure.tcl if we find 
> that acceptable. 
> 
> 
> There is another (in my opinion simpler and better) way to accomplish the 
> same end, and this is what the linux distros did that wanted to accomplish 
> this feat of mixing pre-ABI-5 software and post-ABI-5 software ...
> 
> Build libgcc to default into ABI4-compatible mode always.  This is done with 
> this flag when building libgcc:
> 
> configure.args-append --with-default-libstdcxx-abi=gcc4-compatible
> 
> Then all software that links against that library is in ABI4-compatible mode 
> always (unless you force it otherwise), which is exactly what you want, and 
> if that is deemed the better approach, I would be in favour of putting 
> something like this in the libgcc Portfile:
> 
> platform darwin powerpc {
> default_variants-append +defaultabi4
> }
> variant defaultabi4 description "use gcc4 compatible ABI" {
> configure.args-append --with-default-libstdcxx-abi=gcc4-compatible
> }
> 
> 
> The advantage to that is:
> 1. works on software that doesn't necessarily always respect the cxxflags 
> correctly.
> 2. most likely never need think about it again
> 3. could potentially be overridden by an individual port by adding 
> -D_GLIBCXX_USE_CXX11_ABI=1  if there was ever a reason to do that (that I 
> can't think of just now).
> 
> 
> After that, we just need to go through all the Portfiles and change the 
> blacklisting from *gcc* to *gcc-4* and we should be in business.


The documentation says:

https://gcc.gnu.org/onlinedocs/gcc-5.2.0/libstdc++/manual/manual/using_dual_abi.html

> Although the changes were 

Getting a list of all portfiles

[Ryan Schmidt]

It used to be straightforward to get a list of all portfiles:

port file all

But ever since the introduction of subports, that list might now contain 
duplicates (one for each subport a port has). So now I've been running:

port file all|sort -u

which is a little more tedious. Is this the best way to do it or is there a 
shortcut?

Is there some MacPorts pseudoport like "all" but that means "all ports that are 
not subports"? Or, perhaps useful in other situations, a pseudoport that means 
"all ports that are subports"?

Re: [macports-ports] branch master updated: inspectrum: new port

[Ryan Schmidt]

On Mar 22, 2018, at 15:16, Michael Dickens wrote:

> OK; guess I didn't follow the cmake 1.1 discussion (somehow).
> 
> So for current ports that use cmake 1.0, updating looks to involve 2 parts:
> 
> 1) "1.0" -> "1.1"
> 2) remove the "cmake.out_of_source yes" line and comment.
> 
> Initial testing looks like that's all I need to do. Does that sound correct? 
> - MLD

It depends on the port, of course. If the port is overriding cmake variables 
for which the cmake 1.0 portgroup did not provide MacPorts-specific options, 
and for which the cmake 1.1 portgroup does, then the port should also switch to 
using the MacPorts-specific options. You can diff the cmake 1.0 and 1.1 
portgroup files to see all that has changed.

Re: [macports-ports] branch master updated: inspectrum: new port

[Michael Dickens]

OK; guess I didn't follow the cmake 1.1 discussion (somehow).

So for current ports that use cmake 1.0, updating looks to involve 2 parts:

1) "1.0" -> "1.1"
2) remove the "cmake.out_of_source yes" line and comment.

Initial testing looks like that's all I need to do. Does that sound correct? - 
MLD

On Wed, Mar 21, 2018, at 6:33 PM, Ryan Schmidt wrote:
> On Mar 21, 2018, at 16:46, Michael Dickens wrote:
> > +PortGroup   cmake 1.0
> 
> > +# do VPATH (out of source tree) build
> > +
> > +cmake.out_of_source yes
> 
> New ports (and old ports, as time permits) should use the cmake 1.1 
> portgroup instead of the cmake 1.0 portgroup. cmake 1.1 defaults to out 
> of source builds, and has other improvements.

Gsoc 18 Project | Collect build statistics

[Vishnu]

Hello all,

Thanks for rectifying the mail issues.

This is Vishnu.
I would Like to participate in GSOC 18 .And would like to work on :
#Collect build statistics
I needed some help in understanding the idea a bit more.
i wanted to understand the idea more deeply.
Can someone elaborate the idea more?

How many web pages do we need to make ?
Can i get some sample structure of webpage for 1 port . what all need to be
there.
Also where to get : collect per-port statistics & success matrix .Can i get
the exact sample link?




I really think this is the project i could work on because i have prior
experience with all the languages required for this project (HTML, Python,
javascript, in fact, did my last intern mainly involving JSON).
I also have good experience in web Scraping.

I am well aware about :
JSON
Html
Css
Python
JAVASCRIPT
Basic idea about perl

Have used macOS.
Access to macos during gsoc would be limited. But possible.
I have certain knowledge of macports too.


Thanks
Vishnu

app PortGroup enhancements, and request for someone to test with +quartz variant for a few gtk apps

[Kenneth F. Cunningham]

Hello,

With Ryan's help we've made two enhancements to the app PortGroup

1. an optional bash launch script that doesn't pass -psn, and sets up the PATH 
prior to launch

options app.use_launch_script 
default app.use_launch_script  no

2. an option to hide the sometimes forever bouncing dock icon

options app.hide_dock_icon 
default app.hide_dock_icon  no


With this, many gtk2 and gtk3 apps could now have nice launchable bundles if 
desired. They usually already have the icons in the distfiles, so it's quite 
easy to set up (mods for qalculate-gtk and pan2 listed at bottom).

For the +x11 versions, you would want both of these options to be "yes" if gtk2 
and gtk3 are installed as +x11.

I don't use the +quartz versions much and would appreciate a bit of testing 
from someone.

I think you'd want the launch_script option, but the icon should stop bouncing 
for a +quartz app (I hope) so perhaps the icon doesn't need to be hidden.

Please send some feedback once you've tested one or two +quartz variants of 
apps so we can see what the best defaults should be for those!

Thanks,

Ken


mods to Portfile for qalculate-gtk (Overrides app.name, hides dock icon, uses 
launch script):

PortGroup   app 1.0

app.nameQalculate!
app.icondata/qalculate.png
app.hide_dock_icon  yes
app.use_launch_script yes


mods to Portfile for pan2 (Overrides app.name, app.executable, hides dock icon, 
uses launch script):

PortGroup   app 1.0

app.namePan
app.executable  pan
app.iconpan/icons/icon_pan_about_logo.png
app.hide_dock_icon  yes
app.use_launch_script yes

Re: GSoC-Announcements distributed over the ports tree

[Rainer Müller]

On 2018-03-22 10:57, Abhishek Kashyap wrote:
> Can I use Itcl script for using object oriented features?

At the moment, itcl is not used anywhere in base and not shipped with
MacPorts. Tcl and its packages shipped with base can be found in the
vendor directory:

https://github.com/macports/macports-base/tree/master/vendor

For object-oriented programming I think it would be better to look into
TclOO, as that was merged into Tcl 8.6 and is available as a package for
Tcl 8.5, which we are still using. However, I have never used any of
these, so I cannot compare their style.

Rainer

Re: GSoC-Announcements distributed over the ports tree

[Abhishek Kashyap]

Can I use Itcl script for using object oriented features?

On 22 March 2018 at 14:56, Abhishek Kashyap 
wrote:

> hey
> What are the package require for building Port news items?I have to
> implement the code in tcl.that's why i 'm asking.
>