Fwd: GIMP | Argument -Wimplicit-function-declaration incompatible with Mac M1 arm64? (#6954)

[Peter West]

As advised by some previous messages regarding -Wimplicit-function-declaration, 
I reported this to Gimp bugs, and I received the reply below.

As mentioned in the response, gimp2 built for me, but hung on startup.

There’s a question here about the use of gimp-macos-build scripts and jhbuild, 
which I cannot answer.

Should this question go onto the dev list?

I am reluctant to get into the weeds of the gimp build, as I’ve never built 
anything complex on Mac before, but if no-one else is in a position to do so, I 
may have to. Any other M1 users who would like to see Gimp native, please put 
your hand up.


—
Peter West
p...@ehealth.id.au
“…whoever says, ‘You fool!’ will be liable to the hell of fire.”

> Begin forwarded message:
> 
> From: "Jehan (@Jehan)" 
> Subject: Re: GIMP | Argument -Wimplicit-function-declaration incompatible 
> with Mac M1 arm64? (#6954)
> Date: 10 June 2021 at 5:28:42 pm AEST
> To: p...@pbw.id.au
> Reply-To: GNOME / GIMP 
> 
> 
> Jehan  commented 
> :
> 
> Hi @p-b-west  !
> 
> The build log includes this warning. Warning: Configuration logfiles contain 
> indications of -Wimplicit-function-declaration; check that features were not 
> accidentally disabled: strchr: found in gimp-2.10.22/config.log finite: found 
> in gimp-2.10.22/config.log
> 
> Well you are our best bet to find the solution to this! Most of devs here 
> don't use macOS which is why we have a hard time even providing the non-M1 
> build, even less the M1 one! 😕
> 
> In any case, yes there are a bunch of strchr in the code (both core and in 
> plug-ins, as can be checked by a grep through code), so if it turns out this 
> function is not available/disabled or that something needs to be done to have 
> it on the build, you'd be the best fit to investigate it, especially since 
> you at least got a first build to complete!
> 
> The other people who worked on a macOS build and who may be able to help are: 
> @samm-git  and @DesMcGuinness 
>  (for the main macOS build) and 
> @evultrole  who worked on the M1 build, 
> though I don't know what the status is now (see #5288 
> ).
> 
> By the way, does the MacPorts build use our gimp-macos-build scripts with 
> jhbuild? Something different? Because obviously we are particularly 
> interested to also have a working upstream M1 build!
> 
> — 
> Reply to this email directly or view it on GitLab 
> . 
> You're receiving this email because you have been mentioned on 
> gitlab.gnome.org . If you'd like to receive fewer 
> emails, you can unsubscribe 
> 
>  from this thread or adjust your notification settings.
> 

Re: Why don't p5-* ports mark their dependencies?

[Ryan Schmidt]

On Jun 6, 2021, at 12:41, Bill Cole wrote:

> Not sure where the bug is here, but it's evident in 'port reclaim'.
> 
> The p5-* ports are basically placeholders for the p5.##- ports. I *think* 
> I've even worked out the right way to use that construct to make Perl 
> upgrades simpler, so I use the p5-* ports:
> 
>   $ sudo port install p5-net-cidr p5-term-readline p5-test-fatal
>   --->  Computing dependencies for p5-net-cidr
>   The following dependencies will be installed:  p5.30-net-cidr
>   Continue? [Y/n]: y
>   --->  Fetching archive for p5.30-net-cidr
>   --->  Attempting to fetch 
> p5.30-net-cidr-0.200.0_0.darwin_18.noarch.tbz2 from 
> https://ywg.ca.packages.macports.org/mirror/macports/packages/p5.30-net-cidr
>   --->  Attempting to fetch 
> p5.30-net-cidr-0.200.0_0.darwin_18.noarch.tbz2.rmd160 from 
> https://ywg.ca.packages.macports.org/mirror/macports/packages/p5.30-net-cidr
>   --->  Installing p5.30-net-cidr @0.200.0_0
>   --->  Activating p5.30-net-cidr @0.200.0_0
>   --->  Cleaning p5.30-net-cidr
>   --->  Cleaning p5-net-cidr
>   --->  Computing dependencies for p5-term-readline
>   The following dependencies will be installed:  p5.30-term-readline
>   Continue? [Y/n]: y
>   --->  Fetching archive for p5.30-term-readline
>   --->  Attempting to fetch 
> p5.30-term-readline-1.140.0_0.darwin_18.noarch.tbz2 from 
> https://ywg.ca.packages.macports.org/mirror/macports/packages/p5.30-term-readline
>   --->  Attempting to fetch 
> p5.30-term-readline-1.140.0_0.darwin_18.noarch.tbz2.rmd160 from 
> https://ywg.ca.packages.macports.org/mirror/macports/packages/p5.30-term-readline
>   --->  Installing p5.30-term-readline @1.140.0_0
>   --->  Activating p5.30-term-readline @1.140.0_0
>   --->  Cleaning p5.30-term-readline
>   --->  Cleaning p5-term-readline
>   --->  Computing dependencies for p5-test-fatal
>   The following dependencies will be installed:  p5.30-test-fatal
>   Continue? [Y/n]: y
>   --->  Fetching archive for p5.30-test-fatal
>   --->  Attempting to fetch 
> p5.30-test-fatal-0.16.0_0.darwin_18.noarch.tbz2 from 
> https://ywg.ca.packages.macports.org/mirror/macports/packages/p5.30-test-fatal
>   --->  Attempting to fetch 
> p5.30-test-fatal-0.16.0_0.darwin_18.noarch.tbz2.rmd160 from 
> https://ywg.ca.packages.macports.org/mirror/macports/packages/p5.30-test-fatal
>   --->  Installing p5.30-test-fatal @0.16.0_0
>   --->  Activating p5.30-test-fatal @0.16.0_0
>   --->  Cleaning p5.30-test-fatal
>   --->  Cleaning p5-test-fatal
>   --->  Scanning binaries for linking errors
>   --->  No broken files found.
>   --->  No broken ports found.
> 
> Perfectly normal, right?
> 
> However, immediately after doing that, I did a reclaim and got a surprise:
> 
>   $ sudo port -v reclaim
>   --->  Checking for unnecessary unrequested ports
>   Unrequested ports without requested dependents found:
>p5.30-test-fatal  @0.16.0_0
>p5.30-net-cidr  @0.200.0_0
>p5.30-term-readline  @1.140.0_0
>   Would you like to uninstall them? [Y/n]: n
> 
> And the dependency map is not reversible:
> 
>   $ port deps p5-net-cidr
>   Full Name: p5-net-cidr @0.200.0_0
>   Library Dependencies: p5.30-net-cidr
>   $ port rdependents p5.30-net-cidr
>   p5.30-net-cidr has no dependents.

Yes, the p5 ports are a bit weird in that regard. The p5-* ports can be 
installed -- they install essentially nothing (a placeholder text file) 
themselves but depend on e.g. the corresponding p5.30-* port which then gets 
installed. But also, the p5-* ports are marked as being replaced_by the 
corresponding p5.30-* port. This is unusual. Normally, when a port uses the 
replaced_by feature, the port also prevents itself from being able to be 
installed. The php-* and python-* ports do not use the replaced_by feature in 
this way; maybe the p5-* ports shouldn't do that either. Maybe that would cure 
the issue you observed.

Re: Warning: Configuration logfiles contain indications of -Wimplicit-function-declaration

[Ryan Schmidt]

On Jun 8, 2021, at 04:27, Michael Newman wrote:

> Today I finally installed Big Sur and followed the MacPorts migration guide. 
> I don't see any errors; no failures to build. However, I did get seven of 
> these warnings:
> 
> Warning: Configuration logfiles contain indications of 
> -Wimplicit-function-declaration; check that features were not accidentally 
> disabled:
> 
> It was found in the following logs:
> 
> lynx2.8.9rel.1/config.log
> clamav-0.103.2/config.log
> anholt-libepoxy-d51a358/config.log
> ghostpdl-9.54.0/config.log
> graphviz-2.40.1/config.log
> gst-libav-1.16.2/config.log
> gst-plugins-bad-1.16.2/config.log
> 
> I have no idea what a "Wimplicit-function-declaration" is. I tried to search 
> around, but was unable to enlighten myself. I gather it has something to do 
> with C; about which I know nothing. If this warning is explained somewhere, 
> please provide me with a link.
> 
> Do I need to do something about these, or are they ignorable?

Each occurrence must be investigated and handled individually. File bug reports.

Re: cdrtools streamripper

[Chris Jones]

> On 10 Jun 2021, at 9:05 am, Giuseppe Di Matteo  
> wrote:
> 
> I opened ticket #63062.
> What about streamripper. Configure failed for libmad. (Big Sur arm64)

Same. Check for and if need be open tickets against failing ports.

> 
> Pino Di Matteo
> pinodimat...@me.com
> 
> 
> 
>> Le 9 juin 2021 à 11:04, Christopher Jones  a écrit 
>> :
>> 
>> 
>> Please check for an open trac ticket, and if one does not exist open one.
>> 
>>> On 9 Jun 2021, at 9:47 am, Giuseppe Di Matteo  
>>> wrote:
>>> 
>>> I made the change in the Portfile, but it still won’t install. It seems 
>>> that the problem is now with the arch arm64 (Mac mini M1).
>>> Giuseppe Di Matteo
>>> pinodimat...@me.com
>>> 
>>> 
>>> 
>>> 
>>> 
 Le 8 juin 2021 à 20:48, Christopher Jones  a 
 écrit :
 
 
 For the smake issue see
 
 https://github.com/macports/macports-ports/commit/9040f7195e114173a42c71ee57e74c248ef7ebb1
 
> On 7 Jun 2021, at 5:15 pm, Andrew Udvare  wrote:
> 
> 
>> On 2021-06-07, at 09:34, Giuseppe Di Matteo via macports-users 
>>  wrote:
>> 
>> I can’t install cdrtools and streamripper on macOS 11 (Big Sur).
>> 
>> Giuseppe Di Matteo
>> pinodimat...@me.com
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> I can reproduce the issue with cdrtools. `smake` does not accept -j.
> 
> I cannot reproduce the issue with streamripper. streamripper builds for 
> me. However, I am on x86-64.
 
>>> 
>> 
> 

Re: cdrtools streamripper

[Giuseppe Di Matteo via macports-users]

I opened ticket #63062.
What about streamripper. Configure failed for libmad. (Big Sur arm64)

Pino Di Matteo
pinodimat...@me.com



> Le 9 juin 2021 à 11:04, Christopher Jones  a écrit :
> 
> 
> Please check for an open trac ticket, and if one does not exist open one.
> 
>> On 9 Jun 2021, at 9:47 am, Giuseppe Di Matteo > > wrote:
>> 
>> I made the change in the Portfile, but it still won’t install. It seems that 
>> the problem is now with the arch arm64 (Mac mini M1).
>> Giuseppe Di Matteo
>> pinodimat...@me.com 
>> 
>> 
>> 
>> 
>> 
>>> Le 8 juin 2021 à 20:48, Christopher Jones >> > a écrit :
>>> 
>>> 
>>> For the smake issue see
>>> 
>>> https://github.com/macports/macports-ports/commit/9040f7195e114173a42c71ee57e74c248ef7ebb1
>>>  
>>> 
>>> 
 On 7 Jun 2021, at 5:15 pm, Andrew Udvare >>> > wrote:
 
 
> On 2021-06-07, at 09:34, Giuseppe Di Matteo via macports-users 
>  > wrote:
> 
> I can’t install cdrtools and streamripper on macOS 11 (Big Sur).
> 
> Giuseppe Di Matteo
> pinodimat...@me.com 
> 
> 
> 
> 
> 
> 
> 
 
 I can reproduce the issue with cdrtools. `smake` does not accept -j.
 
 I cannot reproduce the issue with streamripper. streamripper builds for 
 me. However, I am on x86-64.
>>> 
>> 
>