Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 21 Apr 2018 19:00:40 -0700
From:      Mark Millard <marklmi26-fbsd@yahoo.com>
To:        freebsd-toolchain@freebsd.org, freebsd-amd64@freebsd.org
Subject:   Why https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc builds are failing . . .
Message-ID:  <570A6CA9-6DBD-4F5C-BA3E-8ABE953B8A79@yahoo.com>

next in thread | raw e-mail | index | archive | help
/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)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?570A6CA9-6DBD-4F5C-BA3E-8ABE953B8A79>