odd problem trying to use Macports ...

[Ryan Schmidt]

On Jan 12, 2021, at 00:34, raf wrote:

> I treated this like a migration, recorded and uninstalled existing ports,
> then installed/upgraded macports, and then restored the ports.
> 
>  Mac OS X 10.6 (darwin/10.8.0) arch i386
>  MacPorts 2.6.4
>  Xcode 3.2.6
>  SDK 10.6
>  MACOSX_DEPLOYMENT_TARGET: 10.6
> 
> I'm having some trouble. I'm getting errors with several ports:
> 
>  daemon:
>     unrecognized command line option "-Wno-gnu-folding-constant"

We see this on our 10.6 build server too. I didn't file a bug for that error specifically, but for a different and possibly related problem:

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


>  tk:
>    invalid operands to binary expression ('id' and 'double')

I don't see a ticket filed for this, and I don't think we've seen this problem with this port. File a ticket and attach your main.log.


>  MacVim:
>     MacVim only runs on OS X 10.8 or greater
>    (Used to work on 10.6. Tragic! I'll have to compile that myself)

Ports get updated over time, and developers drop support for older operating systems.

The 10.8 requirement was noticed in https://trac.macports.org/ticket/52505. That ticket also tells you what the last version that works on 10.6 was, and how to use MacPorts to install it.


>  dirac:
>    non-constant-expression cannot be narrowed from type 'int' to 'dirac::ValueType' (aka 'short') in initializer list [-Wc++11-narrowing]
>  wxWidgets-2.8
>    non-constant-expression cannot be narrowed from type 'short' to 'CGFloat' (aka 'float') in initializer list [-Wc++11-narrowing]
>    non-constant-expression cannot be narrowed from type 'FontFamilyID' (aka 'short') to 'UInt32' (aka 'unsigned long') in initializer list [-Wc++11-narrowing]

I don't see tickets filed for these yet.

The compilers included in Xcode on 10.6 are so old that we tend not to use them for most ports anymore, and use a much newer MacPorts clang instead, one which defaults to C++11. This has the paradoxical effect of causing problems on 10.6 with software like apparently dirac and wxWidgets-2.8 that is not C++11 compliant, problems which we do not observe on newer OS versions because on newer OS versions we can use the compilers provided by Xcode which are older than the newest MacPorts clangs and don't default to C++11.


>  openjade:
>    ISO C++11 does not allow access declarations; use using declarations instead

Already filed as https://trac.macports.org/ticket/60158


> Should I file bug reports for all of these (apart from MacVim)?

You can file bug reports when things don't work, but please understand that for very old OS versions like 10.6, many maintainers will not invest any time in solving such problems. If you can provide a fix, ideally in a pull request, that will increase the likelihood of getting the problem fixed for you and other 10.6 users.


> Another openjade/tk error is:
> 
>  Error: Requested variants "+x11" do not match those the build was started with: "+quartz".
>  Error: Please use the same variants again, or run 'port clean tk' first to remove the existing partially completed build.
> 
> I didn't specify any variants for those. They're not requested ports.

The last time you tried to install the tk port, you did so using the variant +quartz, either because you had requested it or because that used to be the default. That build was interrupted or failed, leaving a work directory that includes a record of what variants you had selected. You are now trying to install the tk port with the +x11 variant, either because you requested it or because it is now the default, which does not match what you selected previously. Either select what you selected previously (+quartz), or clean tk before trying again.


> I wrote daemon, so I want to fix that myself. Can anyone tell me
> how to tell, from a shell script, whether or not the compiler
> supports -Wno-gnu-folding-constant? Or should I just not include
> it on macos? I suppose I should just try to run gcc with it. :-)
> I'll do that.

daemon builds fine on OS X 10.8 and later, so there is no general problem with -Wno-gnu-folding-constant not working on macOS. But for best portability, for flags that not all compilers support, you should only use a flag if you determine that the compiler supports it.

Normally a configure script is used to determine what features are available on the current system. I see that daemon has a configure script but that it is a simple shell script written manually by you, rather than something generated by autoconf. Autoconf has features that help you detect what flags a compiler supports, but if you want to continue to use your manually-written script, you'll have to figure out how to replicate that functionality of autoconf. Here's how you might do that.

Here's an example showing that on my system, the compiler cc supports -Wno-gnu-folding-constant, indicated by the exit code being 0:

$ ${CC:-cc} -E -xc /dev/null -Werror -Wno-gnu-folding-constant >/dev/null; echo $?
0

In contrast, using a nonexistent flag like -Wnope results in an error and an exit code of 1:

$ ${CC:-cc} -E -xc /dev/null -Werror -Wnope >/dev/null; echo $?
error: unknown warning option '-Wnope'; did you mean '-Wmove'? [-Werror,-Wunknown-warning-option]
1

Note that using -Werror will turn all warnings into errors. Make sure that your tests don't trigger other warnings, otherwise the results won't correctly answer the question. Note that you should not use -Werror=unknown-warning-option to only turn warnings about unknown warning options into an error because although new compilers support that option old compilers (like gcc 4.2.1 on Snow Leopard which is the one the problem you're trying to fix is being observed with) don't.