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.
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}..
