On Wed, Mar 26, 2025 at 01:02:32PM +0100, David Marchand wrote: > On Mon, Mar 17, 2025 at 4:43 PM David Marchand > <david.march...@redhat.com> wrote: > > > > So far, each DPDK library (or driver) exposing symbols in an ABI had to > > maintain a version.map and use some macros for symbol versioning, > > specially crafted with the GNU linker in mind. > > > > This series proposes to rework the whole principle, and instead rely on > > marking the symbol exports in the source code itself, then let it to the > > build framework to produce a version script adapted to the linker in use > > (think GNU linker vs MSVC linker). > > > > This greatly simplifies versioning symbols: a developer does not need to > > know anything about version.map, or that a versioned symbol must be > > renamed with _v26, annotated with __vsym, exported in a header etc... > > > > Checking symbol maps becomes unnecessary since generated by the build > > framework. > > > > Updating to a new ABI is just a matter of bumping the value in > > ABI_VERSION. > > > > > > Comments please. > > - I am considering making rte_function_versioning.h a non exported > header (precisely, moving it to buildtools/ and maybe renaming it). > > This header contains macros not prefixed with RTE_. > Using it requires some build trick (see use_function_versioning). > And I don't see symbol versioning as a MUST infrastructure that DPDK > needs to provide to datapath applications. > > Yet technically, this change would be an API breakage if some > applications indeed relied on it. >
Is it not needed for exporting if an exported library header had versioned symbols is in? /Bruce
