Re: head -r341836 (jump to clang 7): amd64 -> armv7 cross build failed: ld: error: unable to find library -lh_csu
On Thu, Dec 13, 2018 at 3:25 AM Mark Millard via freebsd-toolchain wrote: > Looks like this might have been from a race condition or some such. > Rerunning the meta-mode build again had no such problem and completed. It is also happening in clean build, I've filed a PR about this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233734 Li-Wen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WITH_META_MODE: any effect? Tree built twice!
O. Hartmann wrote: > delete-old|-libs afterwards, I started again a build (filemon loaded!). And, > surprise, > surprise, compilation of all the long-haul taking LLVM/CLANG stuff starts > again! That is > not funny. If you have META_MODE enabled -dM will tell you if meta_oodate decided the target needs update - and if so exactly why. Eg. a command changed, a file is updated, missing etc. If it says nothing, then the target was out-of-date per normal make rules. > Why do I have to rebuild world twice to get WITH_META_MODE in effect? I don't follow; why do you think that is the case? > These setting dind't change over the past time, except some WITHOUT_ tags. > > Are there any unrevealed secrets? If changing any of those knobs impacts CFLAGS etc - then pretty much everything will be out-of-date. Adding -dM to your build command should be very instructive. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r111 build error
On Wed, 12 Dec 2018 at 10:19, Ed Maste wrote: > > While we could take this to > root cause I think the most expedient fix is probably just to check > for evidence of clang 6 in the object tree, and rm the .depend files > and objects if found. A patch implementing this is available for review in https://reviews.freebsd.org/D18530 . ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head -r341836 (jump to clang 7): amd64 -> armv7 cross build failed: ld: error: unable to find library -lh_csu
On 2018-Dec-11, at 17:27, Mark Millard wrote: > [This was after amd64 updating to -r341836 successfully ( from -r341766 ). > The below was a meta-mode cross build, also going from -r341766 to > -r341836 .] > > # > ~/sys_build_scripts.amd64-host/make_armv7_nodebug_clang_bootstrap-amd64-host.sh > -j28 buildworld buildkernel > Script started, output file is > /root/sys_typescripts/typescript_make_armv7_nodebug_clang_bootstrap-amd64-host-2018-12-11:17:02:35 > --- buildworld --- > make[1]: "/usr/src/Makefile.inc1" line 347: SYSTEM_COMPILER: Determined that > CC=cc matches the source tree. Not bootstrapping a cross-compiler. > make[1]: "/usr/src/Makefile.inc1" line 352: SYSTEM_LINKER: Determined that > LD=ld matches the source tree. Not bootstrapping a cross-linker. > --- buildworld_prologue --- > . . . > --- all_subdir_lib --- > --- all_subdir_lib/csu/tests/dynamiclib --- > --- init_test.full --- > ld: error: unable to find library -lh_csu > c++: error: linker command failed with exit code 1 (use -v to see invocation) > --- all_subdir_usr.bin --- > --- all_subdir_usr.bin/bsdiff --- > ===> usr.bin/bsdiff (all) > --- all_subdir_lib --- > *** [init_test.full] Error code 1 > > make[7]: stopped in /usr/src/lib/csu/tests/dynamiclib > .ERROR_TARGET='init_test.full' > .ERROR_META_FILE='/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/lib/csu/tests/dynamiclib/init_test.full.meta' > .MAKE.LEVEL='7' > MAKEFILE='' > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' > _ERROR_CMD='c++ -mcpu=cortex-a7 -mcpu=cortex-a7 -target > armv7-gnueabihf-freebsd13.0 > --sysroot=/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/tmp > -B/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/tmp/usr/bin -O -pipe > -DDSO_BASE -I/usr/src/lib/csu/arm -g -Wsystem-headers -Wall -Wno-format-y2k > -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -Wno-empty-body > -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare > -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function > -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member > -Qunused-arguments -Wno-c++11-extensions > -Wl,-rpath,/usr/tests/lib/csu/dynamiclib > -L/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/lib/csu/tests/dso > -Wl,--no-threads -o init_test.full init_test.o -lh_csu -lprivateatf-c++ > -lprivateatf-c -lprivateatf-c;' > .CURDIR='/usr/src/lib/csu/tests/dynamiclib' > .MAKE='make' > .OBJDIR='/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/lib/csu/tests/dynamiclib' > .TARGETS=' all' > --- all_subdir_share --- > A failure has been detected in another branch of the parallel make > --- all_subdir_lib --- > DESTDIR='/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/tmp' > LD_LIBRARY_PATH='' > MACHINE='arm' > MACHINE_ARCH='armv7' > MAKEOBJDIRPREFIX='' > MAKESYSPATH='/usr/src/share/mk' > MAKE_VERSION='20180919' > PATH='/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/tmp/usr/sbin:/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/tmp/usr/bin:/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/tmp/legacy/usr/sbin:/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/tmp/legacy/usr/bin:/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/tmp/legacy/bin::/sbin:/bin:/usr/sbin:/usr/bin' > SRCTOP='/usr/src' > OBJTOP='/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7' > > I've not yet tried targeting aarch64, powerpc64, or powerpc . Looks like this might have been from a race condition or some such. Rerunning the meta-mode build again had no such problem and completed. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cannot build i386 12.0-RELEASE kernel on -current
Hi Henry, > On Dec 12, 2018, at 8:29 AM, Henry Vogt wrote: > > Hi, > > my build machine (FreeBSD:13:amd64 r341429) builds world/kernel ok for amd64, > world for i386 ok, but fails 'make buildkernel' for i386: > > -- snip > > ... > > --- if_vte.o --- > /usr/src/12/sys/dev/vte/if_vte.c:76:10: fatal error: 'miibus_if.h' file not > found > #include "miibus_if.h" > ^ > Building /usr/obj/usr/src/12/i386.i386/sys/MODULAR/msdosfs_denode.o > --- modules-all --- > --- all_subdir_accf_dns --- > ===> accf_dns (all) > Building /usr/obj/usr/src/12/i386.i386/sys/MODULAR/msdosfs_fat.o > --- if_vte.o --- > 1 error generated. > *** [if_vte.o] Error code 1 > > ... > > -- snip > > Is this known - did i miss something ? > Howto fix ? Did you run `make obj; make depend` beforehand or add miibus to your KERNCONF, like if_vte suggests? Cheers! -Enji VTE(4) FreeBSD Kernel Interfaces Manual VTE(4) NAME vte – Vortex86 RDC R6040 Fast Ethernet driver SYNOPSIS To compile this driver into the kernel, place the following lines in your kernel configuration file: device miibus device vte signature.asc Description: Message signed with OpenPGP
Re: cannot build i386 12.0-RELEASE kernel on -current
On Wed, 2018-12-12 at 19:33 +0300, Yuri Pankov wrote: > Henry Vogt wrote: > > > > Hi, > > > > my build machine (FreeBSD:13:amd64 r341429) builds world/kernel ok > > for amd64, world for i386 ok, but fails 'make buildkernel' for > > i386: > > > > -- snip > > > > ... > > > > --- if_vte.o --- > > /usr/src/12/sys/dev/vte/if_vte.c:76:10: fatal error: 'miibus_if.h' > > file not found > > #include "miibus_if.h" > > ^ > > Building /usr/obj/usr/src/12/i386.i386/sys/MODULAR/msdosfs_denode.o > > --- modules-all --- > > --- all_subdir_accf_dns --- > > ===> accf_dns (all) > > Building /usr/obj/usr/src/12/i386.i386/sys/MODULAR/msdosfs_fat.o > > --- if_vte.o --- > > 1 error generated. > > *** [if_vte.o] Error code 1 > > > > ... > > > > -- snip > > > > Is this known - did i miss something ? > > Howto fix ? > Does your "MODULAR" config file include "device miibus"? > It is possible to build miibus as a module, or not use it at all (and use just the specific phy driver(s) you need), but in that case you need 'device mii' in the kernel to get the minimal infrastructure needed to support the modules (which includes generating miibus_if.h). -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cannot build i386 12.0-RELEASE kernel on -current
Dear Yuri, Am 12.12.18 um 17:33 schrieb Yuri Pankov: > Henry Vogt wrote: >> Hi, >> >> my build machine (FreeBSD:13:amd64 r341429) builds world/kernel ok for >> amd64, world for i386 ok, but fails 'make buildkernel' for i386: >> >> -- snip >> >> ... >> >> --- if_vte.o --- >> /usr/src/12/sys/dev/vte/if_vte.c:76:10: fatal error: 'miibus_if.h' file not >> found >> #include "miibus_if.h" >> ^ >> Building /usr/obj/usr/src/12/i386.i386/sys/MODULAR/msdosfs_denode.o ... >> Howto fix ? > > Does your "MODULAR" config file include "device miibus"? No, it didn't. I added it to the config - Works now - Thanks. Best Henry -- Henry Vogt signature.asc Description: OpenPGP digital signature
Re: Ports build fails on 13-CURRENT r341690
On Mon, 10 Dec 2018 17:34:03 +0900 (JST) Yasuhiro KIMURA wrote: > Hello, > > yasu@rolling-vm-freebsd1[2018]% uname -a > FreeBSD rolling-vm-freebsd1.home.utahime.org 13.0-CURRENT FreeBSD > 13.0-CURRENT r341690 GENERIC amd64 yasu@rolling-vm-freebsd1[2019]% > LANG=C svn info /usr/src Path: /usr/src > Working Copy Root Path: /usr/src > URL: https://svn.freebsd.org/base/head > Relative URL: ^/head > Repository Root: https://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 341690 > Node Kind: directory > Schedule: normal > Last Changed Author: kib > Last Changed Rev: 341690 > Last Changed Date: 2018-12-08 00:19:00 +0900 (Sat, 08 Dec 2018) > > yasu@rolling-vm-freebsd1[2020]% LANG=C svn info /usr/ports > Path: /usr/ports > Working Copy Root Path: /usr/ports > URL: https://svn.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: https://svn.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 487116 > Node Kind: directory > Schedule: normal > Last Changed Author: yuri > Last Changed Rev: 487116 > Last Changed Date: 2018-12-10 10:06:34 +0900 (Mon, 10 Dec 2018) > > > Build of ports-mgmt/pkg fails as following. > > -- > > Compressing man pages (compress-man) > === > > === > ===> Building package for > >pkg-1.10.5_5 > install -l > rs /.npkg/All/pkg-1.10.5_5.txz /.npkg/Latest/pkg.txz > install: /.npkg/All/pkg-1.10.5_5.txz: realpath: No such file or > directory *** Error code 71 > > Stop. > make[1]: stopped in /usr/ports/ports-mgmt/pkg > *** Error code 1 > > Stop. > make: stopped in /usr/ports/ports-mgmt/pkg > =>> Cleaning up wrkdir > ===> Cleaning for pkg-1.10.5_5 > build of ports-mgmt/pkg | pkg-1.10.5_5 ended at Mon Dec 10 16:49:35 > JST 2018 build time: 00:03:50 > !!! build failure encountered !!! > -- > > Full build log: > https://www.utahime.org/FreeBSD/poudriere/data/logs/bulk/curamd64-local/2018-12-10_16h45m20s/logs/errors/pkg-1.10.5_5.log > > And this prevent any other ports from building. > > Does anyone else experience it? > > Best Regards. > > --- > Yasuhiro KIMURA Hi, I see the exact same problem on one of my powerpc64 machines (a P5020-based machine). I see it intermittently on my POWER9, so thought it was a race condition, but it's 100% reproducible on my P5020 machine. - Justin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cannot build i386 12.0-RELEASE kernel on -current
Henry Vogt wrote: > Hi, > > my build machine (FreeBSD:13:amd64 r341429) builds world/kernel ok for amd64, > world for i386 ok, but fails 'make buildkernel' for i386: > > -- snip > > ... > > --- if_vte.o --- > /usr/src/12/sys/dev/vte/if_vte.c:76:10: fatal error: 'miibus_if.h' file not > found > #include "miibus_if.h" > ^ > Building /usr/obj/usr/src/12/i386.i386/sys/MODULAR/msdosfs_denode.o > --- modules-all --- > --- all_subdir_accf_dns --- > ===> accf_dns (all) > Building /usr/obj/usr/src/12/i386.i386/sys/MODULAR/msdosfs_fat.o > --- if_vte.o --- > 1 error generated. > *** [if_vte.o] Error code 1 > > ... > > -- snip > > Is this known - did i miss something ? > Howto fix ? Does your "MODULAR" config file include "device miibus"? signature.asc Description: OpenPGP digital signature
cannot build i386 12.0-RELEASE kernel on -current
Hi, my build machine (FreeBSD:13:amd64 r341429) builds world/kernel ok for amd64, world for i386 ok, but fails 'make buildkernel' for i386: -- snip ... --- if_vte.o --- /usr/src/12/sys/dev/vte/if_vte.c:76:10: fatal error: 'miibus_if.h' file not found #include "miibus_if.h" ^ Building /usr/obj/usr/src/12/i386.i386/sys/MODULAR/msdosfs_denode.o --- modules-all --- --- all_subdir_accf_dns --- ===> accf_dns (all) Building /usr/obj/usr/src/12/i386.i386/sys/MODULAR/msdosfs_fat.o --- if_vte.o --- 1 error generated. *** [if_vte.o] Error code 1 ... -- snip Is this known - did i miss something ? Howto fix ? Best Henry -- Henry Vogt ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pkg-base noise
> On Dec 11, 2018, at 11:14 AM, Ian Lepore wrote: > > On Tue, 2018-12-11 at 11:40 -0700, Sean Bruno wrote: >> make[8]: "/home/sbruno/bsd/fbsd_head/share/mk/bsd.files.mk" line 92: >> warning: duplicate script for target "_testsFILESINS_cleanup.ksh" >> ignored >> make[8]: "/home/sbruno/bsd/fbsd_head/share/mk/bsd.files.mk" line 92: >> warning: using previous script for "_testsFILESINS_cleanup.ksh" >> defined here >> >> >> Is this something easily fixable? I'm unclear what is throwing a >> warning here? >> >> sean >> > > Looks like some makefile has cleanup.ksh listed twice in a FILES= list. Yup — that would be the case! -Enji signature.asc Description: Message signed with OpenPGP
Re: r111 build error
On Wed, 12 Dec 2018 at 07:35, Lev Serebryakov wrote:
>
> On 12.12.2018 14:59, Dimitry Andric wrote:
>
> ld: error: undefined symbol: clang::CallExpr::getLocStart() const
> >>> referenced by MacOSXAPIChecker.cpp:86
> >>> (/usr/src/contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers/MacOSXAPIChecker.cpp:86)
> >>> MacOSXAPIChecker.o:((anonymous
> >>> namespace)::MacOSXAPIChecker::CheckDispatchOnce(clang::ento::CheckerContext&,
> >>> clang::CallExpr const*, llvm::StringRef) const) in
> >>> archive /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a
> >
> > Any ideas on how to reproduce this build failure? I have run multiple
> > universe builds before committing this update, and I never saw any error
> > which resembles the above.
> rm -rf /usr/obj/src helps to get rid of this error. I've had /usr/obj
> from previous version (but I didn't use -DNO_CLEAN!).
This sounds like a similar issue to one I fixed in r341796 after the
most recent wpa update - there are a few cases of source changes that
are not handled well by .depend files. While we could take this to
root cause I think the most expedient fix is probably just to check
for evidence of clang 6 in the object tree, and rm the .depend files
and objects if found. Checking for clang 6 can be done by grepping for
a file removed in the clang 7 update. This approach is rather hacky,
but has allowed builds with -DNO_CLEAN to succeed for the last year
and a half or so, and the hacks do not need to persist indefinitely.
It would look something like:
@if [ -e "${OBJTOP}/lib/clang/.../.depend.foo.o" ] && \
egrep -q 'some/file/removed/in/clang7.c' \
${OBJTOP}/lib/clang/.../.depend.foo.o; then \
echo "Removing stale clang 6 dependencies and objects"; \
find ${OBJTOP}/lib/clang -name '.depend.*' -o -name '*.o' -delete \
fi
I might move these cleanup hacks out into a standalone shell script to
make it easier to test and maintain them.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
WITH_META_MODE: any effect? Tree built twice!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I just updated sources /usr/src to r341879 (13-CURRENT). To have a clean, new build, performing of "make cleanwolrd cleandir" has been issued and I have set WITH_META_MODE= in /etc/src-env.conf. Loading filemon.ko and rebuilding world and kernel takes on my IvyBridge 2-core box aeons. My other box, a XEON E3-1245 V2 @ 3.40GH based box, once took ~ 40 minutes to buildword and buildkernel from a clean buildtree (with LLVM/CLANG extras set to be build!), and that system now is also beyond 90 minutes, starting earlier this year. You see, there is a reason to cut down build times. Well, after rebuilding world/kernel and installing those, mergemaster and make delete-old|-libs afterwards, I started again a build (filemon loaded!). And, surprise, surprise, compilation of all the long-haul taking LLVM/CLANG stuff starts again! That is not funny. Why do I have to rebuild world twice to get WITH_META_MODE in effect? My in-effect settings in /etc/src.conf are as follows: # CPUTYPE?= native # CFLAGS+=-O3 # for the kernel COPTFLAGS+= -O3 # #CXXFLAGS+= -std=c++11 # WITH_CLANG_EXTRAS= YES WITH_LLDB= YES WITH_LLD_IS_LD= YES # eBPF WITH_LLVM_TARGET_BPF= YES # WITH_IDEA= YES # #WITH_BSD_GREP= YES # WITH_OFED_EXTRA=YES WITH_NAND= YES #WITH_CTF= YES # WITH_SVN= YES # # Enable building openldap support for kerberos. #WITH_OPENLDAP= YES # WITH_SORT_THREADS= YES # WITH_EXTRA_TCP_STACKS= YES # WITH_ZONEINFO_LEAPSECONDS_SUPPORT= YES # MALLOC_PRODUCTION= YES # WITHOUT_ASSERT_DEBUG= YES # WITHOUT_TESTS= YES # WITHOUT_DEBUG_FILES=YES # WITHOUT_REPRODUCIBLE_BUILD= YES # # mitigation for CVE-2017-5715 in the kernel build #WITH_KERNEL_RETPOLINE= YES These setting dind't change over the past time, except some WITHOUT_ tags. Are there any unrevealed secrets? The boxes in question do have 8 GB RAM (two core/4 threads box, base system residing on UFS/FFS 256GB Samsung 850 Pro SSD, two ZFS volumes for /home and /usr/ports aboard), and 16 GB RAM (4 cores/8thread XEON box, base system on UFS/FFS 256 GB Samsung 850 Pro SSD, ZFS RAIDZ volume of 16 TB as data graveyard). Thanks in advance. oh - -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). -BEGIN PGP SIGNATURE- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCXBEDpQAKCRDS528fyFhY lMrDAgCnnh1oIWQuNIEb8Es59SGxW5OwQe1KxnRdwOc1lsXJOuBj4lh1pykHavWG S7iY0/QrXLFNhDsNPhiz0CRqO2MyAf47nIQ4olxb7qmUx3MtatUk8VV37USqwVTA gm4pYSgySmH0qKb8BN65VJg19VDkbUEKi1zIwZGMlKQSVq0a3+hO =XMEQ -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r111 build error
On 12.12.2018 14:59, Dimitry Andric wrote: ld: error: undefined symbol: clang::CallExpr::getLocStart() const >>> referenced by MacOSXAPIChecker.cpp:86 >>> (/usr/src/contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers/MacOSXAPIChecker.cpp:86) >>> MacOSXAPIChecker.o:((anonymous >>> namespace)::MacOSXAPIChecker::CheckDispatchOnce(clang::ento::CheckerContext&, >>> clang::CallExpr const*, llvm::StringRef) const) in >>> archive /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a > > Any ideas on how to reproduce this build failure? I have run multiple > universe builds before committing this update, and I never saw any error > which resembles the above. rm -rf /usr/obj/src helps to get rid of this error. I've had /usr/obj from previous version (but I didn't use -DNO_CLEAN!). > It almost looks as if your libclang.a is not rebuilt properly, or not > built at all. Can you show the time stamps of: I can not, as I cleaned up /usr/obj/src and now I have clean build. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: r111 build error
On 12 Dec 2018, at 10:24, O. Hartmann wrote: > > Am Wed, 12 Dec 2018 10:06:02 +0100 > Gary Jennejohn schrieb: > > > On Wed, 12 Dec 2018 02:11:10 +0300 > > Lev Serebryakov wrote: > > > > > Hello Freebsd-current, > > > > > > I'm building very last r341836 (with new llvm/clang 7) on r341726 and > > > get this build > > > error (with MALLOC_PRODUCTION=yes): > > > > > > > Worked for me from r341824 to r341840, but I deleted /usr/obj/usr > > before starting the build. I even added MALLOC_PRODUCTION=yes to > > /etc/src.conf. > > A "me, too" from here. I have also MALLOC_PRODUCTION=yes in /etc/src.conf, > but I did, as > usual, a "make cleanworld" prior to the sebsequent system's > buildworld/buildkernel. > > > > > > ===> usr.bin/clang/clang (all) > > > c++ -target x86_64-unknown-freebsd13.0 > > > --sysroot=/usr/obj/usr/src/amd64.amd64/tmp > > > -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe > > > -I/usr/obj/usr/src/amd64.amd64/lib/clang/libclang > > > -I/usr/obj/usr/src/amd64.amd64/lib/clang/libllvm > > > -I/usr/src/contrib/llvm/tools/clang/include -DCLANG_ENABLE_ARCMT > > > -DCLANG_ENABLE_STATIC_ANALYZER -I/usr/src/lib/clang/include > > > -I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL > > > -D__STDC_LIMIT_MACROS > > > -D__STDC_CONSTANT_MACROS > > > -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd13.0\" > > > -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd13.0\" -DDEFAULT_SYSROOT=\"\" > > > -DLLVM_TARGET_ENABLE_AARCH64 -DLLVM_TARGET_ENABLE_ARM > > > -DLLVM_TARGET_ENABLE_MIPS > > > -DLLVM_TARGET_ENABLE_POWERPC -DLLVM_TARGET_ENABLE_SPARC > > > -DLLVM_TARGET_ENABLE_X86 > > > -DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser > > > -DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter > > > -DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler > > > -DLLVM_NATIVE_TARGET=LLVMInitializeX86Target > > > -DLLVM_NATIVE_TARGETINFO=LLVMInit > > ia > > > lizeX86TargetInfo -DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC > > > -ffunction-sections -fdata-sections -gline-tables-only > > > -fstack-protector-strong > > > -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable > > > -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality > > > -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef > > > -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum > > > -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -std=c++11 > > > -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions > > > -Wl,--gc-sections > > > -static -o clang.full cc1_main.o cc1as_main.o cc1gen_reproducer_main.o > > > driver.o /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a > > > /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a > > > -lz -lncursesw -lpthread ld: error: undefined symbol: > > > clang::LocationContext::getCurrentStackFrame() const > > > >>> referenced by ExplodedGraph.h:138 > > > >>> (/usr/src/contrib/llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExplodedGraph.h:138) > > > >>> ReturnUndefChecker.o:(void > > > >>> clang::ento::check::PreStmt::_checkStmt<(anonymous > > > >>> namespace)::ReturnUndefChecker>(void*, clang::Stmt const*, > > > >>> clang::ento::CheckerContext&)) in > > > >>> archive /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a > > > > > > ld: error: undefined symbol: clang::CallExpr::getLocStart() const > > > >>> referenced by MacOSXAPIChecker.cpp:86 > > > >>> (/usr/src/contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers/MacOSXAPIChecker.cpp:86) > > > >>> MacOSXAPIChecker.o:((anonymous > > > >>> namespace)::MacOSXAPIChecker::CheckDispatchOnce(clang::ento::CheckerContext&, > > > >>> clang::CallExpr const*, llvm::StringRef) const) in > > > >>> archive /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a Any ideas on how to reproduce this build failure? I have run multiple universe builds before committing this update, and I never saw any error which resembles the above. It almost looks as if your libclang.a is not rebuilt properly, or not built at all. Can you show the time stamps of: /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a -Dimitry signature.asc Description: Message signed with OpenPGP
Re: freebsd-current Digest, Vol 789, Issue 3
Отмена 12 дек. 2018 г. 14:30 пользователь написал: Send freebsd-current mailing list submissions to freebsd-current@freebsd.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.freebsd.org/mailman/listinfo/freebsd-current or, via email, send a message with subject or body 'help' to freebsd-current-requ...@freebsd.org You can reach the person managing the list at freebsd-current-ow...@freebsd.org When replying, please edit your Subject line so it is more specific than "Re: Contents of freebsd-current digest..." Today's Topics: 1. Re: Composite PCI devices in FreeBSD (mfd in Linux) (Emiel Kollof) 2. FreeBSD 12.0 RC3 PPC report (Alex McKeever) 3. pkg-base noise (Sean Bruno) 4. Re: pkg-base noise (Ian Lepore) 5. Linux is considering dropping x32. (Alexandre C. Guimar?es) 6. Re: Linux is considering dropping x32. (Kris Moore) 7. Re: Linux is considering dropping x32. (Konstantin Belousov) 8. Re: Linux is considering dropping x32. (Kris Moore) 9. Re: Linux is considering dropping x32. (Jung-uk Kim) 10. Re: Linux is considering dropping x32. (Nathan Whitehorn) 11. Re: Linux is considering dropping x32. (Hadi Rezaee) 12. r111 build error (Lev Serebryakov) 13. Re: r341836 build error (Lev Serebryakov) 14. test (Sean Bruno) 15. head -r341836 (jump to clang 7): amd64 -> armv7 cross build failed: ld: error: unable to find library -lh_csu (Mark Millard) 16. Re: Composite PCI devices in FreeBSD (mfd in Linux) (Anthony Jenkins) 17. Re: r111 build error (Gary Jennejohn) 18. Re: r111 build error (O. Hartmann) -- Message: 1 Date: Tue, 11 Dec 2018 15:02:52 +0100 From: Emiel Kollof To: Anthony Jenkins Cc: FreeBSD CURRENT , owner-freebsd-curr...@freebsd.org Subject: Re: Composite PCI devices in FreeBSD (mfd in Linux) Message-ID: Content-Type: text/plain; charset=US-ASCII; format=flowed Anthony Jenkins schreef op 2018-12-10 18:00: > Hi all, > > I'm trying to port an Intel PCI I2C controller from Linux to FreeBSD. > Linux represents this device as an MFD (multi-function device), meaning > it has these "sub-devices" that can be handed off to other drivers to > actually attach devices to the system. The Linux "super" PCI device is > the intel-lpss-pci.c, and the "sub" device is i2c-designware-platdrv.c, > which represents the DesignWare driver's "platform" attachment to the > Linux system. FreeBSD also has a DesignWare I2C controller driver, > ig4(4), but it only has PCI and ACPI bus attachment implementations. Might this also be relevant for i2c-hid devices, like some touchpads (Elantech for example)? Cheers, Emiel -- Message: 2 Date: Tue, 11 Dec 2018 13:45:06 + (UTC) From: Alex McKeever To: FreeBSD Current Subject: FreeBSD 12.0 RC3 PPC report Message-ID: <948957337.2497926.1544535906...@mail.yahoo.com> Content-Type: text/plain; charset=UTF-8 It?s working fine on my eMac G4/1.25 GHz retail model. The CDE Desktop Environment is oddly broken, but I am pleased to report that most of the packages I?ve compiled have done so successfully unlike 11.1! Sent from Yahoo Mail for iPhone -- Message: 3 Date: Tue, 11 Dec 2018 11:40:05 -0700 From: Sean Bruno To: freebsd-current Subject: pkg-base noise Message-ID: Content-Type: text/plain; charset="utf-8" make[8]: "/home/sbruno/bsd/fbsd_head/share/mk/bsd.files.mk" line 92: warning: duplicate script for target "_testsFILESINS_cleanup.ksh" ignored make[8]: "/home/sbruno/bsd/fbsd_head/share/mk/bsd.files.mk" line 92: warning: using previous script for "_testsFILESINS_cleanup.ksh" defined here Is this something easily fixable? I'm unclear what is throwing a warning here? sean -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 618 bytes Desc: OpenPGP digital signature URL: < http://lists.freebsd.org/pipermail/freebsd-current/attachments/20181211/a0bbc9c2/attachment-0001.sig > -- Message: 4 Date: Tue, 11 Dec 2018 12:14:15 -0700 From: Ian Lepore To: Sean Bruno , freebsd-current Subject: Re: pkg-base noise Message-ID: <1544555655.44045.13.ca...@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" On Tue, 2018-12-11 at 11:40 -0700, Sean Bruno wrote: > make[8]: "/home/sbruno/bsd/fbsd_head/share/mk/bsd.files.mk" line 92: > warning: duplicate script for target "_testsFILESINS_cleanup.ksh" > ignored > make[8]: "/home/sbruno/bsd/fbsd_head/share/mk/bsd.files.mk" line 92: > warning: using previous script for "_testsFILESINS_cleanup.ksh" > defined here > > > Is this something easily fixable???I'm unclear what is throwing a > warning here? > > sean > Looks like some makefile has cleanup.ksh listed twice in a FILES= list. -- Ian -- Message: 5 Date: Tue, 11 Dec 2018
Re: r111 build error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Wed, 12 Dec 2018 10:06:02 +0100 Gary Jennejohn schrieb: > On Wed, 12 Dec 2018 02:11:10 +0300 > Lev Serebryakov wrote: > > > Hello Freebsd-current, > > > > I'm building very last r341836 (with new llvm/clang 7) on r341726 and get > > this build > > error (with MALLOC_PRODUCTION=yes): > > > > Worked for me from r341824 to r341840, but I deleted /usr/obj/usr > before starting the build. I even added MALLOC_PRODUCTION=yes to > /etc/src.conf. A "me, too" from here. I have also MALLOC_PRODUCTION=yes in /etc/src.conf, but I did, as usual, a "make cleanworld" prior to the sebsequent system's buildworld/buildkernel. > > > ===> usr.bin/clang/clang (all) > > c++ -target x86_64-unknown-freebsd13.0 > > --sysroot=/usr/obj/usr/src/amd64.amd64/tmp > > -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe > > -I/usr/obj/usr/src/amd64.amd64/lib/clang/libclang > > -I/usr/obj/usr/src/amd64.amd64/lib/clang/libllvm > > -I/usr/src/contrib/llvm/tools/clang/include -DCLANG_ENABLE_ARCMT > > -DCLANG_ENABLE_STATIC_ANALYZER -I/usr/src/lib/clang/include > > -I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL > > -D__STDC_LIMIT_MACROS > > -D__STDC_CONSTANT_MACROS > > -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd13.0\" > > -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd13.0\" -DDEFAULT_SYSROOT=\"\" > > -DLLVM_TARGET_ENABLE_AARCH64 -DLLVM_TARGET_ENABLE_ARM > > -DLLVM_TARGET_ENABLE_MIPS > > -DLLVM_TARGET_ENABLE_POWERPC -DLLVM_TARGET_ENABLE_SPARC > > -DLLVM_TARGET_ENABLE_X86 > > -DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser > > -DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter > > -DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler > > -DLLVM_NATIVE_TARGET=LLVMInitializeX86Target > > -DLLVM_NATIVE_TARGETINFO=LLVMInit > ia > > lizeX86TargetInfo -DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC > > -ffunction-sections -fdata-sections -gline-tables-only > > -fstack-protector-strong > > -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable > > -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality > > -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef > > -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum > > -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -std=c++11 > > -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions > > -Wl,--gc-sections > > -static -o clang.full cc1_main.o cc1as_main.o cc1gen_reproducer_main.o > > driver.o /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a > > /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a > > -lz -lncursesw -lpthread ld: error: undefined symbol: > > clang::LocationContext::getCurrentStackFrame() const > > >>> referenced by ExplodedGraph.h:138 > > >>> (/usr/src/contrib/llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExplodedGraph.h:138) > > >>> ReturnUndefChecker.o:(void > > >>> clang::ento::check::PreStmt::_checkStmt<(anonymous > > >>> namespace)::ReturnUndefChecker>(void*, clang::Stmt const*, > > >>> clang::ento::CheckerContext&)) in > > >>> archive /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a > > > > ld: error: undefined symbol: clang::CallExpr::getLocStart() const > > >>> referenced by MacOSXAPIChecker.cpp:86 > > >>> (/usr/src/contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers/MacOSXAPIChecker.cpp:86) > > >>> MacOSXAPIChecker.o:((anonymous > > >>> namespace)::MacOSXAPIChecker::CheckDispatchOnce(clang::ento::CheckerContext&, > > >>> clang::CallExpr const*, llvm::StringRef) const) in > > >>> archive /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a > > > > ld: error: undefined symbol: clang::Stmt::getLocStart() const > > >>> referenced by DeadStoresChecker.cpp:265 > > >>> (/usr/src/contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp:265) > > >>> DeadStoresChecker.o:((anonymous > > >>> namespace)::DeadStoreObs::observeStmt(clang::Stmt > > >>> const*, clang::CFGBlock const*, clang::LiveVariables::LivenessValues > > >>> const&)) in > > >>> archive /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a > > > > ld: error: undefined symbol: clang::CodeSegAttr::clone(clang::ASTContext&) > > const > > >>> referenced by SemaDecl.cpp:0 > > >>> (/usr/src/contrib/llvm/tools/clang/lib/Sema/SemaDecl.cpp:0) > > >>> SemaDecl.o:(clang::Sema::getImplicitCodeSegOrSectionAttrForFunction(clang::FunctionDecl > > >>> const*, bool)) in > > >>> archive /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a > > > > ld: error: undefined symbol: > > clang::ArtificialAttr::clone(clang::ASTContext&) const > > >>> referenced by AttrTemplateInstantiate.inc:150 > > >>> (/usr/obj/usr/src/amd64.amd64/lib/clang/libclang/clang/Sema/AttrTemplateInstantiate.inc:150) > > >>> SemaTemplateInstantiateDecl.o:(clang::sema::instantiateTemplateAttribute(clang::Attr > > >>> const*, clang::ASTContext&, clang::Sema&, > > >>>
Re: r111 build error
On Wed, 12 Dec 2018 02:11:10 +0300 Lev Serebryakov wrote: > Hello Freebsd-current, > > I'm building very last r341836 (with new llvm/clang 7) on r341726 and get > this build > error (with MALLOC_PRODUCTION=yes): > Worked for me from r341824 to r341840, but I deleted /usr/obj/usr before starting the build. I even added MALLOC_PRODUCTION=yes to /etc/src.conf. > ===> usr.bin/clang/clang (all) > c++ -target x86_64-unknown-freebsd13.0 > --sysroot=/usr/obj/usr/src/amd64.amd64/tmp > -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe > -I/usr/obj/usr/src/amd64.amd64/lib/clang/libclang > -I/usr/obj/usr/src/amd64.amd64/lib/clang/libllvm > -I/usr/src/contrib/llvm/tools/clang/include -DCLANG_ENABLE_ARCMT > -DCLANG_ENABLE_STATIC_ANALYZER -I/usr/src/lib/clang/include > -I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL > -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS > -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd13.0\" > -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd13.0\" -DDEFAULT_SYSROOT=\"\" > -DLLVM_TARGET_ENABLE_AARCH64 -DLLVM_TARGET_ENABLE_ARM > -DLLVM_TARGET_ENABLE_MIPS -DLLVM_TARGET_ENABLE_POWERPC > -DLLVM_TARGET_ENABLE_SPARC -DLLVM_TARGET_ENABLE_X86 > -DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser > -DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter > -DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler > -DLLVM_NATIVE_TARGET=LLVMInitializeX86Target -DLLVM_NATIVE_TARGETINFO=LLVMInit ia > lizeX86TargetInfo -DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC > -ffunction-sections -fdata-sections -gline-tables-only > -fstack-protector-strong -Wno-empty-body -Wno-string-plus-int > -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value > -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion > -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch > -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses > -Qunused-arguments -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ > -Wno-c++11-extensions -Wl,--gc-sections -static -o clang.full cc1_main.o > cc1as_main.o cc1gen_reproducer_main.o driver.o > /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a > /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a -lz -lncursesw > -lpthread > ld: error: undefined symbol: clang::LocationContext::getCurrentStackFrame() > const > >>> referenced by ExplodedGraph.h:138 > >>> (/usr/src/contrib/llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExplodedGraph.h:138) > >>> ReturnUndefChecker.o:(void > >>> clang::ento::check::PreStmt::_checkStmt<(anonymous > >>> namespace)::ReturnUndefChecker>(void*, clang::Stmt const*, > >>> clang::ento::CheckerContext&)) in archive > >>> /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a > > ld: error: undefined symbol: clang::CallExpr::getLocStart() const > >>> referenced by MacOSXAPIChecker.cpp:86 > >>> (/usr/src/contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers/MacOSXAPIChecker.cpp:86) > >>> MacOSXAPIChecker.o:((anonymous > >>> namespace)::MacOSXAPIChecker::CheckDispatchOnce(clang::ento::CheckerContext&, > >>> clang::CallExpr const*, llvm::StringRef) const) in archive > >>> /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a > > ld: error: undefined symbol: clang::Stmt::getLocStart() const > >>> referenced by DeadStoresChecker.cpp:265 > >>> (/usr/src/contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp:265) > >>> DeadStoresChecker.o:((anonymous > >>> namespace)::DeadStoreObs::observeStmt(clang::Stmt const*, clang::CFGBlock > >>> const*, clang::LiveVariables::LivenessValues const&)) in archive > >>> /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a > > ld: error: undefined symbol: clang::CodeSegAttr::clone(clang::ASTContext&) > const > >>> referenced by SemaDecl.cpp:0 > >>> (/usr/src/contrib/llvm/tools/clang/lib/Sema/SemaDecl.cpp:0) > >>> > >>> SemaDecl.o:(clang::Sema::getImplicitCodeSegOrSectionAttrForFunction(clang::FunctionDecl > >>> const*, bool)) in archive > >>> /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a > > ld: error: undefined symbol: clang::ArtificialAttr::clone(clang::ASTContext&) > const > >>> referenced by AttrTemplateInstantiate.inc:150 > >>> (/usr/obj/usr/src/amd64.amd64/lib/clang/libclang/clang/Sema/AttrTemplateInstantiate.inc:150) > >>> > >>> SemaTemplateInstantiateDecl.o:(clang::sema::instantiateTemplateAttribute(clang::Attr > >>> const*, clang::ASTContext&, clang::Sema&, > >>> clang::MultiLevelTemplateArgumentList const&)) in archive > >>> /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a > > ld: error: undefined symbol: > clang::CPUDispatchAttr::clone(clang::ASTContext&) const > >>> referenced by AttrTemplateInstantiate.inc:243 > >>> (/usr/obj/usr/src/amd64.amd64/lib/clang/libclang/clang/Sema/AttrTemplateInstantiate.inc:243) > >>> > >>>
