On Wed, 10 Jun 2020 13:53:58 +0200, Stephen Kitt <sk...@debian.org> wrote:
> On Tue, 9 Jun 2020 21:08:25 +0100, Simon McVittie <s...@debian.org> wrote:
> > On Tue, 09 Jun 2020 at 15:21:37 -0400, Olek Wojnar wrote:
> > > On Tue, Jun 9, 2020 at 6:12 AM Adrian Bunk <[1]b...@debian.org>
> > > wrote:
> > > > I wonder if the real fix shouldn't be for cegui-mk2 to stop
> > > > exporting a
> > > pile
> > > > of Boost symbols...
> > >
> > >
> > > I would love that. Any advice on a reasonably easy/straightforward way
> > > of doing that?
> >
> > *If* your upstream is on board with this, my understanding is that
> > the main way to do this is to build with -fvisibility=hidden,
> > and decorate each intentionally-public class/function/thing
> > with a macro that (when building with gcc or clang) expands to
> > __attribute__((__visibility__("hidden"))).
> >
> > Some upstreams will be doing something similar already, because they are
> > portable to Windows and need to decorate public symbols with
> > __declspec(dllexport) on Windows.
>
> See
> https://salsa.debian.org/debian/fcml/-/blob/master/debian/patches/visibility.patch
> for a quick-and-dirty example of both of these approaches (and
> https://salsa.debian.org/debian/fcml/-/commit/22d753b1c820ea339b6b52cbc1cdf6e05229fbf9#34a4bacbb5ecf973fa5f481819228c77da389f43
> for the resulting symbols file simplification).I’ve looked into the cegui-mk2 situation a bit more. It turns out that the project itself does define its exported symbols, and that can be used to built a library with no extraneous symbols: * add -fvisibility=hidden to the CXXFLAGS (or use the CMake hidden symbol support, which I think is available); * patch the headers define the various export macros, e.g. CEGUIEXPORT in cegui/include/CEGUI/Base.h (taking care to match the EXPORTS handling, same as the Windows code). This greatly reduces the number of exported symbols: debian/libcegui-mk2-0.8.7.symbols | 7477 +++++++---------------------------------------------------------------------------------- 1 file changed, 577 insertions(+), 6900 deletions(-) However it also breaks dh_dwz. This still leaves all the bitness variation (armel/armhf/i386 etc. v. amd64/arm64 etc., which could be better handled with arch-bits), and the changes from GCC 9 to 10. Those are annoying enough that I suspect it’s simply not worth dealing with a symbols file, as others have said. However I do think that controlling the symbols’ visibility would be a good thing, but that should be dealt with upstream. Regards, Stephen
pgpYiz05ydFjM.pgp
Description: OpenPGP digital signature
