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 <[email protected]>: > > > 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++.
