Reason to alway to build both static and shared libs

Reason to alway to build both static and shared libs

[Jianshen Liu]

[-- Attachment #1: Type: text/plain, Size: 481 bytes --]

Hi all,

Could I know the reason for always building both static and shared libs of
DPDK? I can find the patch
<https://www.mail-archive.com/dev@dpdk.org/msg83487.html> to enable this
behavior, but it seems that it didn't mention the reason behind it. Also,
if I propose a change to use "both" as the default for default_library in
meson's config file and still allow users to choose either static or shared
as they want, is there any reason against that change?

Thanks,
Jianshen

[-- Attachment #2: Type: text/html, Size: 592 bytes --]

Re: Reason to alway to build both static and shared libs

[Bruce Richardson]

On Wed, Aug 03, 2022 at 10:13:24PM -0700, Jianshen Liu wrote:
>    Hi all, Could I know the reason for always building both static and
>    shared libs of DPDK? I can find the [1]patch to enable this behavior,
>    but it seems that it didn't mention the reason behind it. Also, if I
>    propose a change to use "both" as the default for default_library in
>    meson's config file and still allow users to choose either static or
>    shared as they want, is there any reason against that change?  Thanks,
>    Jianshen
> 
When DPDK moved to use the meson build system, there was no "both" option
for static and shared libs, so that is the primary reason why it is not
used as the default. As for why even without that both libraries are always
built, the main reasons we do so are:
* traditionally DPDK has been built and linked into applications as a
  static library, and when moving build systems from make to meson we wanted
  to keep that as the default, since the transition was already confusing
  enough for users.
* with the older make build system when users submitted patches to DPDK
  there was many, many cases where the patches did not include changes to
  the version.map files, leading to shared lib build failures. By ensuring
  that shared libs are always built, this whole class of patch errors are
  caught before users push their patches to the mailing list.
Therefore by always building both shared and static we can keep consistency
and ensure higher quality patches to the mailing list.

I have looked a little into this in the past and from that investigation
some other considerations are:

* We can't actually use the built-in "both_libraries" option in DPDK
  directly since - due to ABI versioning - some files actually need to be
  compiled with different flags for static libraries (which don't have
  function versions) and shared libs (which do). This means that even if we
  do use "both_library" function, or "library" function with a default of
  "both" we will still need to maintain the code path fallback for building
  static and shared separately.
* The built-in option for building static and/or shared libraries only
  controls what libraries get built - it does not control what way things
  get linked. Right now, the default in DPDK is to build both libraries but
  link the applications like testpmd or examples, using the static libs. If
  we use the defaults in meson for "both" the shared library versions will
  be used for linking in preference to the static ones. This means that if
  we switch to using the default_library option for building only
  static/shared/both we also need a separate flag for indicating whether to
  link apps statically or dynamically in the "both" case.

I'm also a bit curious as to how much benefit you would expect to come from
this change. Since in 99% of cases the C files are only ever built once and
then put into the static and shared libs, I would not expect there to be a
large build-time improvement from disabling one of the library types.
However, having never tested it, I may be wrong on this and there may be a
boost from disabling the shared libs - though that in turn means fewer
build-time checks for the version.map files, for example. Let me know if
you do try it and see a big benefit.

Hope this input helps.
Regards,
/Bruce