[Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223551
Mark Millard changed:
What|Removed |Added
CC||mar...@dsl-only.net
--- Comment #1 from Mark Millard ---
(In reply to sid from comment #0)
I expect that there is a misinterpretation of the
https://wiki.freebsd.org/ExternalToolchain wording.
(Easily done.)
I think that https://wiki.freebsd.org/ExternalToolchain
does not well indicate what context it material applies
in vs. what context is does not: XCC, XCXX, XCPP, XAS, etc.
do not replace all uses of CC, CPP, AS, etc. in all
contexts.
The description:
The XCC approach works with top level build targets (buildworld, buildkernel,
etc) and overrides common make variables such as CC, CXX, and AS during the
cross building portions of the build with values specified by the XCC, XCPP,
XAS, etc variables.
(end description)
sounds like all uses of CC, CXX, AS, and the like
are replaced --but that is wrong and would not
work for cross-builds.
For example, for amd64 -> aarch64 (cortex-A53)
cross builds I've used one compiler as the "for
host" CC/CXX/CPP and another compiler and its tool
chain as the "cross compiler to target" XCC/XCPP/. . .
for a cross build context. The cross-compiler tools
can not be used for everything because some
host software is also built for later use in
the overall buildworld that is happening on the
host.
Some recursive makes replace uses of CC/CXX/CPP
and the like with uses of XCC/XCXX/XCPP (for
example). But other make activity uses the
original definitions above (or the defaults for
what is not specified).
I've even done examples of a gcc host compiler
(and its toolchain) and a separate gcc cross
compiler (and its tool chain), avoiding the
system compiler for both aspects. That is
a type of example where things have to
start with CC/CXX/CPP/. . . vs. XCC/XCXX/XCPP/. . .
being distinct and the initial CC/CXX/CPP/. . .
do have to be used but are not the default
(system compiler tied). [devel/*-xtolchain-gcc's
are not setup for this fully automatically:
they are only the cross-compiler/toolchain
part of it.]
I'll supply one example for a cross-build that
has both CC/CXX/CPP and XCC/XCXX/XCPP/XAS/. . .
assignments and needs the distinctions:
(The example is for 12.0 but I've done such
11.x and for 10.x in the past. This does
use the system compiler/toolchain as the
host-targetting compiler/toolchain.)
# more ~/src.configs/src.conf.cortexA53-xtoolchain-gcc.amd64-host
TO_TYPE=aarch64
TOOLS_TO_TYPE=${TO_TYPE}
VERSION_CONTEXT=12.0
#
KERNCONF=GENERIC-NODBG
TARGET=arm64
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITHOUT_CROSS_COMPILER=
WITHOUT_SYSTEM_COMPILER=
#
WITH_LIBCPLUSPLUS=
WITHOUT_BINUTILS_BOOTSTRAP=
WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
WITHOUT_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITHOUT_LLD_BOOTSTRAP=
WITH_LLD=
WITH_LLD_IS_LD=
WITH_LLDB=
#
WITH_BOOT=
WITHOUT_LIB32=
#
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
#WERROR=
MALLOC_PRODUCTION=
#
WITH_REPRODUCIBLE_BUILD=
WITH_DEBUG_FILES=
#
XCFLAGS+= -mcpu=cortex-a53
XCXXFLAGS+= -mcpu=cortex-a53
# There is no XCPPFLAGS but XCPP gets XCFLAGS content.
#
#
# For TO (so-called "cross") stages . . .
# So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . .
# TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . .
#
CROSS_TOOLCHAIN=${TO_TYPE}-gcc
X_COMPILER_TYPE=gcc
CROSS_BINUTILS_PREFIX=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/
.if ${.MAKE.LEVEL} == 0
XCC=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-gcc
XCXX=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-g++
XCPP=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-cpp
.export XCC
.export XCXX
.export XCPP
XAS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as
XAR=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar
XLD=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld
XNM=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm
XOBJCOPY=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy
XOBJDUMP=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump
XRANLIB=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib
XSIZE=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size
#NO-SUCH: XSTRINGS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings
XSTRINGS=/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings
.export XAS
.export XAR
.export XLD
.export XNM
.export XOBJCOPY
.export XOBJDUMP
.export XRANLIB
.export XSIZE
.export XSTRINGS
.endif
#
#
# From based on clang (via system). . .
#
.if ${.MAKE.LEVEL} == 0
CC=/usr/bin/clang
CXX=/usr/bin/clang++
CPP=/usr/bin/clang-cpp
.export CC
.export CXX
.export CPP
.endif
(In some respects the above is explicit about
some things that each devel/*-xtoolchain-gcc
sets up to do automatically.)
So ultimately I think the specifics of any
example of a possible bad substitution need
[Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223551 --- Comment #2 from Mark Millard --- (In reply to sid from comment #0) I'll also mention that there is a port devel/xtoolchain-llvm50 that installs files to help configure for using llvm50 as a cross-compiler. For example: # more /usr/local/share/toolchains/llvm50.mk XCC=/usr/local/bin/clang50 XCXX=/usr/local/bin/clang++50 XCPP=/usr/local/bin/clang-cpp50 XLD=/usr/local/llvm50/bin/ld.lld CROSS_BINUTILS_PREFIX=/var/empty X_COMPILER_TYPE=clang An example for a gcc compiler is: # more /usr/local/share/toolchains/aarch64-gcc.mk XCC=/usr/local/bin/aarch64-unknown-freebsd12.0-gcc XCXX=/usr/local/bin/aarch64-unknown-freebsd12.0-g++ XCPP=/usr/local/bin/aarch64-unknown-freebsd12.0-cpp CROSS_BINUTILS_PREFIX=/usr/local/aarch64-freebsd/bin/ X_COMPILER_TYPE=gcc It would take also assigning CC/CXX/CPP/. . . in order to also use llvm50 materials as the host compiler/toolchain as well during cross-builds. (Note that the limiting condition of a cross-build is a form of native build, where the target happens to match the host type. But technically the CC/CXX/CPP/. . . could be assigned but the XCC/XCXX/XCPP/. . . left unassigned for "self hosted" that avoids the system compiler.) One does have to consider what to do with (showing WITHOUT_ use): WITHOUT_CROSS_COMPILER= WITHOUT_SYSTEM_COMPILER= WITH_SYSTEM_COMPILER= would be directly indicating to use the system compiler when a cross compiler does not seem to need to be built. WITH_CROSS_COMPILE= vs. WITHOUT_CROSS_COMPILER= is less obvious and I analyzed source code to see which way had the properties that I was after in each case. In my earlier example it was using WITHOUT_ for both and I explicitly set lots of things. This makes the case structurally more similar to the case of avoiding the system compiler (and potential cross compiler variant): in part it is just replacing some paths. It is not obvious what your host-native vs. cross-build-target intents are for use of: /usr/local/bin/llvm-as50 /usr/local/bin/llvm-ar50 /usr/local/bin/lld-link50 /usr/local/bin/llvm-nm50 /usr/local/bin/llvm-objdump50 /usr/local/bin/llvm-ranlib50 /usr/local/bin/llvm-strings50 (I've had examples of the host-native vs. cross-build-toolchain using different tools.) You may have to specify more of your intent for such things in order to find out what is needed to configure things. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223551 --- Comment #3 from s...@bsdmail.com --- (In reply to Mark Millard from comment #2) You're saying the X prefix doesn't replace buildworld compilers and utils in make.conf settings, it supplements them. If this is the case, perhaps this is an incorrect bug report. My intent was to replace binutils with either elfutils or llvm's utils. It was in part for purposes of not having to build/install utils and compilers twice (from the base system, then again from ports), and for modularity and efficiency of utils and compilers. As far as I'm aware, all of binutil's replacements are not completed. Down the road it will be better for testing, if there is a false sense that the package/ports compiler and utils are used, when base components are used. llvm40 and llvm50 work much the same. I used llvm50, because I thought perhaps it's binutils' replacements were more developed. Here's a sample of my src.conf to use clang/llvm from packages. #WITHOUT_TOOLCHAIN=yes #binutils is needed WITH_BINUTILS=yes WITH_BINUTILS_BOOTSTRAP=yes WITHOUT_CLANG=yes WITHOUT_CLANG_BOOTSTRAP=yes WITHOUT_CPP=yes # uncertain about WITHOUT_CXX=yes # needed for devd, gperf and c++ libraries # will use llvm40/50 WITH_LLVM_LIBUNWIND=yes WITH_LLD_BOOTSTRAP=yes WITH_LLD_IS_LD=yes WITH_LLVM_LIBUNWIND=yes WITHOUT_CROSS_COMPILER=yes WITHOUT_GCC=yes WITHOUT_GCC_BOOTSTRAP=yes WITHOUT_GDB=yes WITHOUT_GPL_DTC=yes WITHOUT_GNU=yes WITHOUT_GNUCXX=yes WITHOUT_GNU_SUPPORT=yes WITH_LLVM_LIBUNWIND=yes With your information, I will adjust my src.conf and make.conf and see if that works for the linker and utils. Thank you. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223551 --- Comment #4 from Mark Millard --- (In reply to sid from comment #3) What is the host environment? amd64? What is the target environment? Also amd64? (I'll be leaving for a meeting and so will not reply soon even if you do.) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223551 --- Comment #5 from s...@bsdmail.com --- (In reply to Mark Millard from comment #4) Target and host environment are both amd64. Thanks for your help. Not necessarily one person has to respond, anyone can respond. I can also keep tinkering with it. It seems that the X prefix should be used exclusively for base system (and kernel), because most ports build with AS, AR, LD, NM, OBJECTDUMP, RANLIB, and STRINGS set to llvm from ports. AS=/usr/local/bin/llvm-as50 AR=/usr/local/bin/llvm-ar50 LD=/usr/local/bin/lld-link50 # /usr/local/llvm50/bin/ld.lld NM=/usr/local/bin/llvm-nm50 OBJECTDUMP=/usr/local/bin/llvm-objdump50 RANLIB=/usr/local/bin/llvm-ranlib50 STRINGS= /usr/local/bin/llvm-strings50 XLD= /usr/local/llvm50/bin/ld.lld I will switch over to llvm40 than llvm50, because it is more widely used. Both have behaved similarly with these settings. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223551
--- Comment #6 from Mark Millard ---
(In reply to sid from comment #5)
So, for whatever reason, you want to:
buildworld buildkernel
in a way that does not build a system
compiler or toolchain in the process,
neither for internal use of the stages
of the build, nor for what would be in
the system after installworld. Also you
do not want to use any pre-existing
system compilers or system tool chain
to do this activity but instead use
a devel/llvm* .
Sound right? (The ports conventions
do not really apply to buildworld,
although there likely is some overlap.)
I used to do this sort of thing for
powerpc64 (self hosted), although before
devel/llvm*'s time. As I remember
I had it build system-clang but not use
system-clang. (At the time clang was
broken in big ways for powerpc64 so the
compiler was basically unusable.) I
had it build various things just to prove
that the builds could complete, even if
they were otherwise unused.
As I remember I had to do things to force
the system include files and libraries to
be used for what I used as the substitute
for the "host system compiler/toolchain".
The files from the compiler's own environment
were not appropriate/sufficient.
In more modern terms this would have been
using lang/gcc7 and its tool chain as the
"host system compiler/toolchain" and
devel/powerpc64-gcc and its tool chain
as the "cross compiler/toolchain", both
targeting powerpc64 (on a powerpc64
context). (Originally it was gcc49 instead
of gcc7.)
May be the below will help, even though it
is not exactly what you are after.
Not adjusting the material for devel/llvm40
or devel/llvm50 but modernizing the content
some and making it reference amd64 and be
appropriate for adm64 (and its set up for
12.0):
(preumes lang/gcc7 and devel/adm64-xtoolchain-gcc
are installed, dependencies included; still shows
building clang materials; I've not tested the
below)
# more /root/src.configs/src.conf.powerpc64-xtoolchain-gcc.powerpc64-host
TO_TYPE=amd64
TOOLS_TO_TYPE=${TO_TYPE}
FROM_TYPE=${TO_TYPE}
TOOLS_FROM_TYPE=${FROM_TYPE}
VERSION_CONTEXT=12.0
#
KERNCONF=GENERIC
TARGET=amd64
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITHOUT_CROSS_COMPILER=
WITHOUT_SYSTEM_COMPILER=
#
WITH_LIBCPLUSPLUS=
WITHOUT_BINUTILS_BOOTSTRAP=
WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
WITHOUT_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITH_LLD=
WITH_LLDB=
#
WITH_BOOT=
WITH_LIB32=
#
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
#
WERROR=
MALLOC_PRODUCTION=
#
WITH_REPRODUCIBLE_BUILD=
WITH_DEBUG_FILES=
#
#
# For TO (so-called "cross") stages . . .
# So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . .
# TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . .
#
CROSS_TOOLCHAIN=${TO_TYPE}-gcc
X_COMPILER_TYPE=gcc
CROSS_BINUTILS_PREFIX=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/
.if ${.MAKE.LEVEL} == 0
XCC=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-gcc
XCXX=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-g++
XCPP=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-cpp
.export XCC
.export XCXX
.export XCPP
XAS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as
XAR=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar
XLD=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld
XNM=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm
XOBJCOPY=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy
XOBJDUMP=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump
XRANLIB=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib
XSIZE=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size
#NO-SUCH: XSTRINGS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings
XSTRINGS=/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings
.export XAS
.export XAR
.export XLD
.export XNM
.export XOBJCOPY
.export XOBJDUMP
.export XRANLIB
.export XSIZE
.export XSTRINGS
.endif
#
#
# For FROM (host) stages . . .
# From gccXY (such as gcc7 but not xtoolchain)
# TOOLS_FROM_TYPE's appropriate binutils. . .
#
.if ${.MAKE.LEVEL} == 0
CC=env C_INCLUDE_PATH=/usr/include /usr/local/bin/gcc7 -L/usr/lib
CXX=env C_INCLUDE_PATH=/usr/include CPLUS_INCLUDE_PATH=/usr/include/c++/v1
/usr/local/bin/g++7 -std=c++11 -nostdinc++ -L/usr/lib
CPP=/usr/local/bin/cpp7
.export CC
.export CXX
.export CPP
AS=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/as
AR=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/ar
LD=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/ld
NM=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/nm
OBJCOPY=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/objcopy
OBJDUMP=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/objdump
RANLIB=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/ranlib
SIZE=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/size
#NO-SUCH:
STRINGS=/usr/local/${TOOLS_F
Re: [Bug 223383] pathconf querying for posix_falloc not supported on freebsd [devel/llvm*'s lld's are also broken by this for zfs and need updating]
[ devel/llvm* also have the issue in their lld 's.] On 2017-Nov-7, at 4:43 PM, bugzilla-noreply at freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223383 > > --- Comment #7 from commit-h...@freebsd.org --- > A commit references this bug: > > Author: emaste > Date: Wed Nov 8 00:39:04 UTC 2017 > New revision: 325523 > URL: https://svnweb.freebsd.org/changeset/base/325523 > > Log: > MFC r325420: lld: accept EINVAL to indicate posix_fallocate is unsupported > > As of r325320 posix_fallocate on a ZFS filesystem returns EINVAL to > indicate that the operation is not supported. (I think this is a strange > choice of errno on the part of POSIX.) > > PR: 223383, 223440 > Reported by: Mark Millard > Sponsored by: The FreeBSD Foundation > > Changes: > _U stable/11/ > stable/11/contrib/llvm/lib/Support/Unix/Path.inc > > -- > You are receiving this mail because: > You are on the CC list for the bug. [Context a zfs file system.] >From /usr/src/UPDATING: 20171106: The naive and non-compliant support of posix_fallocate(2) in ZFS has been removed as of r325320. The system call now returns EINVAL when used on a ZFS file. Although the new behavior complies with the standard, some consumers are not prepared to cope with it. One known victim is lld prior to r325420. The issue is not limited to the system clang's associated lld. Here is an attempt to use clang++50, implicitly using its associated lld: # clang++50 -v exception_test.cc clang version 5.0.0 (tags/RELEASE_500/final) Target: x86_64-portbld-freebsd12.0 Thread model: posix InstalledDir: /usr/local/llvm50/bin "/usr/local/llvm50/bin/clang-5.0" -cc1 -triple x86_64-portbld-freebsd12.0 -emit-obj -mrelax-all -disable-free -main-file-name exception_test.cc -mrelocation-model static -mthread-model posix -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -v -dwarf-column-info -debugger-tuning=gdb -resource-dir /usr/local/llvm50/lib/clang/5.0.0 -internal-isystem /usr/include/c++/v1 -fdeprecated-macro -fdebug-compilation-dir /root/c_tests -ferror-limit 19 -fmessage-length 200 -fobjc-runtime=gnustep -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/exception_test-baadc9.o -x c++ exception_test.cc clang -cc1 version 5.0.0 based upon LLVM 5.0.0 default target x86_64-portbld-freebsd12.0 #include "..." search starts here: #include <...> search starts here: /usr/include/c++/v1 /usr/local/llvm50/lib/clang/5.0.0/include /usr/include End of search list. "/usr/local/llvm50/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/exception_test-baadc9.o -lc++ -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o /usr/local/llvm50/bin/ld: error: cannot open output file a.out: Invalid argument clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation) https://svnweb.freebsd.org/ports/head/devel/?dir_pagestart=1000 does not yet suggest updates to devel/llvm* 's for the issue. === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223551 --- Comment #7 from Mark Millard --- (In reply to sid from comment #0) I used -v to check include paths searched for devel/llvm50 : #include <...> search starts here: /usr/include/c++/v1 /usr/local/llvm50/lib/clang/5.0.0/include /usr/include As I would expect for devel/* it looks like teh devel/llvm* 's were adjusted to use the system include files by default. (If there was a lang/llvm50 then it likely would not have such an adjustment, just like lang/gcc7 does not look there by default.) So it appears that the following paragraph does not apply to your context: As I remember I had to do things to force the system include files and libraries to be used for what I used as the substitute for the "host system compiler/toolchain". The files from the compiler's own environment were not appropriate/sufficient. I will note that currently lld from devel/llvm* 's are broken on zfs from the fallocate change (ZFS does not actually support it but lld tries to use it without detecting the problem). The devel/llvm* 's need to be updated so that they build usable lld 's even for use in a zfs context. What lld does on zfs after a given version is: "/usr/local/llvm50/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/exception_test-baadc9.o -lc++ -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o /usr/local/llvm50/bin/ld: error: cannot open output file a.out: Invalid argument clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation) At soem point this will apply to 11.x instead of just 12.0. (I've not been tracking 11.x and so do not know the status of zfs and fallocate there.) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
