From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2DE6843891; Thu, 11 Jan 2024 10:38:12 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A31064025E; Thu, 11 Jan 2024 10:38:11 +0100 (CET) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id A96AC40042 for ; Thu, 11 Jan 2024 10:38:09 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id 1CD1420B43; Thu, 11 Jan 2024 10:38:09 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH] build: fix linker warnings about undefined symbols X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 11 Jan 2024 10:38:05 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9F125@smartserver.smartshare.dk> In-Reply-To: <20240110165814.GA25069@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] build: fix linker warnings about undefined symbols Thread-Index: AdpD5jci+QC05zEgQZq472v44cJeOwAilZ3Q References: <20240110150103.529080-1-bruce.richardson@intel.com> <20240110165814.GA25069@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Tyler Retzlaff" , "Bruce Richardson" Cc: X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > Sent: Wednesday, 10 January 2024 17.58 >=20 > On Wed, Jan 10, 2024 at 03:01:03PM +0000, Bruce Richardson wrote: > > The default behaviour of "ld.lld" has changed, so it now prints out > > warnings about entries in the version.map file which don't exist in > > the current build. Since we use our version.map file simply to = filter > > out the functions we don't want made public, we include in it all > > functions across all OS's and builds that we want public if present. > > This causes these ld warnings to be emitted, e.g. on BSD, which is > > missing functionality found on Linux. For example: > > > > * hpet functions in EAL > > * regexdev enqueue and dequeue burst > > * eventdev event_timer functions > > > > Easiest solution, without major rework of how we use our version.map > > files, and without dynamically generating them per-build, is to pass > > the --undefined-version flag to the linker, to restore the old > > behaviour. > > > > Signed-off-by: Bruce Richardson > > --- >=20 > Acked-by: Tyler Retzlaff >=20 > i don't know if has ever been discussed but a way to achieve a similar > outcome would be to introduce a visibility macro allowing the data and > function symbols to be explicitly made visible while making the build > default hidden. >=20 > https://gcc.gnu.org/wiki/Visibility This looks interesting! Declaring a function "public" directly in its header seems much simpler = to manage than having to add it to the version.map file too. I wonder if function versioning is still supported if using this instead = of version.map files? Of if there are other relevant reasons for continuing to use the = version.map files instead of this? >=20 > on windows symbols are hidden by default (opposite of gnu toolchain) > and > allowing the symbols that are intended to be public be annotated in > code > with a macro instead of a separate map/def file would arguably appear > more consistent. additionally, the current process of converting a = map > file to a def file for windows has limitations with respect to things > like marking the type of symbol being exported. >=20 > ty