Why https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc builds are failing . . .

[Mark Millard]

/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+=  ${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 = Args.hasArg(OPT_no_rosegment);
/usr/src/stand/i386/Makefile.inc:LDFLAGS.lld+=  -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+=  -Wl,--no-rosegment
which seems to be the only place that the --no-rosegment could be from.

The error report detail is:

===> stand/i386/mbr (all)
--- machine ---
machine -> /workspace/src/sys/i386/include
--- x86 ---
x86 -> /workspace/src/sys/x86/include
--- mbr.o ---
as  --defsym FLAGS=0x80 --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=/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=jagged-little-pill -Dfloat=floaty-mcfloatface -DLOADER_DISK_SUPPORT -m32 -mcpu=i386 -ffreestanding -mno-mmx -mno-sse -msoft-float -march=i386 -I. -std=gnu99 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-error=address -Wno-error=array-bounds -Wno-error=attributes -Wno-error=bool-compare -Wno-error=cast-align -Wno-error=clobbered -Wno-error=enum-compare -Wno-error=extra -Wno-error=inline -Wno-error=logical-not-parentheses -Wno-error=strict-aliasing -Wno-error=uninitialized -Wno-error=unused-but-set-variable -Wno-error=unused-function -Wno-error=unused-value -Wno-error=misleading-indentation -Wno-error=nonnull-compare -Wno-error=shift-negative-value -Wno-error=tautological-compare -Wno-error=unused-const-variable -mpreferred-stack-boundary=2  -e start -Ttext 0x600 -Wl,-N,-S,--oformat,binary -nostdlib -Wl,--no-rosegment -o mbr mbr.o  
x86_64-unknown-freebsd11.1-gcc: warning: '-mcpu=' is deprecated; use '-mtune=' or '-march=' 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+=  ${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=       lld

Or with more context and indented but inside a
".for ld X_ in LD $${_empty_var_} XLD X_":

.if ${ld} == "LD" || (${ld} == "XLD" && ${XLD} != ${LD})
  .if !defined(${X_}LINKER_TYPE) || !defined(${X_}LINKER_VERSION)
    _ld_version!=   (${${ld}} --version || echo none) | head -n 1
    . . .
    .elif ${_ld_version:[1]} == "LLD"
      ${X_}LINKER_TYPE=       lld
      _v=     ${_ld_version:[2]}
    .else
    . . .
  .endif
.else
  . . .
.endif  # ${ld} == "LD" || (${ld} == "XLD" && ${XLD} != ${LD})


So it seems that ${${ld}} picked out lld for assigning _ld_version .
In turn, the following what apparently executed:

    .elif ${_ld_version:[1]} == "LLD"
      ${X_}LINKER_TYPE=       lld
      _v=     ${_ld_version:[2]}

But for (again):

/usr/src/share/mk/bsd.sys.mk:LDFLAGS+=  ${LDFLAGS.${LINKER_TYPE}}

that implies that the case involved is:

ld X_ in LD $${_empty_var_}

It looks like the LDFLAGS+= should not be using that for this type
of build.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)