On Tue, 2020-11-03 at 11:18 +0100, Thomas Monjalon wrote: > 02/11/2020 16:00, Bruce Richardson: > > On Mon, Nov 02, 2020 at 10:40:54AM +0000, Ali Alnubani wrote: > > > Hi Bruce, > > > > > > I was able to pin this down on drivers/net/mlx5/mlx5_rxtx.c. Removing > > > -fPIC from its ninja recipe in build.ninja resolves the issue (had to > > > prevent creating shared libs in this case). > > > What do you suggest I do? Can we have per-pmd customized compilation > > > flags? > > > > > > Regards, > > > Ali > > > > > There are multiple possible ways to achieve this, but below are some ideas: > > > > 1. Take the changes for supporting function versioning and duplicate them > > from lib/meson.build to drivers/meson.build. Since function versioning > > support already requires everything to be built twice, we could set it to > > not use -fpic for the static libs in that case. Then mark mlx5 as using > > function versioning. This is a bit hackish though, so > > > > 2. The "objs" parameter from each sub-directory is not widely used, so we > > could split this easily enough into objs-shared and objs-static, and allow > > the subdirectory build file, in this case mlx5/meson.ninja, to build any c > > files manually to pass them back. This is more flexible, and also means > > that you can limit the files which are to be built twice to only the single > > file, rather than marking the whole driver as needing rebuild. > > Can it be done only in the driver? > No general meson change for this option? > > > I'm sure there are other approaches too. However, I agree with Luca's > > comment that first approach should probably be to see if you can track down > > exactly why this one file is having problems. Could any of the slowdown be > > due to the fact that you use a common lib from your driver? Are there > > cross-driver calls in the fast-path that are suffering a penalty? > > Of course the performance will be analyzed in the long run. > However, such analyzis is more convenient if meson is flexible enough > to allow customization of the build. > And in general, I think it is good to have meson flexible > to allow any kind of driver build customization.
The problem is with the specific case, not with general customizations. IIRC all libraries must have fpic to build a relocatable executable - you cannot mix and match. Missing this feature means no address layout randomization, which is really bad especially for a network application. -- Kind regards, Luca Boccassi
