On 2026/10/28 13:03, Kirill A. Korinsky wrote: > On Wed, 28 Oct 2026 12:38:46 +0100, > Stuart Henderson <[email protected]> wrote: > > > > On 2026/10/28 12:30, Theo Buehler wrote: > > > On Wed, Oct 28, 2026 at 11:20:49AM +0000, Stuart Henderson wrote: > > > > On 2026/10/28 11:48, Kirill A. Korinsky wrote: > > > > > > > > > > > > Not a fan of this. > > > > > > kmos@ added the COMPILER line for sparc64 build at the time. I > > > > > > don't know what > > > > > > the error was and if it was fixable. > > > > > > > > > > > > > > > > I had talked with kmos@, and he, as expected, hasn't recall nor have > > > > > logs of > > > > > that error. > > > > > > > > > > I also checked http://build-failures.rhaalovely.net/sparc64/ and here > > > > > to > > > > > trace of this. > > > > > > > > I don't see any error, I checked build logs. > > > > > > > > libxml-2.10.2 built ok with base compiler on sparc64 on 2022-08-31 > > > > > > > > The subsequent build on 2022-09-10 was with ports-gcc > > > > > > > > > > kmos often reduced the fallout in package snapshots by fixing things up > > > before the bulks finished. This is great for users. The downside is that > > > the logs of the failures were lost because (as I understand it) the > > > script only pushes out failures showing up in the summary.log. > > > > > > > aha, there are two builds in that log. errors are in libxml2-py.c; > > the python bindings are no longer built. > > [...] > > > libxml2-py.c:196: error: expected '=', ',', ';', 'asm' or '__attribute__' > > before 'PyObject' > > libxml2-py.c:324: error: expected '=', ',', ';', 'asm' or '__attribute__' > > before 'PyObject' > > libxml2-py.c:1557: error: expected '=', ',', ';', 'asm' or '__attribute__' > > before 'PyObject' > > libxml2-py.c:1578: error: expected '=', ',', ';', 'asm' or '__attribute__' > > before 'PyObject' > > libxml2-py.c:2331: error: expected '=', ',', ';', 'asm' or '__attribute__' > > before 'PyObject' > > libxml2-py.c:2358: error: expected '=', ',', ';', 'asm' or '__attribute__' > > before 'PyObject' > > libxml2-py.c:3270: error: expected '=', ',', ';', 'asm' or '__attribute__' > > before 'PyObject' > > libxml2-py.c:3283: error: expected '=', ',', ';', 'asm' or '__attribute__' > > before 'PyObject' > > libxml2-py.c:3330: error: expected '=', ',', ';', 'asm' or '__attribute__' > > before 'PyObject' > > libxml2-py.c:3541: error: expected '=', ',', ';', 'asm' or '__attribute__' > > before 'PyObject' > > libxml2-py.c:6377: error: expected '=', ',', ';', 'asm' or '__attribute__' > > before 'PyObject' > > libxml2-py.c:6464: error: expected '=', ',', ';', 'asm' or '__attribute__' > > before 'PyObject' > > libxml2-py.c:6734: error: expected '=', ',', ';', 'asm' or '__attribute__' > > before 'PyObject' > > libxml2-py.c:6937: error: expected '=', ',', ';', 'asm' or '__attribute__' > > before 'PyObject' > > libxml2-py.c:7020: error: expected '=', ',', ';', 'asm' or '__attribute__' > > before 'PyObject' > > libxml2-py.c:13533: error: expected '=', ',', ';', 'asm' or '__attribute__' > > before 'PyObject' > > Error while executing cc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include > > -I/usr/local/include/python3.9 -I/usr/local/include -I/usr/local/include > > -O2 -pipe -MT libxml2-py.lo -MD -MP -MF .deps/libxml2-py.Tpo -c > > libxml2-py.c -fPIC -DPIC -o .libs/libxml2-py.o > > Thanks, what perfectly explains why: python needs ports-gcc and expect that > python's bindings won't need it is naive, indeed. > > But libxml port has that comment: > > # Python bindings are planned to be removed in the 2.16 release; > # circular dependency: libxml -> doxygen -> git -> xmlto -> libxml > > so, it reads like we good with move back to autotools and drop ports-gcc > requirements, right? > > Special that upstream declared C89 as target and it really builds with > -std=c89 at CI: > https://github.com/GNOME/libxml2/blob/master/.gitlab-ci.yml#L39-L43 > > without python :) > > -- > wbr, Kirill >
It's the general "adding more things on the path to building gcc" that I'd prefer to avoid - whichever way it's done it increases the number of ports which need extra care when dealing with updates. And since a build without ports-gcc is pretty much useless, it's extra work for bulk builders (and increases the chance of a bad build getting pushed out to ftp if the people signing them don't notice) whenever something breaks gcc (the more frontends enabled, the more likely) or one of the ports on the path to it.
