Linker discards redundant .o inside .a

[Frederick Gotham]

I have a 3rd party library which is 50 - 100 source files.

I compile this library to produce a static shared library. All of the object files are gathered together into an archive (In Linux, this is a ".a" file).

I then write my own program which links with this static library. For example:

g++ main.cpp -o program -l:libmonkey.a

When the GNU linker links my own program with the archive file, it only links with the object files inside the archive which are needed.

If I had not created the archive file... If I had simply linked my own program with all of the 50-100 object files, then my program would have linked with every single object file -- possibly resulting in unreachable code in the output binary.

So... when the linker links with an archive file, it is smart enough to know which object files are needed, and which are not needed.

Is there any way to get a list of which object files are actually needed when a program links with an archive file? If I can get such a list, I can remove the redundant object files from the project, and then go on to tweak the object files that are actually needed.

I need to reduce a library of nearly a hundred source files, to about ten source files, and then go through each of these 10 source files and apply __attribute__ to every function.

I posted in this group yesterday, and one of the people who replied seemed to think that I was trying to hide that I'm linking with a library licensed under GPL (as it is against the GPL license to do what I am doing if my project isn't open-source). The legal advisors in my company have confirmed that I'm allowed to do what I'm doing with this particular 3rd party library.

[Robert Wessel]

The list of included objects (and what symbol prompted them to be
included) from an archive is in the link map (assuming you ask for
one). -M

[Scott Lurndal]

Frederick Gotham <cauldwel...@gmail.com> writes:
>I have a 3rd party library which is 50 - 100 source files.
>

>I compile this library to produce a static shared library. All of the objec=
>t files are gathered together into an archive (In Linux, this is a ".a" fil=
>e).

Careful with your terminology. An archive file is not a 'static shared library'.

Unix System V release 3 supported static shared libraries (which was a royal
pain because they all had to be statically linked at specific non-interfering
virtual addresses).

An archive (.a) is simply a 'folder' of object files.

The linker will access the archive when attempting to resolve external
symbols and will include any objects that contain such resolved external
symbols. All other objects in the archive will be ignored.

[Frederick Gotham]

robert...@yahoo.com said:

> The list of included objects (and what
> symbol prompted them to be included)
> from an archive is in the link map
> (assuming you ask for one).  -M

Thank you. Looks like I need to tell gcc to pass the "--print-map" flag to ld.

    gcc -Wl,--print-map main.c -o prog -l:libmonkey.a

[Frederick Gotham]

Scott said:
> An archive (.a) is simply a 'folder' of object files.

I thought everyone called.
these .a files "static libraries".

[Öö Tiib]

That is fancy term about some .o (object) files combined into
.a (archive) file.
.

[Jorgen Grahn]

I don't know about "fancy"; as far as I can tell "static library"
is the term people use for libraries which aren't shared libraries.

But they /are/ implemented as archive files on Unix: something similar
to a tar archive containing object files, and often a symbol table for
faster linking.

Anyway, the main point upthread was that they aren't called "static
shared libraries".

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[David Brown]

Yes - but not "static /shared/ libraries". "Shared libraries" generally
means libraries that are shared at run time - ".so" files on Linux,
".dll" files on Windows.

[Öö Tiib]

On Saturday, 30 November 2019 19:37:16 UTC+2, Jorgen Grahn wrote:
> On Sat, 2019-11-30, Öö Tiib wrote:
> > On Saturday, 30 November 2019 12:39:00 UTC+2, Frederick Gotham wrote:
> >> Scott said:
> >> > An archive (.a) is simply a 'folder' of object files.
> >>
> >> I thought everyone called.
> >> these .a files "static libraries".
> >
> > That is fancy term about some .o (object) files combined into
> > .a (archive) file.
>
> I don't know about "fancy"; as far as I can tell "static library"
> is the term people use for libraries which aren't shared libraries.

Correct.

> But they /are/ implemented as archive files on Unix: something similar
> to a tar archive containing object files, and often a symbol table for
> faster linking.

So these can be distributed as 1) folder of source code or 2) as
that archive file and folder of header files or even 3) just folder
of header files (then it is "header-only statically-linked library"
or just "header-only library").

> Anyway, the main point upthread was that they aren't called "static
> shared libraries".

I fully agree with that. I was attempting to add a pedantry point
to the mix in sense that calling that .a file alone (IOW wihout
headers) as "shared library" is becoming a bit extravagant. Sorry
for confusion if I caused any.

[Scott Lurndal]

That's not the term you used. I'm not sure why you felt it necessary
to snip that part of your response.

[Jorgen Grahn]

On Sat, 2019-11-30, Öö Tiib wrote:
> On Saturday, 30 November 2019 19:37:16 UTC+2, Jorgen Grahn wrote:

...

>> Anyway, the main point upthread was that they aren't called "static
>> shared libraries".
>
> I fully agree with that.

I know you do; I just felt that after your posting and my rather
lengthy posting, it was useful to return to SL's point, for other
readers.

[Jorgen Grahn]

On Sat, 2019-11-30, Scott Lurndal wrote:
> Frederick Gotham <cauldwel...@gmail.com> writes:
>>Scott said:
>>> An archive (.a) is simply a 'folder' of object files.
>>
>>I thought everyone called.
>> these .a files "static libraries".
>
> That's not the term you used. I'm not sure why you felt it necessary
> to snip that part of your response.

Thinking about it again, it's likely that "static shared" was just
a typo and he didn't realize he'd written that.