odd problem trying to use Macports ...

raf macports at raf.org
Sun Jan 24 12:58:39 UTC 2021

Hi Ryan,

Thanks for the response.

On Sun, Jan 17, 2021 at 02:31:22AM -0600, Ryan Schmidt <ryandesign at macports.org> wrote:

> 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
> > 
> > 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

Thanks for that. I think I can tell from
how to use the right compiler (i.e. look at $CC in my
dumb configure script and update the Makefile to use
it), but I'm not sure about -arch. The compilers I have
don't seem to have an -arch option. But it looks like
Kurt is addressing this ticket. It does install
successfully now. I'll ask him if there's anything that
I can do upstream to help.

> >  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.

I started again, and instead of using restore_ports.tcl
on my list of previously installed ports, I just
installed my previously requested ports. Now, tk is

The only problem builds are avidemux, which I've filed
a ticket for (#62136), and muse (needed by
py27-wxpython-2.8) and there's already a ticket for

> >  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.

Ah, I wrote those instructions! Still works. :-)

> >  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.

Thanks for the explanation.
Perhaps these will turn up again when the mesa problem is fixed.
If they do, I'll file ticketts for them then.

> >  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.

That's fair enough. I don't really need py27-wxpython-2.8 anymore,
so mesa not working isn't a disaster, but I'd like to get avidemux
working again, even if I have to rever to an older version.

> > 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.

Thanks for that.


More information about the macports-users mailing list