Weird object file link issue

Weird object file link issue

[Tom Kacvinsky]

[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]

Hi,

Using binutils 2.39 and GCC 12.1, built from source on CentOS 7

This is a really weird one.  I have a simple "hello world" C program.
When I link this against a third party object file foo.o, symbols from
foo.o are in my hello world main program, even though the main
program does not have any symbol dependencies from foo.o.

Sample link driver:

gcc -fuse-ld=gold -o bar bar.c foo.o

I would have thought that foo.o would just have been discarded from the
final link, but using -Wl,--trace or -Wl,-Map=link shows it is indeed
used in the final link.  This is happening with both the gold and bfd
linkers. Any ideas on what I should do to diagnose this?  Completely new
to me - I have always seen unused object files and archives discarded
from the file link.

I'd like to file an issue with the third party company I am working with,
but
I want to go to them with concrete data as to why this is happening, in the
hopes they can fix it.

Yes, I know I can just drop the object file from the link line as it is not
really needed.  That poses a problem from how we build with cmake.
That and I am curious as to the black magic that is causing this.

Thanks,

Tom

Re: Weird object file link issue

[Tom Kacvinsky]

[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]

Answering my own question.  See below...

On Tue, Nov 22, 2022 at 3:16 PM Tom Kacvinsky <tkacvins@gmail.com> wrote:

> Hi,
>
> Using binutils 2.39 and GCC 12.1, built from source on CentOS 7
>
> This is a really weird one.  I have a simple "hello world" C program.
> When I link this against a third party object file foo.o, symbols from
> foo.o are in my hello world main program, even though the main
> program does not have any symbol dependencies from foo.o.
>
> Sample link driver:
>
> gcc -fuse-ld=gold -o bar bar.c foo.o
>
> I would have thought that foo.o would just have been discarded from the
> final link, but using -Wl,--trace or -Wl,-Map=link shows it is indeed
> used in the final link.  This is happening with both the gold and bfd
> linkers. Any ideas on what I should do to diagnose this?  Completely new
> to me - I have always seen unused object files and archives discarded
> from the file link.
>
>
So, on a lark, I added foo.o to an archive "ar cru libfoo.a foo.o" and
linked
against libfoo.a.  libfoo.a was discarded as no symbols from it were used.

I guess I was mistaken in thinking that the symbols from a lone object
file, if
not used, would lead to the object file being discarded from the final link.

Clarification on the matter would be appreciated.  A +1 would be a reference
to a linker option that would enable the behavior I'd like, if one exists.
I've
not found one yet.

I'd like to file an issue with the third party company I am working with,
> but
> I want to go to them with concrete data as to why this is happening, in the
> hopes they can fix it.
>
> Yes, I know I can just drop the object file from the link line as it is not
> really needed.  That poses a problem from how we build with cmake.
> That and I am curious as to the black magic that is causing this.
>

If there is no link option I can use, I'll just do the static archive trick
above
and be on my merry way.

Sorry for the noise.

Tom

Re: Weird object file link issue

[Nick Clifton]

Hi Tom,

> So, on a lark, I added foo.o to an archive "ar cru libfoo.a foo.o" and
> linked against libfoo.a.  libfoo.a was discarded as no symbols from it 
> were used.

Correct - that is the normal way make the inclusion of an object file
optional.


> I guess I was mistaken in thinking that the symbols from a lone object
> file, if not used, would lead to the object file being discarded from 
> the final link.

Not quite.  There is a magic linker option which can achieve this effect:

   --gc-sections

This will tell the linker to run its garbage collector, discarding any
input sections which it can prove are not needed in the output.  Since
none of the sections in foo.o are needed, it should be entirely discarded.
(Well maybe a few note or debug sections might make it through, but no
code from foo.o should be present).

Cheers
   Nick