On Wed, December 6, 2017 16:16, Stuart Henderson wrote: > On 2017/12/06 15:32, Kirill Bychkov wrote: >> On Wed, December 6, 2017 14:37, Stuart Henderson wrote: >> > On 2017/12/06 11:49, Kirill Bychkov wrote: >> >> On Wed, December 6, 2017 11:34, Jeremie Courreges-Anglas wrote: >> >> > On Wed, Dec 06 2017, "Kirill Bychkov" <ki...@linklevel.net> wrote: >> >> >> On Wed, December 6, 2017 03:23, Jeremie Courreges-Anglas wrote: >> >> >>> On Sun, Dec 03 2017, "Kirill Bychkov" <ki...@linklevel.net> wrote: >> >> >>>> Hi! >> >> >>>> This patch enables build of libraw on other gcc4 arches, not only >> arm. >> >> >>>> Tested on macppc. >> >> >>>> OK? >> >> >>> >> >> >>> This looks heavy-handed to me, why extend this to all non-clang >> archs, >> >> >>> afaik base-gcc has support for 4-bytes atomics on powerpc. How does >> the >> >> >>> build fail exactly? >> >> >> >> >> >> Without patch I see >> >> >> ===> libraw-0.18.5 is only for aarch64 amd64 i386 arm, not powerpc >> >> >> (macppc) . >> >> >> MODGCC4_ARCHS = arm somehow overrides ONLY_FOR_ARCHES: >> >> >> >> >> >> make show=ONLY_FOR_ARCHS >> >> >> aarch64 amd64 i386 arm >> >> >> >> >> >> With patch: >> >> >> make show=ONLY_FOR_ARCHS >> >> >> aarch64 amd64 i386 amd64 arm hppa i386 mips64 mips64el powerpc sparc64 >> >> >> >> >> >> Switching MODULES=gcc4 to COMPILER=gcc made libraw unavailable on most >> >> >> arches. >> >> >> See >> >> >> http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/graphics/libraw/Makefile.diff?r1=1.24&r2=1.25 >> >> > >> >> > ok, thanks for confirming. >> >> > >> >> >> Better patch: >> >> >> >> >> >> Index: Makefile >> >> >> =================================================================== >> >> >> RCS file: /cvs/ports/graphics/libraw/Makefile,v >> >> >> retrieving revision 1.29 >> >> >> diff -u -p -u -r1.29 Makefile >> >> >> --- Makefile 16 Nov 2017 23:20:39 -0000 1.29 >> >> >> +++ Makefile 6 Dec 2017 08:13:27 -0000 >> >> >> @@ -22,9 +22,10 @@ WANTLIB += c jasper jpeg lcms2 m pthread >> >> >> >> >> >> MASTER_SITES = https://www.libraw.org/data/ >> >> >> >> >> >> -COMPILER = base-clang ports-gcc >> >> >> # for atomic builtins (__sync_fetch_and_add_4) >> >> >> -MODGCC4_ARCHS = arm >> >> >> +.if ${MACHINE_ARCH} == "arm" >> >> >> +COMPILER = base-clang ports-gcc >> >> >> +.endif >> >> > >> >> > I guess it's fine, but isn't the shortest fix to add "base-gcc" at the >> >> > end of COMPILER? >> >> >> >> macppc is quite happy with base-gcc, so it should be before ports-gcc. >> And >> >> for arm ports-gcc is the only solution I suppose (have no hw to test). >> >> So I see no other way to deal with arm other than this. >> >> >> >> >> >> >> > >> > I think COMPILER should be removed here, seems it should probably >> > use this instead (untested): >> > >> > # XXX remove when armv7 switches to clang in base? >> > MODULES= gcc4 >> > MODGCC4_ARCHS= arm >> > MODGCC4_LANGS= c++ >> > >> > >> Missed that point that we could simply return back to MODULES=gcc instead >> of COMPILER. Works for me on macppc and amd64. >> > > Is it worth trying that on hppa as well? > > OK?
OK.
