[Buildroot] [PATCH] libaio: Fix library creation for ARC with -Os
Thomas Petazzoni
thomas.petazzoni at bootlin.com
Tue Sep 18 09:15:06 UTC 2018
Hello,
On Tue, 18 Sep 2018 08:03:19 +0000, Alexey Brodkin wrote:
> This is how libaio.so is linked now (before my patch) with
> omitted some non-important options:
> ----------------------->8-------------------
> arc-buildroot-linux-uclibc-gcc -shared -matomic -Os -nostdlib -nostartfiles -fPIC \
> -o libaio.so io_queue_init.os io_queue_release.os io_queue_wait.os io_queue_run.os \
> io_getevents.os io_submit.os io_cancel.os io_setup.os io_destroy.os raw_syscall.os compat-0_1.os
> ----------------------->8-------------------
>
> And that's what happens with my patch:
> ----------------------->8-------------------
> arc-buildroot-linux-uclibc-gcc -shared -matomic -Os -nostdlib -nostartfiles -fPIC \
> -o libaio.so io_queue_init.os io_queue_release.os io_queue_wait.os io_queue_run.os \
> io_getevents.os io_submit.os io_cancel.os io_setup.os io_destroy.os raw_syscall.os compat-0_1.os -lgcc
> ----------------------->8-------------------
>
> Note "-lgcc" in the latter case.
Thank you, I do understand that passing LDFLAGS=-lgcc will add -lgcc to
the link command line :-)
The question is: why does libaio needs to be told explicitly to link
against libgcc, and not any other package.
And I believe the reason is because -nostdlib -nostartfiles are used.
Why is libaio using those flags? Is there a good reason ?
> Now let's see what happens with millicode symbols in both cases.
> Pre-patch case:
> ----------------------->8-------------------
> # arc-linux-gnu-readelf -s libaio.so | grep __st_r13_to_r17
> 3: 00000000 0 NOTYPE GLOBAL DEFAULT UND __st_r13_to_r17
> 41: 00000000 0 NOTYPE GLOBAL DEFAULT UND __st_r13_to_r17
> ----------------------->8-------------------
>
> Note millicode's "__st_r13_to_r17" is GLOBAL UNDEFINED symbol.
> Thus during linkage of the final application that symbol will
> need to be resolved and LD finds it in libgcc.a and essentially
> refuses to proceed as there's no way for shared library to
> use a function that is implemented in a different static library.
>
> Post-patch case:
> ----------------------->8-------------------
> # arc-linux-gnu-readelf -s libaio.so | grep __st_r13_to_r17
> 38: 000006cc 18 FUNC LOCAL DEFAULT 9 __st_r13_to_r17
> ----------------------->8-------------------
>
> Note "__st_r13_to_r17" is locally defined so shared library doesn't
> need anything from libgcc.a.
Indeed.
> > Why is this problem happening only with libaio, and not with other
> > packages ?
>
> That's a good question :)
> I may assume other shared libs gets linked with libgcc.a, i.e. all
> symbols from libgcc including millicode get built into libXXX.so.
See above: -nostdlib -nostartfiles are used in libaio. That's the
difference. The question is why libaio is using those flags.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
More information about the buildroot
mailing list