On Tue, Oct 17, 2023 at 07:07:12PM +0100, Stuart Henderson wrote: > On 2023/10/17 17:36, Klemens Nanni wrote: > > On Tue, Oct 17, 2023 at 04:32:19PM +0200, Theo Buehler wrote: > > > On Tue, Oct 17, 2023 at 03:27:26PM +0100, Stuart Henderson wrote: > > > > On 2023/10/16 21:07, Klemens Nanni wrote: > > > > > OK kn when that works on sparc64 for you and got wrapped in a > > > > > CHOSEN_COMPILER or MACHINE_ARCH check. > > > > > > > > CHOSEN_COMPILER is messy because it has to go after the final > > > > .include <bsd.port.mk> > > > > > > > > Using MACHINE_ARCH and enumerating the base-gcc archs is a > > > > terrible idea for this. > > > > > > > > Could do !${PROPERTIES:Mclang} though my strong preference would > > > > be to avoid difference between flags on the different archs and > > > > always add to CXXFLAGS.. > > > > > > I would also have preferred that since I don't really see the reason > > > for treating gcc and clang differently, just because clang happens to > > > work for a reason that I did not investigate. > > > > > > I used this (since I just used something similar for shared-mime-info) > > > and it does the expected: > > > > > > EXTRA_ports-gcc += -I${LOCALBASE}/include > > > CXXFLAGS += ${EXTRA_${CHOSEN_COMPILER}} > > > > No objection from me doing this unconditionally if this is too messy. > > > > It just made it easier to reason about and, imho, also reads clearer than > > an unconditional include that implies configure/build script bugs when there > > are none (at least for clang archs). > > > > I don't see a configure script bug. > > lz4 and lzo2 are picked up on ports-gcc archs at configure time. > From the failed build log: > > -- Looking for lzo1x_1_15_compress in lzo2 > -- Looking for lzo1x_1_15_compress in lzo2 - not found > -- Looking for LZ4_compress_default in lz4 > -- Looking for LZ4_compress_default in lz4 - found > > IIRC ports-gcc's library search path includes /usr/local/lib which would > explain this. If that's not it, there's probably something deep in > /usr/local/share/cmake responsbile, but I no longer have the correct > glasses from the Infocom HHGTTG packaging to spend much time in > there. > > These libraries aren't linked to the main snappy library but are used > in tests. > > Adding the -I without doing anything else means that if lz4 or lzo2 are > present during configure and then junked, build will fail. (Probably > better if things like this are seen on base-clang archs too, rather > than failing very occasionally on a less common arch).
The problem I was addressing is that lz4 will always make sanppy fail on sparc64 because it's always there: cmake -> libarchive -> lz4. In particular, it won't be junked. ports-gcc then stumbles over the weird #include "lz4.h" in the test (which should be fixed upstream by using <lz4.h> I suppose). For some reason clang is happy with "" while ports-gcc isn't, so I made sure gcc can find it. I did not look for further problems, but I do see the problem with lzo2. > I think this is a better fix (checked there's no change to the produced > package so I didn't bump). ok tb > Index: Makefile > =================================================================== > RCS file: /cvs/ports/archivers/snappy/Makefile,v > retrieving revision 1.20 > diff -u -p -r1.20 Makefile > --- Makefile 16 Oct 2023 21:17:52 -0000 1.20 > +++ Makefile 17 Oct 2023 17:56:42 -0000 > @@ -25,8 +25,12 @@ CONFIGURE_ARGS += -DBUILD_SHARED_LIBS=ON > -DINSTALL_GTEST=OFF \ > -DSNAPPY_BUILD_BENCHMARKS=OFF > > -EXTRA_ports-gcc += -I${LOCALBASE}/include > -CXXFLAGS += ${EXTRA_${CHOSEN_COMPILER}} > +# used in tests > +BUILD_DEPENDS = archivers/lz4 \ > + archivers/lzo2 > + > +CXXFLAGS += -I${LOCALBASE}/include > +MODCMAKE_LDFLAGS = -L${LOCALBASE}/lib > > # expects submodule/cannot use system library > DIST_TUPLE = github google googletest > e40661d89b051e9ef4eb8a2420b74bf78b39ef41 \ >