Issues with scripts/trylink

Denys Vlasenko vda.linux at googlemail.com
Tue Feb 23 11:44:14 UTC 2021


On Sat, Feb 13, 2021 at 3:23 PM Laurent Bercot <ska-dietlibc at skarnet.org> wrote:
>   Greetings,
>
>   busybox is linked via the scripts/trylink shell script. I have
> found a couple issues with trylink's management of additional libraries:
>
>
> 1. https://git.busybox.net/busybox/tree/scripts/trylink#n123
>
>   This "sanitization" phase changes the semantics of the LDLIBS list.
> When you give a list of additional libraries, the order is important:
> higher-level libraries must be given before lower-level ones, else
> linking might fail.
>   The call to "sort" may change the order, which can break dependencies.

trylink encloses libs in start-group/end-group pair, like so:

-Wl,--start-group -lcrypt -lm -lresolv -lrt -Wl,--end-group

"""
       --start-group archives --end-group
           The archives should be a list of archive files.
           They may be either explicit file names, or -l options.
           The specified archives are searched repeatedly until
           no new undefined references are created.
"""

>   The fix is to manually scan the list to remove duplicates without
> changing the order, which can be achieved with a few lines of shell,
> but I'm wondering if it's even necessary: giving the same -llib
> several times on the linking command line does not change the result
> (there are exceptions, such as when linking libgcc, but those are
> very special cases, and in those cases all the instances of -l are
> needed, so if anything it's an argument to keep the lib list as is),
> and extra spaces do not seem to hurt the rest of the script - except
> for starting and trailing ones, which are rather easy to remove.
>
>   I can provide a patch, but I don't want to bother with the whole
> deduplication thing if the community and the maintainer agree that it
> can be removed. Or better, see below.

>
>
> 2. https://git.busybox.net/busybox/tree/scripts/trylink#n145
>
>   trylink attempts to build with as few additional libraries as it
> can get away with. This is not correct. In some cases, the libc
> provides stubs, so linking works without additional libraries, but
> additional libraries are needed to get the full functionality, so
> attempting to build without the additional library, seeing that it
> works, and removing the -l argument yields a binary that does not
> have the functionality the user wanted.
>
>   An example is utmp functionality with the musl C library: musl
> provides utmpx.h stubs that do nothing, and the utmps library
> ( https://skarnet.org/software/utmps/ ) can be used to implement
> real utmp functionality on top of musl - but at the moment, busybox
> cannot be built with utmps, because trylink sees that it links
> without the "utmps skarnet" arguments (which it reorders as
> "-lskarnet -lutmps" due to the call to "sort" mentioned above, which
> would be incorrect even if it kept them), removes them, and makes it
> impossible to have the desired utmps functionality in the busybox
> binary.
>
>   My suggestion is to axe the whole part of the trylink script that
> attempts to outsmart the user, and to take everything provided as
> CFLAGS, LDFLAGS and LDLIBS quite literally. (LDLIBS should not even
> have to add the -l parts before the library names, but we can keep
> that for compatibility.) If the user wishes to have a convoluted
> list of LDLIBS, let them; if the busybox binary has too many
> dependencies as a result, it's on them.

The logic to remove libs which are not necessary simplifies cases
where e.g. -lrt or -lm is necessary on one libc, but not on other.
(Some newly created libc's include them into main library, and
libm is just an empty archive, kept to not break link invocations
with -lm. Google, as usual, decided to be a pain and Android has no
separate crypt library and they did NOT retain a stub empty archive!).

With current logic, you do not need to jump through the hoops
"if FEATURE_AWK_LIBM=y, include -lm, but if it's musl, do not include -lm".
Just LDLIBS += m, always.

Maybe we can have LDLIBS_MANDATORY for libs which should not be elided?


More information about the busybox mailing list