From owner-freebsd-amd64@freebsd.org Sun Apr 22 02:00:52 2018 Return-Path: Delivered-To: freebsd-amd64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30757FB657B for ; Sun, 22 Apr 2018 02:00:52 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic307-12.consmr.mail.ne1.yahoo.com (sonic307-12.consmr.mail.ne1.yahoo.com [66.163.190.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B828C74ED3 for ; Sun, 22 Apr 2018 02:00:51 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: 3HDaIXQVM1nIH8ytBfWnxZ1qAFHfkB8uOr5oqC5mW_wMMLu1tRv3rVAj97gD5nf Cey_bq2COOL2K8Ph6kl6.3yLdccL4.onUtPPQjN79rDml0RetJPJnAZ.IuJ8f6FpuLNMlnXbM180 kGgHVM0LYNdkYZgj0p9qEQl8ZZjvVYFsJ3Qr1aGawlt3tiwvPUrLYzhuB6axlsoO4MQ2FskjUBv9 .7DviAcbZRVDj3kQd_5nnkRM074CjQik_o5dnk3vZQd0FDDcQ1QxHXDo2li5VMOo_7sBuBV6zgtE qw0ovgZSLVgV37_SWCcZRSucxDKAOeg7s3gdmQRkuYOyCj6VhthrdxDjRmpasjWPcaG1KmGc2CRh XKwQm25aSAaW9aev9s8o9o3_6WS58Ih_QN7lf8uAh112v3k9EKv9z3EmO4bbcwTNQpWz.rpyQSf6 WwFoYdqmgsrc77GDz98tFxIXnEL5g5hf_qJa4MHPVAaqWMKE.cePO8LjsyMqK1F_uEy41z40P_ap cQpep0YGpgrspAGhCp4OWHZ4K.zNmCe528sTpjRPRtn0JXgwUjptT12CsEiJTeaEG79UND2gLmTX q5yj2w7M- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ne1.yahoo.com with HTTP; Sun, 22 Apr 2018 02:00:45 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp409.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID bd7ba04b5069c7487a7c8a06959d2076; Sun, 22 Apr 2018 02:00:41 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Why https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc builds are failing . . . Message-Id: <570A6CA9-6DBD-4F5C-BA3E-8ABE953B8A79@yahoo.com> Date: Sat, 21 Apr 2018 19:00:40 -0700 To: freebsd-toolchain@freebsd.org, freebsd-amd64@freebsd.org X-Mailer: Apple Mail (2.3445.6.18) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2018 02:00:52 -0000 /usr/local/bin/x86_64-freebsd-ld: unrecognized option '--no-rosegment' is the message that reports what stops the build. I think this traces back to: /usr/src/share/mk/bsd.sys.mk:LDFLAGS+=3D ${LDFLAGS.${LINKER_TYPE}} being incorrect for an amd64-gcc / x86_64-freebsd-ld based build. The details for how I got to that follow. Looking around . . . # grep -r rosegment /usr/src/* | more /usr/src/contrib/llvm/tools/lld/ELF/Writer.cpp: // -no-rosegment = option is used. /usr/src/contrib/llvm/tools/lld/ELF/Options.td:def no_rosegment: = F<"no-rosegment">, /usr/src/contrib/llvm/tools/lld/ELF/ScriptParser.cpp: // -no-rosegment = is used to avoid placing read only non-executable sections in /usr/src/contrib/llvm/tools/lld/ELF/SyntheticSections.cpp: // for that = case, which happens only when -no-rosegment is given. /usr/src/contrib/llvm/tools/lld/ELF/Driver.cpp: Config->SingleRoRx =3D = Args.hasArg(OPT_no_rosegment); /usr/src/stand/i386/Makefile.inc:LDFLAGS.lld+=3D -Wl,--no-rosegment /usr/src/usr.bin/clang/lld/ld.lld.1:.It Fl -no-rosegment Note the line: /usr/src/stand/i386/Makefile.inc:LDFLAGS.lld+=3D = -Wl,--no-rosegment which seems to be the only place that the --no-rosegment could be from. The error report detail is: =3D=3D=3D> stand/i386/mbr (all) --- machine --- machine -> /workspace/src/sys/i386/include --- x86 --- x86 -> /workspace/src/sys/x86/include --- mbr.o --- as --defsym FLAGS=3D0x80 --32 -o mbr.o = /workspace/src/stand/i386/mbr/mbr.s --- mbr --- /usr/local/bin/x86_64-unknown-freebsd11.1-gcc -isystem = /workspace/obj/workspace/src/amd64.amd64/tmp/usr/include = -L/workspace/obj/workspace/src/amd64.amd64/tmp/usr/lib = -B/workspace/obj/workspace/src/amd64.amd64/tmp/usr/lib = --sysroot=3D/workspace/obj/workspace/src/amd64.amd64/tmp = -B/workspace/obj/workspace/src/amd64.amd64/tmp/usr/bin -O2 -pipe = -I/workspace/src/stand/i386/btx/lib -nostdinc = -I/workspace/obj/workspace/src/amd64.amd64/stand/libsa32 = -I/workspace/src/stand/libsa -D_STANDALONE -I/workspace/src/sys = -Ddouble=3Djagged-little-pill -Dfloat=3Dfloaty-mcfloatface = -DLOADER_DISK_SUPPORT -m32 -mcpu=3Di386 -ffreestanding -mno-mmx -mno-sse = -msoft-float -march=3Di386 -I. -std=3Dgnu99 -Wsystem-headers -Werror = -Wno-pointer-sign -Wno-error=3Daddress -Wno-error=3Darray-bounds = -Wno-error=3Dattributes -Wno-error=3Dbool-compare -Wno-error=3Dcast-align = -Wno-error=3Dclobbered -Wno-error=3Denum-compare -Wno-error=3Dextra = -Wno-error=3Dinline -Wno-error=3Dlogical-not-parentheses = -Wno-error=3Dstrict-aliasing -Wno-error=3Duninitialized = -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-function = -Wno-error=3Dunused-value -Wno-error=3Dmisleading-indentation = -Wno-error=3Dnonnull-compare -Wno-error=3Dshift-negative-value = -Wno-error=3Dtautological-compare -Wno-error=3Dunused-const-variable = -mpreferred-stack-boundary=3D2 -e start -Ttext 0x600 = -Wl,-N,-S,--oformat,binary -nostdlib -Wl,--no-rosegment -o mbr mbr.o =20 x86_64-unknown-freebsd11.1-gcc: warning: '-mcpu=3D' is deprecated; use = '-mtune=3D' or '-march=3D' instead /usr/local/bin/x86_64-freebsd-ld: unrecognized option '--no-rosegment' /usr/local/bin/x86_64-freebsd-ld: use the --help option for usage = information collect2: error: ld returned 1 exit status *** [mbr] Error code 1 It appears that, for a amd64-gcc build that is using = /usr/local/bin/x86_64-freebsd-ld via x86_64-unknown-freebsd11.1-gcc , for some reason LDFLAGS.lld content = is using used. This suggests that in: /usr/src/share/mk/bsd.sys.mk:LDFLAGS+=3D ${LDFLAGS.${LINKER_TYPE}} LINKER_TYPE is "lld". In turn that would seem to be from: /usr/src/share/mk/bsd.linker.mk:${X_}LINKER_TYPE=3D lld Or with more context and indented but inside a ".for ld X_ in LD $${_empty_var_} XLD X_": .if ${ld} =3D=3D "LD" || (${ld} =3D=3D "XLD" && ${XLD} !=3D ${LD}) .if !defined(${X_}LINKER_TYPE) || !defined(${X_}LINKER_VERSION) _ld_version!=3D (${${ld}} --version || echo none) | head -n 1 . . . .elif ${_ld_version:[1]} =3D=3D "LLD" ${X_}LINKER_TYPE=3D lld _v=3D ${_ld_version:[2]} .else . . . .endif .else . . . .endif # ${ld} =3D=3D "LD" || (${ld} =3D=3D "XLD" && ${XLD} !=3D ${LD}) So it seems that ${${ld}} picked out lld for assigning _ld_version . In turn, the following what apparently executed: .elif ${_ld_version:[1]} =3D=3D "LLD" ${X_}LINKER_TYPE=3D lld _v=3D ${_ld_version:[2]} But for (again): /usr/src/share/mk/bsd.sys.mk:LDFLAGS+=3D ${LDFLAGS.${LINKER_TYPE}} that implies that the case involved is: ld X_ in LD $${_empty_var_} It looks like the LDFLAGS+=3D should not be using that for this type of build. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)