On Thu, December 7, 2017 18:39, Jeremie Courreges-Anglas wrote: > On Thu, Dec 07 2017, Marc Espie <es...@nerim.net> wrote: >> On Thu, Dec 07, 2017 at 05:56:13PM +0300, 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. >>> >> > >>> >> >[...] >>> >> > 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++ >>> > >>> >>> Hello, >>> Another look at the tree showed more incorrect removals of MODULES=gcc: >>> in devel/libgit2/libgit2 [1] and devel/libmtp [2]. >>> So I propose to switch back to MODULES=gcc4 instead of COMPILEr and unlock >>> building of this ports on most !clang archs. >>> Builds fine on macppc (base-gcc) and amd64 (base-clang). >>> OK? Comments? >> >> This is a disastrous idea. >> >> Learn to work with COMPILER, please. >> Figure out the correct line in those cases. > > Thanks for confirming, Marc. This is similar to what I suggested for > libraw, and allows me to build libmtp on armv7: > > > Index: Makefile > =================================================================== > RCS file: /d/cvs/ports/devel/libmtp/Makefile,v > retrieving revision 1.39 > diff -u -p -r1.39 Makefile > --- Makefile 16 Nov 2017 23:20:38 -0000 1.39 > +++ Makefile 7 Dec 2017 15:29:45 -0000 > @@ -16,9 +16,9 @@ WANTLIB += c gcrypt gpg-error iconv intl > > MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=libmtp/} > > -# avoid "libmtp.so.7.0: undefined reference to `.L2085'" > -COMPILER= base-clang ports-gcc > +COMPILER= base-clang ports-gcc base-gcc > COMPILER_LANGS= c > +# avoid "libmtp.so.7.0: undefined reference to `.L2085'" > MODGCC4_ARCHS= mips64 mips64el > > LIB_DEPENDS= devel/libusb1 \ > >
After attentive reading of manuals I've finally got how this works. I was confused by MODGCC4_* vars in my understaning. Works on macppc. OK with me.
