Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)
On Sat, 15 Apr 2017 09:30:49 +1000 (AEST) Gerald Pfeifer <ger...@pfeifer.com> wrote: > On Thu, 13 Apr 2017, Pedro Giffuni wrote: > > I didn't want to get into this but the problem is that as part of > > it's build/bootstrapping process, GCC historically takes system > > headers and attempts to "fix" them. I am unsure the fixes do > > anything at all nowadays but the effect is that the compiler tends > > to take snapshots of the system headers when it is built. cdefs.h > > is used by all the system headers so changes in cdefs.h have good > > chances affecting such builds but any change are likely to cause > > similar trouble. > > > > In the case of gcc-aux, it appears the compilation is based on a > > bootstrap compiler which already carries outdated headers. > > A workaround, suggested by gerald@ the last time a similar issue > > happened was to run for install-tools/fixinc.sh. I think that may > > regenerate the headers and let the build use updated headers. > > Ultimately gcc-aux needs maintainer intervention and using > > outdated headers will break sooner or later: especially on > > -current. > > Indeed, thanks for the analysis/background, Pedro! > > I had a look at gcc6-aux is based on the 20170202 snapshot of GCC 6, > and perhaps John (as the maintainer of that port) has plans to update > it? Let me copy him. > > Gerald > > PS: John, if you have an update, happy to help and apply that for you. Hi Gerald, it was suggested multiple times that the whole fixinc step is ultimately harmful and serves no useful purpose and probably should be disabled in built packages outright. Is there a reason not to do it? Even Redhat appears to do the slimming in their rpms: mv $FULLPATH/include-fixed/syslimits.h $FULLPATH/include/syslimits.h mv $FULLPATH/include-fixed/limits.h $FULLPATH/include/limits.h for h in `find $FULLPATH/include -name \*.h`; do if grep -q 'It has been auto-edited by fixincludes from' $h; then rh=`grep -A2 'It has been auto-edited by fixincludes from' $h | tail -1 | sed 's|^.*"\(.*\)".*$|\1|'` diff -up $rh $h || : rm -f $h fi done -- Alexander Kabaev pgpG5jabvm7gZ.pgp Description: Цифровая подпись OpenPGP
Re: FYI on aarch64: building and installing devel/aarch64-gcc fails with "Unable to access file" for 6 files
aarch64-gcc is not a full compiler, but one intended to be used as cross toolchain. Said that, when built on x86-64, it does have gcov and man pages, so this must be an artefact of your build environment or your aarch64 setup, as this never was tested when run natively nor was it meant to be - there is unfinished work in ports/base to create native toolchain. Please provide full log of your port build soemwhere, though I will not be able to look at it under weekend at the earliest. % pkg info -l aarch64-gcc-6.3.0 | grep gcov /usr/local/bin/aarch64-unknown-freebsd12.0-gcov /usr/local/bin/aarch64-unknown-freebsd12.0-gcov-tool /usr/local/lib/gcc/aarch64-unknown-freebsd12.0/6.3.0/plugin/include/gcov-counter.def /usr/local/lib/gcc/aarch64-unknown-freebsd12.0/6.3.0/plugin/include/gcov-io.h /usr/local/man/man1/aarch64-unknown-freebsd12.0-gcov.1.gz Thanks, On Wed, 19 Apr 2017 17:09:34 -0700 Mark Millard <mar...@dsl-only.net> wrote: > The attempt to build & install devel/aarch64-gcc on a aarch64 > environment gets (I use WRKDIRPREFIX=/usr/obj/portswork ): > > ===> Installing for aarch64-gcc-6.3.0 > ===> Checking if aarch64-gcc already installed > ===> Registering installation for aarch64-gcc-6.3.0 as automatic > pkg-static: Unable to access > file > /usr/obj/portswork/usr/ports/devel/aarch64-gcc/work/stage/usr/local/bin/aarch64-unknown-freebsd12.0-gcov:No > such file or directory pkg-static: Unable to access > file > /usr/obj/portswork/usr/ports/devel/aarch64-gcc/work/stage/usr/local/bin/aarch64-unknown-freebsd12.0-gcov-tool:No > such file or directory pkg-static: Unable to access > file > /usr/obj/portswork/usr/ports/devel/aarch64-gcc/work/stage/usr/local/man/man1/aarch64-unknown-freebsd12.0-cpp.1.gz:No > such file or directory pkg-static: Unable to access > file > /usr/obj/portswork/usr/ports/devel/aarch64-gcc/work/stage/usr/local/man/man1/aarch64-unknown-freebsd12.0-g++.1.gz:No > such file or directory pkg-static: Unable to access > file > /usr/obj/portswork/usr/ports/devel/aarch64-gcc/work/stage/usr/local/man/man1/aarch64-unknown-freebsd12.0-gcc.1.gz:No > such file or directory pkg-static: Unable to access > file > /usr/obj/portswork/usr/ports/devel/aarch64-gcc/work/stage/usr/local/man/man1/aarch64-unknown-freebsd12.0-gcov.1.gz:No > such file or directory *** Error code 74 > > Stop. > make: stopped in /usr/ports/devel/aarch64-gcc > > ===>>> Installation of aarch64-gcc-6.3.0 (devel/aarch64-gcc) failed > > > A hack before doing a portmaster -CDK lang/aarch64-gcc to continue > the build/install is to execute the script shown below (I use > WRKDIRPREFIX=/usr/obj/portswork ): > > # more ~/aarch64-gcc_fixup.sh > #!/bin/sh > cp > -ax /usr/obj/portswork/usr/ports/devel/aarch64-gcc/work/.build/gcc/gcov > /usr/obj/portswork/usr/ports/devel/aarch64-gcc/work/stage/usr/local/bin/aarch64-unknown-freebsd12.0-gcov > > cp > -ax /usr/obj/portswork/usr/ports/devel/aarch64-gcc/work/.build/gcc/gcov-tool > /usr/obj/portswork/usr/ports/devel/aarch64-gcc/work/stage/usr/local/bin/aarch64-unknown-freebsd12.0-gcov-tool > > gzip > -c /usr/obj/portswork/usr/ports/devel/aarch64-gcc/work/gcc-*/gcc/doc/cpp.1 > > /usr/obj/portswork/usr/ports/devel/aarch64-gcc/work/stage/usr/local/man/man1/aarch64-unknown-freebsd12.0-cpp.1.gz > > gzip > -c /usr/obj/portswork/usr/ports/devel/aarch64-gcc/work/.build/gcc/doc/g++.1 > > /usr/obj/portswork/usr/ports/devel/aarch64-gcc/work/stage/usr/local/man/man1/aarch64-unknown-freebsd12.0-g++.1.gz > > gzip > -c /usr/obj/portswork/usr/ports/devel/aarch64-gcc/work/.build/gcc/doc/gcc.1 > > /usr/obj/portswork/usr/ports/devel/aarch64-gcc/work/stage/usr/local/man/man1/aarch64-unknown-freebsd12.0-gcc.1.gz > > gzip > -c /usr/obj/portswork/usr/ports/devel/aarch64-gcc/work/gcc-*/gcc/doc/gcov.1 > > /usr/obj/portswork/usr/ports/devel/aarch64-gcc/work/stage/usr/local/man/man1/aarch64-unknown-freebsd12.0-gcov.1.gz > > That puts in place the files that are not where they are expected. > > Of course this sort of hack-then-continue would not fit well > with poudriere use or analogous build techniques. > > > The same sort of thing happens for lang/powerpc64 on a powerpc64 > environment. > > As I remember. . . > The same sort of thing happens for lang/amd64 on a amd64 > environment. > > So I have ~/powerpc64-gcc_fixup.sh and ~/amd64-gcc_fixup.sh > as well. > > > I get to these ???-gcc's by trying to install a > self-hosted lang/???-xtoolchain-gcc in each case. > Such allows for experimenting with self-hosted gcc > based system builds that are libc++ based (instead > of using gcc 4.2.1). > > === > Mark Millard > markmi at dsl-only.net > > ___ > freebsd-...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org" -- Alexander Kabaev pgpBs3WB8qnxL.pgp Description: Цифровая подпись OpenPGP
Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)
On Wed, 19 Jul 2017 22:50:04 +0200 (CEST) Gerald Pfeifer <ger...@pfeifer.com> wrote: > On Fri, 14 Apr 2017, Alexander Kabaev wrote: > > it was suggested multiple times that the whole fixinc step is > > ultimately harmful and serves no useful purpose and probably should > > be disabled in built packages outright. Is there a reason not to do > > it? Even Redhat appears to do the slimming in their rpms: > > For the more current lang/gcc* ports (not the gcc5-aux and gcc6-aux > ports which I do not maintain) I have now removed packaging the > headers processed by fixincludes, so any problems in that direction > should be gone. > > Gerald Thank you, Gerald! -- Alexander Kabaev pgpGWVxeaZmdj.pgp Description: Цифровая подпись OpenPGP
Re: Attempting a xtoolchain-gcc head amd64->aarch64 cross buildworld failed for liblto_plugin.so loading error
:/usr/bin' > SRCTOP='/usr/src' > OBJTOP='/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64' > .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk > /usr/src/share/mk/src.sys.env.mk > /root/src.configs/src.conf.cortexA53-xtoolchain-gcc.amd64-host > /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk > /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk > /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk > /usr/src/share/mk/src.sys.mk /dev/null /usr/src/lib/libc/Makefile > /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk > /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk > /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk > /usr/src/lib/libc/aarch64/Makefile.inc /usr/src/lib/libc/db/Makefile.inc > /usr/src/lib/libc/db/btree/Makefile.inc /usr/src/lib/libc/db/db/Makefile.inc > /usr/src/lib/libc/db/hash/Makefile.inc /usr/src/lib/libc/db/man/Makefile.inc > /usr/src/lib/libc/db/mpool/Makefile.inc > /usr/src/lib/libc/db/recno/Makefile.inc > /usr/src/lib/libc/compat-43/Makefile.inc /usr/src/lib/libc/gdtoa/Makefile.inc > /us > r/src/lib/libc/gen/Makefile.inc /usr/src/lib/libc/aarch64/gen/Makefile.inc > /usr/src/lib/libc/gmon/Makefile.inc /usr/src/lib/libc/iconv/Makefile.inc > /usr/src/lib/libc_nonshared/Makefile.iconv > /usr/src/lib/libc/inet/Makefile.inc /usr/src/lib/libc/isc/Makefile.inc > /usr/src/lib/libc/locale/Makefile.inc /usr/src/lib/libc/md/Makefile.inc > /usr/src/lib/libc/nameser/Makefile.inc /usr/src/lib/libc/net/Makefile.inc > /usr/src/lib/libc/nls/Makefile.inc /usr/src/lib/libc/posix1e/Makefile.inc > /usr/src/lib/libc/regex/Makefile.inc /usr/src/lib/libc/resolv/Makefile.inc > /usr/src/lib/libc/stdio/Makefile.inc /usr/src/lib/libc/stdlib/Makefile.inc > /usr/src/lib/libc/stdlib/jemalloc/Makefile.inc > /usr/src/lib/libc/stdtime/Makefile.inc /usr/src/lib/libc/string/Makefile.inc > /usr/src/lib/libc/aarch64/string/Makefile.inc > /usr/src/lib/libc/sys/Makefile.inc /usr/src/sys/sys/syscall.mk > /usr/src/lib/libc/aarch64/sys/Makefile.inc > /usr/src/lib/libc/secure/Makefile.inc /usr/src/lib/libc/rpc/Makefile.inc > /usr/src/lib/lib > c/uuid/Makefile.inc /usr/src/lib/libc/xdr/Makefile.inc > /usr/src/lib/libc/yp/Makefile.inc /usr/src/lib/libc/capability/Makefile.inc > /usr/src/share/mk/bsd.lib.mk /usr/src/share/mk/bsd.init.mk > /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk > /usr/src/lib/libc/../Makefile.inc /usr/src/share/mk/bsd.libnames.mk > /usr/src/share/mk/src.libnames.mk /usr/src/share/mk/bsd.symver.mk > /usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.files.mk > /usr/src/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.confs.mk > /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.dep.mk > /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk > /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk' .PATH='. > /usr/src/lib/libc /usr/src/lib/libc/db/btree /usr/src/lib/libc/db/db > /usr/src/lib/libc/db/hash /usr/src/lib/libc/db/man /usr/src/lib/libc/db/mpool > /usr/src/lib/libc/db/recno /usr/src/lib/libc/compat-43 > /usr/src/lib/libc/gdtoa /usr/src/lib/libc/aarch64/gen /usr/src/lib/libc/gen > /usr/src/contrib/libc-pwcache /usr/src/contrib/libc-vis > /usr/src/lib/libc/gmon /usr/src/lib/libc/iconv /usr/src/lib/libc/inet > /usr/src/lib/libc/isc /usr/src/lib/libc/locale /usr/src/lib/libmd > /usr/src/lib/libc/nameser /usr/src/lib/libc/net /usr/src/lib/libc/nls > /usr/src/lib/libc/posix1e /usr/src/lib/libc/regex /usr/src/lib/libc/resolv > /usr/src/lib/libc/stdio /usr/src/lib/libc/stdlib > /usr/src/lib/libc/stdlib/jemalloc /usr/src/lib/libc/stdtime > /usr/src/contrib/tzcode/stdtime /usr/src/lib/libc/aarch64/string > /usr/src/lib/libc/string /usr/src/sys/libkern > /usr/src/contrib/cortex-strings/src/aarch64 /usr/src/lib/libc/aarch64/sys > /usr/src/lib/libc/sys /usr/src/lib/libc/secure /usr/src/lib/libc/rpc > /usr/src/li > b/libc/. /usr/src/lib/libc/uuid /usr/src/lib/libc/xdr /usr/src/lib/libc/yp > /usr/src/sys/kern /usr/src/lib/libc/capability' > 1 error > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > ___ > freebsd-...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org" IIRC, I had to disable LTO plugin in binutils and this need to disable it was there for a while. -- Alexander Kabaev pgpTGwi4uoHiE.pgp Description: Цифровая подпись OpenPGP
Re: amd64-binutils file name structure for utils vs. for powerpc64-binutils and aarch64-binutils
On Sat, 7 Apr 2018 18:43:17 -0400 Alexander Kabaev <kab...@gmail.com> wrote: Come to think of it, I am not sure I understand the problem. amd64-binutils installs "proper" x86_64-freebsd-prefixed binaries. Did you expect amd64-freebsd-* ? -- Alexander Kabaev pgpByasv65uKB.pgp Description: Цифровая подпись OpenPGP
Re: amd64-binutils file name structure for utils vs. for powerpc64-binutils and aarch64-binutils
On Sat, 7 Apr 2018 15:30:08 -0700 Mark Millard via freebsd-toolchain <freebsd-toolchain@freebsd.org> wrote: > For: > > # pkg info "*binutils" > aarch64-binutils-2.30_2,1 > amd64-binutils-2.30_2,1 > binutils-2.30_2,1 > powerpc64-binutils-2.30_2,1 > > # svnlite info /usr/ports/ | grep "Re[plv]" > Relative URL: ^/head > Repository Root: svn://svn.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 466704 > Last Changed Rev: 466704 > > in a amd64 context . . . > > amd64-binutils uses file naming that does not match the > patterns that aarch64-binutils and powerpc64-binutils > use. Using an example type of binutil for illustration > (in a 12.0 head context): > > # find /usr/local/bin /usr/local/*freebsd* -name "*addr2line*" -print > /usr/local/bin/powerpc64-unknown-freebsd12.0-addr2line > /usr/local/bin/x86_64-freebsd-addr2line > /usr/local/bin/addr2line > /usr/local/bin/aarch64-unknown-freebsd12.0-addr2line > > The differences involve the lack of: > > -unknown > 12.0 > > (Of course, plain binutils does not have such conventions.) > > Is this expected/intended? > > > For reference: > > # uname -apKU > FreeBSD FBSDFSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r332181M amd64 > amd64 1200061 1200061 No, this is not indented, but that is how GCC/binutils configure works. When building 'native' config, it does not install full triple-prefixed binaries. I had to manually work around that in powerpc64-gcc, looks like bintuils need the same treatment. -- Alexander Kabaev pgpMGummgJRFb.pgp Description: Цифровая подпись OpenPGP
Re: DragonFly added DT_GNU_HASH support to rtld
On Sun, 15 Apr 2012 17:43:22 +0300 Konstantin Belousov kostik...@gmail.com wrote: On Sun, Mar 11, 2012 at 10:59:00AM +0100, John Marino wrote: Hi Konstantin, It seems that no BSD supported DT_GNU_HASH despite this option being available on the base binutils (FreeBSD's 2.17.50 binutils supports it). This gnu extension is a big performance improvement over the specified SysV hash. The guy porting libreoffice to pkgsrc was finding -Wl,--hash-style=gnu to be the default build for that package. Indeed, using the standard hash results in very long startup times for something like Writer ( 8 seconds launched from a SSD) The result is that we brought in DT_GNU_HASH support to our real-time linker this weekend. We're still waiting to see how that improves libreoffice startup times. full commit: http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/7629c6317998f850ebca23c296822ba08af09e5b Modification to base compiler so all system libs and binaries can take advantage of it: http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/4687ecd9561d76f3d02ccb4f7adeecd5e3afdd8f For a while, binaries with dynamic symbol tables will have both types of hashes embedded. At some point in the future, we may switch over to only generating the GNU hash. This will break forward compatibility, but that happens rather frequently for other reasons anyway. I was a bit surprised FreeBSD didn't already have this functionality given the performance benefits, so hopefully these DragonFly commits will be interesting for you. I finally ported the Dragonfly commit to FreeBSD. There were several changes reverted in dragonfly version of the extracted matched_symbol() function which were restored. I also blindly converted all non-x86 arches. The matched_symbol() extraction is the good opportunity to apply the style(9) formatting to the large chunk of rtld code. Any testers, esp. on non-x86 architectures, are welcome. You would need to modify gcc spec file for you architecture, see corresponding x86 changes in contrib/gcc/config/i386. For me, patch successfully worked on the machine were I disabled sysv hashes at all. http://people.freebsd.org/~kib/misc/rtld-gnu_hash.1.patch Nothing jumps out, looks good. I am not a fan of mixing and matching different styles within the same file though. -- Alexander Kabaev signature.asc Description: PGP signature
