On 13/10/2022 14:05, Anthony Perard wrote: > When there isn't a version-script for a shared library (like for > unstable libs), we create one based on the current Xen version. But > that version-script became out-of-date as soon as Xen's version > changes and make as no way to regenerate the version-script on > rebuild. > > In order to allow regenerating the script, we'll have a different > filename. In order to check if the content is up-to-date, we'll always > generated it and compare. > > But we also need to know if there's already an existing version script > or if we need to generate one, for that we introduce $(version-script) > to be used to point to the path of the existing script. (Guessing if a > version script exist for a stable library with for example $(wildcard) > won't work as a file will exist when building the library without this > patch.) > > We don't need the version-script unless we are making the shared > library so it is removed from the "all" target. > > Signed-off-by: Anthony PERARD <anthony.per...@citrix.com> > --- > > Alternatively, we could remove the need for to generate a > version-script, but that would mean the exported symbols won't have a > version anymore (like before, a few versions of Xen ago). Or, we could > use --default-symver, but the symboled would be versionned with the > soname (e.g. "libxenctrl.so.4.16.0") instead of "VERS_4.16.0".
It turns out that the use of VERS_* everywhere is buggy. We should have had 'XEN$FOO' in the soname for libraries. But it's too late for the stable ones. As far as the unstable libraries go, it really doesn't matter. The only thing we care about (rightly or wrongly) is that you can't mistake the libraries from different versions of Xen. --default-symver sounds like it would be ideal, and avoid writing out temporary version scripts. ~Andrew
