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