* Re: Reason to alway to build both static and shared libs
2022-08-04 5:13 Reason to alway to build both static and shared libs Jianshen Liu
@ 2022-08-22 11:23 ` Bruce Richardson
0 siblings, 0 replies; 2+ messages in thread
From: Bruce Richardson @ 2022-08-22 11:23 UTC (permalink / raw)
To: Jianshen Liu; +Cc: dev
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
^ permalink raw reply [flat|nested] 2+ messages in thread