On 2017/02/07 10:02, Stuart Henderson wrote:
> On 2017/02/07 11:47, Jonathan Gray wrote:
> > On Mon, Jan 23, 2017 at 10:14:15AM +0000, Stuart Henderson wrote:
> > > On 2017/01/23 11:55, Vadim Zhukov wrote:
> > > > 2017-01-23 4:04 GMT+03:00 Peter Hessler <phess...@openbsd.org>:
> > > > > Here are some bits to add arch defines to the ports infrastruture
> > > > > files
> > > > > for aarch64.
> > > > >
> > > > > amd64 is the kernel arch (similar to macppc)
> > > > > aarch64 is the application arch (similiar to powerpc)
> > > >
> > > > I see no mention of arm64 in the diff you posted.
> > >
> > > arm64 is not needed for the ARCHS defines, it would only appear on lines
> > > that have things like "loongson/macppc" instead of "mips64el/powerpc".
> > >
> > > > > Untested, but it is relatively straightforward. db/config.* already
> > > > > has
> > > > > information about armv8/arm64/aarch64.
> > > > >
> > > > > OK?
> > > > >
> > > > > Index: infrastructure/mk/arch-defines.mk
> > > > > ===================================================================
> > > > > RCS file: /cvs/openbsd/ports/infrastructure/mk/arch-defines.mk,v
> > > > > retrieving revision 1.30
> > > > > diff -u -p -u -p -r1.30 arch-defines.mk
> > > > > --- infrastructure/mk/arch-defines.mk 1 Jan 2017 10:50:18 -0000
> > > > > 1.30
> > > > > +++ infrastructure/mk/arch-defines.mk 23 Jan 2017 00:53:07 -0000
> > > > > @@ -17,14 +17,15 @@ ALL_ARCHS = alpha amd64 arm aviion hppa
> > > > > # not all powerpc have apm(4), hence the use of macppc
> > > > > APM_ARCHS = amd64 i386 loongson macppc sparc64
> > > > > BE_ARCHS = hppa m88k mips64 powerpc sparc64
> > > > > -LE_ARCHS = alpha amd64 arm i386 mips64el sh
> > > > > -LP64_ARCHS = alpha amd64 sparc64 mips64 mips64el
> > > > > +LE_ARCHS = aarch64 alpha amd64 arm i386 mips64el sh
> > > > > +LP64_ARCHS = aarch64 alpha amd64 sparc64 mips64 mips64el
> > > > > +CLANG_ARCHS = aarch64
> > > >
> > > > It's better describe in bsd.port.mk(5) what's the CLANG_ARCHS and
> > > > LLVM_ARCHS lists are, otherwise it gets quiet confusing.
> > >
> > > Agreed. I'm OK with the existing diff but please add this.
> > >
> > > > Also, you likely want to tweak clang.port.mk (to skip dependency and
> > > > correct cc/c++ links) and devel/llvm port (to skip it on CLANG_ARCHS),
> > > > unless you really want to keep devel/llvm port building on aarch64 and
> > > > make ports keep using this one instead of system compiler. I remember
> > > > sending a patch proposal to patrick@ some time ago...
> > >
> > > I disagree about skipping devel/llvm - it comes with many more things
> > > than we'd expect to be installed in base (and some things that _cannot_
> > > be done in base, like the Python bindings).
> > >
> > > I agree that the clang module should use the compiler from base on those
> > > arches where it is already the base compiler. (Similar to what we did with
> > > the gcc3 module when we had gcc2+3 arches; use base compiler on gcc3
> > > arches,
> > > use ports compiler on gcc2 arches).
> > >
> > > Should we rename files in the llvm port (e.g. eclang/eclang++/eclang-cpp)?
> > >
> >
> > How should WANTLIB be handled?
> >
> > To build a native gdb with ports gettext has to be built which has WANTLIB
> > of stdc++ not c++.
> >
>
> The simple fix for your issue would be to add a ${BASE_CXXLIB}, stdc++
> on base-is-gcc arches, c++ on base-is-clang ones, and replace all
> stdc++ in WANTLIB with that variable.
e.g.
Index: infrastructure/mk/arch-defines.mk
===================================================================
RCS file: /cvs/ports/infrastructure/mk/arch-defines.mk,v
retrieving revision 1.31
diff -u -p -r1.31 arch-defines.mk
--- infrastructure/mk/arch-defines.mk 23 Jan 2017 10:50:25 -0000 1.31
+++ infrastructure/mk/arch-defines.mk 7 Feb 2017 10:06:32 -0000
@@ -29,13 +29,19 @@ LLVM_ARCHS = aarch64 amd64 arm i386 powe
OCAML_NATIVE_ARCHS = i386 amd64
OCAML_NATIVE_DYNLINK_ARCHS = i386 amd64
GO_ARCHS = amd64 i386
-
+LIBCXX_ARCHS = aarch64
.for PROP in ALL APM BE LE LP64 GCC4 GCC3 MONO LLVM \
- OCAML_NATIVE OCAML_NATIVE_DYNLINK GO
+ OCAML_NATIVE OCAML_NATIVE_DYNLINK GO LIBCXX
. for A B in ${MACHINE_ARCH} ${ARCH}
. if !empty(${PROP}_ARCHS:M$A) || !empty(${PROP}_ARCHS:M$B)
PROPERTIES += ${PROP:L}
. endif
. endfor
.endfor
+
+.if ${PROPERTIES:Mlibcxx}
+BASE_CXXLIB = c++
+.else
+BASE_CXXLIB = stdc++
+.endif
Index: devel/gettext/Makefile
===================================================================
RCS file: /cvs/ports/devel/gettext/Makefile,v
retrieving revision 1.81
diff -u -p -r1.81 Makefile
--- devel/gettext/Makefile 31 Aug 2016 13:53:11 -0000 1.81
+++ devel/gettext/Makefile 7 Feb 2017 10:06:32 -0000
@@ -20,7 +20,7 @@ MAINTAINER= Christian Weisgerber <naddy@
PERMIT_PACKAGE_CDROM= Yes
LIB_DEPENDS= converters/libiconv
-WANTLIB= c m iconv stdc++
+WANTLIB= c m iconv ${BASE_CXXLIB}
WRKSRC= ${WRKDIST}/gettext-runtime
CONFIGURE_STYLE=gnu
> But this is part of a wider problem that we don't have a good answer
> for.
>
> We have some libraries that are built with ports gcc or ports clang
> on some arch (-> estdc++).
>
> libraries (e.g. libvpx) has a WANTLIB with stdc++ on some arches,
> estdc++ on other arches, and c++ on another. Trouble is, there's no
> common way to chain it through, and I don't see a sane way to add
> one. In the case of libvpx it's built with ports clang (mostly for
> the integrated assembler IIRC) and thus linked with libstdc++ on
> i386/amd64 but built with base gcc on other arches. In the case of
> some other library it may use ports gcc on all arches for newer C++
> language support. And some downstream port might depend on both of these
> libraries, giving different mixtures of symbol conflicts on different
> arches.
>
> Currently we have a mixture of this...
>
> # comes from multimedia/libvpx using lang/clang MODULE on i386|amd64 only
> # which includes gcc4 MODULE with adds gcc-libs in dependency scope
> .if ${MACHINE_ARCH:Mi386} || ${MACHINE_ARCH:Mamd64}
> WANTLIB-main += estdc++
> .endif
>
> ...and ports that don't build on some arch simply because they list
> estdc++ in WANTLIB and don't have a library dependency chain to it.
>
> We could really do with getting things down to one C++ standard library
> per arch (not just for ports; needs to be used for xenocara as well),
> then we could have a simple variable like ${CXXLIB}..
>
