DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: dev@dpdk.org
Cc: Andrzej Ostruszka <amo@semihalf.com>,
	Neil Horman <nhorman@tuxdriver.com>,
	bluca@debian.org, thomas@monjalon.net,
	Bruce Richardson <bruce.richardson@intel.com>
Subject: [dpdk-dev] [PATCH v3 0/2] Improve function versioning meson support
Date: Mon,  7 Oct 2019 16:45:48 +0100	[thread overview]
Message-ID: <20191007154550.46655-1-bruce.richardson@intel.com> (raw)
In-Reply-To: <20190927194932.22197-1-bruce.richardson@intel.com>

Adding support for LTO has exposed some issues with how the functions
versioning was supported by meson, which was always set to build both
shared and static libraries.

For plain C code, so long as the -fPIC compiler flag was passed, the
output is identical whether or not the code is to be included in a
static library or a dynamic one. Unfortunately, when using function
versioning that no longer held as different macros were used for the
versioned functions depending on which type of build it was. This means
that any files that use versioning need to be built twice, with
different defines in each case.

While the trivial solution here is just to rebuild everything twice,
that involves a lot of unnecessary work when building DPDK. A better
option is to identify those files or components which need multiple
builds and rebuild only those. To do this, we add a new meson.build
setting for libraries "use_function_versioning" and when that is set, we
rebuild all source files twice, initially for static library and then
with -DRTE_BUILD_SHARED_LIB for the shared library.

If the flag is not set, then the static versioning setting only is used,
which could lead to the build succeeding but later causing problems. To
avoid that, we add a new define which must be set when the versioning
header is included. This addition while solving 1 problem raises 2
other, more minor problems:
* what to do with make builds? since make only builds one library type,
  we can just always define the new value.
* what about files that include rte_compat.h for the macro for
  "experimental"? To solve this, we can split compat.h in two, since the
  versioning macro should be internal only to DPDK (as no public header
  should expose anything but the latest APIs), while the experimental
  macros are primarily for public use.

V3: following feedback, moved the define for make from the common_base
    build config file to one of the global makefiles, as it's not user
    tunable.
V2: added in file that missed a "git add" when doing V1


Bruce Richardson (2):
  eal: split compat header file
  build: support building ABI versioned files twice

 config/rte_config.h                           |  3 -
 doc/api/doxy-api-index.md                     |  3 +-
 doc/guides/contributing/coding_style.rst      |  7 ++
 doc/guides/contributing/versioning.rst        |  4 +-
 lib/librte_distributor/meson.build            |  1 +
 lib/librte_distributor/rte_distributor.c      |  2 +-
 lib/librte_distributor/rte_distributor_v20.c  |  2 +-
 lib/librte_eal/common/Makefile                |  1 +
 lib/librte_eal/common/include/rte_compat.h    | 70 ----------------
 .../common/include/rte_function_versioning.h  | 83 +++++++++++++++++++
 lib/librte_lpm/meson.build                    |  1 +
 lib/librte_lpm/rte_lpm.c                      |  1 +
 lib/librte_lpm/rte_lpm.h                      |  1 -
 lib/librte_lpm/rte_lpm6.c                     |  1 +
 lib/librte_timer/meson.build                  |  1 +
 lib/librte_timer/rte_timer.c                  |  2 +-
 lib/meson.build                               | 16 +++-
 mk/target/generic/rte.vars.mk                 |  8 ++
 18 files changed, 124 insertions(+), 83 deletions(-)
 create mode 100644 lib/librte_eal/common/include/rte_function_versioning.h

-- 
2.21.0


  parent reply	other threads:[~2019-10-07 15:46 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-27 19:49 [dpdk-dev] [PATCH " Bruce Richardson
2019-09-27 19:49 ` [dpdk-dev] [PATCH 1/2] eal: split compat header file Bruce Richardson
2019-09-27 20:48   ` Bruce Richardson
2019-09-27 19:49 ` [dpdk-dev] [PATCH 2/2] build: support building ABI versioned files twice Bruce Richardson
2019-09-27 20:59 ` [dpdk-dev] [PATCH v2 0/2] Improve function versioning meson support Bruce Richardson
2019-09-27 20:59   ` [dpdk-dev] [PATCH v2 1/2] eal: split compat header file Bruce Richardson
2019-09-27 20:59   ` [dpdk-dev] [PATCH v2 2/2] build: support building ABI versioned files twice Bruce Richardson
2019-10-01 13:23     ` Andrzej Ostruszka
2019-10-01 16:53       ` Bruce Richardson
2019-10-07 15:57         ` Bruce Richardson
2019-10-07 15:45 ` Bruce Richardson [this message]
2019-10-07 15:45   ` [dpdk-dev] [PATCH v3 1/2] eal: split compat header file Bruce Richardson
2019-10-27  9:49     ` Thomas Monjalon
2019-10-07 15:45   ` [dpdk-dev] [PATCH v3 2/2] build: support building ABI versioned files twice Bruce Richardson
2019-10-23 10:19   ` [dpdk-dev] [PATCH v3 0/2] Improve function versioning meson support Andrzej Ostruszka
2019-10-27 10:26     ` Thomas Monjalon
2019-10-09 22:59 ` [dpdk-dev] [PATCH " Stephen Hemminger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191007154550.46655-1-bruce.richardson@intel.com \
    --to=bruce.richardson@intel.com \
    --cc=amo@semihalf.com \
    --cc=bluca@debian.org \
    --cc=dev@dpdk.org \
    --cc=nhorman@tuxdriver.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).