2.35.50 breaks ld -no-pie

Bug #1907789 reported by Christian Ehrhardt  on 2020-12-11
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu on IBM z Systems
Fix Released
binutils (Ubuntu)
qemu (Ubuntu)
Christian Ehrhardt 
s390-tools (Ubuntu)
Lukas Märdian

Bug Description

The qemu build reaches (and always did) a step where it tries to link some
img files. That is done via the command:
  $ ld -m elf_i386 -T /<<PKGBUILDDIR>>/pc-bios/optionrom//flat.lds -no-pie -s -o multiboot.img multiboot.o

Recently that still works in Debian [1] but no more in Ubuntu [2].

I think that the new binutils broke me.
In hirsute proposed those are at

The issue is easily isolated, and by copying the two files around I found the following:

Hirsute: - bad
Hirsute: - bad
Sid: 2.35.1-4 - good
Groovy: 2.35.1-1ubuntu1 - good
Focal: 2.34-6ubuntu1 - good

I'll attach these two files to the bug, just thro them into a directory and
run the command:
 $ ld -m elf_i386 -T ./flat.lds -no-pie -s -o linuxboot.img linuxboot.o

If that is an intentional change please guide how this is now supposed to work.

[1]: https://buildd.debian.org/status/fetch.php?pkg=qemu&arch=amd64&ver=1%3A5.2%2Bdfsg-2&stamp=1607598738&raw=1
[2]: https://launchpadlibrarian.net/510801929/buildlog_ubuntu-hirsute-amd64.qemu_1%3A5.2+dfsg-2ubuntu1~ppa2_BUILD

Related branches

works with the 2.35 branch, fails with the trunk:

$ ld.gold -pie
ld.gold: fatal error: no input files

$ ld.gold -no-pie
ld.gold: fatal error: no input files

$ ld.bfd -pie
ld.bfd: no input files

$ ld.bfd -no-pie
ld.bfd: Error: unable to disambiguate: -no-pie (did you mean --no-pie ?)

Matthias Klose (doko) on 2020-12-11
Changed in binutils (Ubuntu):
status: New → Fix Committed

It is caused by

commit 983d925db6a09ac90f6bed90be16eb69267b58e0
Author: Nick Clifton <email address hidden>
Date: Mon Oct 5 13:53:59 2020 +0100

    Update the BFD linker so that it deprecates grouped short options.

            * lexsup.c (parse_args): Generate an error or warning message when
            multiple short options are used together.

$ valgrind ./ld/ld-new -no-pie
==290969== Memcheck, a memory error detector
==290969== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==290969== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==290969== Command: ./ld/ld-new -no-pie
==290969== Conditional jump or move depends on uninitialised value(s)
==290969== at 0x409A96: parse_args (lexsup.c:749)
==290969== by 0x403DC6: main (ldmain.c:370)
./ld/ld-new: Error: unable to disambiguate: -no-pie (did you mean --no-pie ?)
==290969== HEAP SUMMARY:
==290969== in use at exit: 21,161 bytes in 10 blocks
==290969== total heap usage: 72 allocs, 62 frees, 43,232 bytes allocated
==290969== LEAK SUMMARY:
==290969== definitely lost: 0 bytes in 0 blocks
==290969== indirectly lost: 0 bytes in 0 blocks
==290969== possibly lost: 0 bytes in 0 blocks
==290969== still reachable: 21,161 bytes in 10 blocks
==290969== suppressed: 0 bytes in 0 blocks
==290969== Rerun with --leak-check=full to see details of leaked memory
==290969== Use --track-origins=yes to see where uninitialised values come from
==290969== For lists of detected and suppressed errors, rerun with: -s
==290969== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 0 from 0)

longind may not be set by getopt_long_only:

diff --git a/ld/lexsup.c b/ld/lexsup.c
index 0d10bc6fba..60e3f7d8b5 100644
--- a/ld/lexsup.c
+++ b/ld/lexsup.c
@@ -735,6 +735,7 @@ parse_args (unsigned argc, char **argv)
       /* getopt_long_only is like getopt_long, but '-' as well as '--'
    can indicate a long option. */
       opterr = 0;
+ longind = -1;
       last_optind = optind;
       optc = getopt_long_only (argc, argv, shortopts, longopts, &longind);
       if (optc == '?')

   LONGIND returns the index in LONGOPT of the long-named option found.
   It is only valid when a long-named option has been found by the most
   recent call.

Since the long option isn't found, LONGIND is undefined.

    Not to be facetious but did we ever really support -no-pie ?

    It does not appear to be documented, and it looks like it is treated internally as two options: -n and -o-pie.

    I have a patch that fixes the uninitialised memory problem detected by valgrind, but I am wondering whether it is better to add explicit support for -no-pie as an option to turn off -pie, or else keep the linker's error message, and maybe add a --no-pie option instead.

(In reply to Nick Clifton from comment #5)
> Not to be facetious but did we ever really support -no-pie ?

ld/testsuite/config/default.exp: set NOPIE_LDFLAGS "-no-pie"

that was reported for qemu:

./configure:# Check we support --no-pie first; we will need this for building ROMs.
./configure:if compile_prog "-Werror -fno-pie" "-no-pie"; then
./configure: LDFLAGS_NOPIE="-no-pie"

That's the *compiler* flag.

The master branch has been updated by Nick Clifton <email address hidden>:


commit 3991c7acb29aa8d7d52150695eb3efa03a08dd50
Author: Nick Clifton <email address hidden>
Date: Mon Dec 14 12:40:13 2020 +0000

    Fix a use of an uninitialised variable in the bfd linker.

            PR 27050
            * lexsup.c (parse_args): Ensure that the longind local variable is

Right - I have checked in the patch to fix the use of an unitialised variable.

Frankly I do not see any need to go any further. The linker does not have a -no-pie or a --no-pie command line option, so the error message is correct. Hence I am going to close this PR. If anyone has any strong objections they can reopen it and tell us what they think.


Changed in qemu (Ubuntu):
status: New → In Progress
assignee: nobody → Christian Ehrhardt  (paelzer)
importance: Undecided → High
Changed in binutils:
importance: Unknown → Medium
status: Unknown → Fix Released

FYI - fix submitted to qemu upstream and for now added to the qemu package. If upstream eventually prefers a different solution I can refresh it accordingly.
=> https://lists.gnu.org/archive/html/qemu-devel/2020-12/msg03684.html

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package binutils -

binutils ( hirsute; urgency=medium

  * Revert linker options parsing patch. LP: #1907789.

 -- Matthias Klose <email address hidden> Fri, 11 Dec 2020 11:29:47 +0100

Changed in binutils (Ubuntu):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :
Download full text (5.2 KiB)

This bug was fixed in the package qemu - 1:5.2+dfsg-2ubuntu1

qemu (1:5.2+dfsg-2ubuntu1) hirsute; urgency=medium

  * Merge with Debian unstable
    - includes fix for CVE-2020-17380
    - includes a fix for s390x PCI device reset (LP: #1907656)
    Remaining changes:
    - qemu-kvm to systemd unit
      - d/qemu-kvm-init: script for QEMU KVM preparation modules, ksm,
        hugepages and architecture specifics
      - d/qemu-system-common.qemu-kvm.service: systemd unit to call
      - d/qemu-system-common.install: install helper script
      - d/qemu-system-common.qemu-kvm.default: defaults for
      - d/rules: call dh_installinit and dh_installsystemd for qemu-kvm
    - Distribution specific machine type (LP: 1304107 1621042)
      - d/p/ubuntu/define-ubuntu-machine-types.patch: distro machine types
      - d/qemu-system-x86.NEWS Info on fixed machine type definitions
        for host-phys-bits=true (LP: 1776189)
      - add an info about -hpb machine type in debian/qemu-system-x86.NEWS
      - provide pseries-bionic-2.11-sxxm type as convenience with all
        meltdown/spectre workarounds enabled by default. (LP: 1761372).
      - ubuntu-q35 alias added to auto-select the most recent q35 ubuntu type
    - Enable nesting by default
      - d/p/ubuntu/enable-svm-by-default.patch: Enable nested svm by default
        in qemu64 on amd
        [ No more strictly needed, but required for backward compatibility ]
    - improved dependencies
      - Make qemu-system-common depend on qemu-block-extra
      - Make qemu-utils depend on qemu-block-extra
      - let qemu-utils recommend sharutils
    - tolerate ipxe size change on migrations to >=18.04 (LP: 1713490)
      - d/p/ubuntu/pre-bionic-256k-ipxe-efi-roms.patch: old machine types
        reference 256k path
      - d/control-in: depend on ipxe-qemu-256k-compat-efi-roms to be able to
        handle incoming migrations from former releases.
    - d/control-in: Disable capstone disassembler library support (universe)
    - d/qemu-system-x86.README.Debian: add info about updated nesting changes
    - d/control*, d/rules: disable xen by default, but provide universe
      package qemu-system-x86-xen as alternative
      [includes compat links changes of 5.0-5ubuntu4]
    - allow qemu to load old modules post upgrade (LP 1847361)
      - Drop d/qemu-block-extra.*.in, d/qemu-system-gui.*.in
      - d/rules: Drop generating package version into maintainer scripts
      - d/qemu-system-gui.prerm: add no-op prerm to overcome upgrade issues on
        the bad old prerm (LP 1906245 1905377)
  * Dropped Changes:
    - d/control, d/rules: build with gcc-9 on armhf as workaround until
      resolved in gcc-10 (LP: 1890435) [it is flaky still, but no more 100%
  * Added Changes:
    - Refreshed ubuntu machine types for hirsute@5.2
    - d/control: regenerated from d/control-in
    - d/p/ubuntu/lp-1907789-build-no-pie-is-no-functional-liker-flag.patch: fix
      ld usage of -no-pie (LP: #1907789)

qemu (1:5.2+dfsg-2) unstable; urgency=medium

  * move ui-opengl.so module from qemu-system-gui to qemu-system-common,
    as other ...


Changed in qemu (Ubuntu):
status: In Progress → Fix Released
Lukas Märdian (slyon) on 2021-01-07
Changed in s390-tools (Ubuntu):
assignee: nobody → Lukas Märdian (slyon)
status: New → In Progress
Lukas Märdian (slyon) wrote :

Proposed to drop the -no-pie flag at upstream s390-tools:

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package s390-tools - 2.15.1-0ubuntu6

s390-tools (2.15.1-0ubuntu6) hirsute; urgency=medium

  * debian/patches/s390-tools-lp1903984-hirsute.patch
    zcryptstats: Fix handling of partial results with many domains
    Thanks to Ingo Franzki (LP: #1903984)

 -- Frank Heimes <email address hidden> Tue, 19 Jan 2021 18:58:26 +0100

Changed in s390-tools (Ubuntu):
status: In Progress → Fix Released
Frank Heimes (fheimes) on 2021-01-28
Changed in ubuntu-z-systems:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.