bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/31200] New: Surprising behavior of DISCARD section and explicitl


From: petedietl at gmail dot com
Subject: [Bug ld/31200] New: Surprising behavior of DISCARD section and explicitly mentioned archive file
Date: Sun, 31 Dec 2023 06:00:55 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=31200

            Bug ID: 31200
           Summary: Surprising behavior of DISCARD section and explicitly
                    mentioned archive file
           Product: binutils
           Version: 2.38
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: petedietl at gmail dot com
  Target Milestone: ---

Created attachment 15274
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15274&action=edit
minimal reproduction of problem

I am observing that the sections of an archive file explicitly mentioned in an
input section of a linker script within the /DISCARD/ output section does not
get discarded if the -T option on an ld invocation is given after mentioning a
.o file that has an undefined symbol which is found in a section of an object
file within said archive. It was not clear to me in the documentation what the
expected behavior is. Attached is a Makefile and sources reproduction on an
x86_64 Ubuntu machine.

When I run `make`, I get an error like so: undefined reference to
`libfoo_getmsg'/
When I run `make clean && make SCRIPT_LAST=1`, it works.

It seems that indeed the position of the linker script is a key factor.

Furthermore, if one changes the linker script from `libfoo.a (*)` to `foo.o
(*)`, the `make` command succeeds regardless of the position of the linker
script argument.

I suspect that all of this has some complex explanation involving wildcard
matches, but I couldn't figure it out.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]