Re: [Buildroot] Removing BR2_SHARED_STATIC_LIBS [was: [PATCH 1/1] package/pkgconf: fix BR2_SHARED_STATIC_LIBS build]

["Yann E. MORIN" <yann.morin.1998@free.fr>]

Arnout, All,

On 2022-04-24 17:03 +0200, Arnout Vandecappelle spake thusly:
> On 23/04/2022 18:49, Fabrice Fontaine wrote:
> >Le sam. 23 avr. 2022 à 16:40, Arnout Vandecappelle <arnout@mind.be> a écrit :
> >>On 16/04/2022 23:13, Fabrice Fontaine wrote:
> >>>Add --static when calling pkg-config with BR2_SHARED_STATIC_LIBS to
> >>>avoid the following build failure if a package (e.g. dash or zabbix)
> >>>decide to use the static library of of its dependency instead of the
> >>>shared library (e.g. edit or openssl) resulting in the following build
> >>>failures:
> [snip]
> >>>-ifeq ($(BR2_STATIC_LIBS),y)
> >>>-HOST_PKGCONF_POST_INSTALL_HOOKS += HOST_PKGCONF_STATIC
> >>>-else
> >>>+ifeq ($(BR2_SHARED_LIBS),y)
> >>>   HOST_PKGCONF_POST_INSTALL_HOOKS += HOST_PKGCONF_SHARED
> >>>+else
> >>>+HOST_PKGCONF_POST_INSTALL_HOOKS += HOST_PKGCONF_STATIC
> >>   Err, so this would mean that we almost always link statically in the
> >>SHARED_STATIC case? I don't think that that's what we want, really...

Agreed: in the shared+static case, we want to link dynamically by
default.

> >>   If a package wants to link statically and is using pkg-config, why is not
> >>calling pkg-config with --static? Something seems to be really off here...
> >To my knowledge most packages are not adding --static when calling pkg-config.
> >--static is added by buildroot through HOST_PKGCONF_POST_INSTALL_HOOKS.
> >dash fails to build because -static is passed to gcc.
> >-static is passed to gcc because package/Makefile.in is setting
> >--enable-static (and --enable-shared):
[--SNIP--]
> >dash doesn't not handle --enable-shared.
> >It adds -static to gcc call depending on --{en,dis}able-static.
> >
> >So, the 'onlyy' other option would be to add
> >DASH_CONF_OPTS += --disable-static
> >to override what is set by package/Makefile.in
>  This is what was done for dropbear 4 years ago in commit c9922a4d2fc79e.

That was not exactly the same reason. dropbear misuses --enable-static.

--enable-{static,shared} is meant for building libraries, not for
linking an executable statically or not [0].

[0] https://www.gnu.org/software/libtool/manual/libtool.html#LT_005fINIT

Still, I think in that case, and unless the package really needs a
static link, we should fix it with ad-hoc warts, like the one for
dropbear. So, we should work around the issue in dash and zabbix*.

[*] now that we have fixed the a and z packages, what is there left to
fix? ;-)

> >I can send a v2 if you think that this solution is better.
> >However, it'll have to be applied to dash and zabbix but perhaps to a
> >large number of "application" packages ...
>  Very good point.

I am not sure there would be so many packages that misbehave in that
situation, in fact...

>  I think perhaps we should simply remove BR2_SHARED_STATIC completely. The
> idea is to build both static and shared libraries, but link with shared
> libraries by default. However, it turns out not to be working: cmake and
> meson packages don't support it, for all the non-C languages it's not
> relevant, and even for autotools packages it doesn't work consistently, as
> shown by these issues. So I think this option is just creating problems for
> us without added value.
> 
>  I've put a bunch of other Buildroot contributors in Cc to weigh in in this
> question. But for me, it is creating problems without adding much value.

I have always been a bit confused on how BR2_SHARED_STATIC_LIBS was
supposed to work, to be honest... Sure, it meant we wanted to _build_
both the static and shared libs. But how were we going to tell packages
whether they were supposed to link staticially or not?

Surely we do not want a per-package option... Then we're left with
deciding at the package's .mk level, by hard-coding some heuristic to
decide.

In upstream, we have no such case where we'd want a package to be
statically linked even in the presence of shared libraries (maybe the
the exception being busybox, for those who want to cheaply build an
initrd before pivoting in the final rootfs, but that can be done with
a config fragment or a custom config file in any case).

This leaves out-of-tree packages.

In that case, there can be tons of reasons to prefer a static link even
in the presence of shared libraries.

So, the real quesiton is whether we want to support that use-case or
not.

If we do, then we need to keep BR2_SHARED_STATIC_LIBS and fix those
packages that misbehave in its presence, like done for dropbear.

Regards,
Yann E. MORIN.


-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot