This is the mail archive of the
mailing list for the binutils project.
Re: Static linking on 64-bit PowerPC ELFv2
- From: Alan Modra <amodra at gmail dot com>
- To: Sebastian Huber <sebastian dot huber at embedded-brains dot de>
- Cc: binutils at sourceware dot org
- Date: Fri, 11 Aug 2017 20:20:00 +0930
- Subject: Re: Static linking on 64-bit PowerPC ELFv2
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org>
On Fri, Aug 11, 2017 at 11:48:50AM +0200, Sebastian Huber wrote:
> I recently added 64-bit PowerPC for RTEMS using the ELFv2 ABI. On RTEMS, the
> applications are statically linked with the operating system. I am now a bit
> surprised be a linker behaviour. I have a big library containing a network
> stack with many features. On other targets the linker just picks individual
> objects from the library to resolve the dependencies. However, on the 64-bit
> PowerPC the linker seems to pull in the complete library somehow. I see in
> the linker map file lines like this:
> ./libbsd.a(utils.c.18.o) (print_string)
You're only showing part of the complete line (which is no doubt
split). What you show is the reference, the line above it would be
the included object.
> The applications has no direct or indirect references to print_string,
> however, the utils.c.18.o is still included in the link process. This in
> turn leads to unresolved references. Is this the expected behaviour on
> 64-bit PowerPC?
I don't know any reason why you should see differences between
PowerPC64 and other targets regarding the extraction of objects from
libraries. Are you compiling with different options, perhaps with
debugging turned on, for PowerPC64?
If you compare with another architecture, find the first difference
in included object and then compare the referencing object. Then
figure out why the referencing object is different.
Australia Development Lab, IBM