Hi Ryan, Thanks for the response.
On Sun, Jan 17, 2021 at 02:31:22AM -0600, Ryan Schmidt <[email protected]> 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 > > 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 Thanks for that. I think I can tell from https://trac.macports.org/wiki/UsingTheRightCompiler 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 fine. 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 that. > > 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. cheers, raf
