On Wed, 22 Jun 2022 02:04:04 +0200 Ichthyostega <p...@ichthyostega.de> wrote:
>Am 18.06.22 um 17:59 schrieb Will Godfrey: >> Also does anyone know how to deal with the LV2 exposed symbols issue? Only >> Arch >> Linux seem to test for this, but I'd like to keep them happy - they've been >> very helpful in the past, and are usually the first to pick up new releases. >> > >Hi Will, > >as has been pointed out already, the recommended way to deal with this issue >today seems to generally link with visibility=hidden and then only to declare >explicitly some externally exposed functions to be exported for dynamic >linking. > >Now I've looked into that a bit more and found out some further info, >however I'm not really sure what's the actual problem reported by Arch Linux. > > >(1) generally speaking, it is highly recommended to hide all spurious exports > also for the Main executable; this can reduce the size of the executable > and allows modern compilers to do much more aggressive global > optimisations > and inlinings (because they can be sure the optimised functions can not > be called from outside) > > See: https://gcc.gnu.org/wiki/Visibility > > >(2) However: we *did* already activate that link mode, albeit only for > the LV2 plugin object allone. And we set it by directly spelling out > the flag for GCC, instead of relying on CMake > (the latter would be more portable). > > For context, this change was introduced by Kristian in 2021-1 > Commit: 422411854164c40c2 > > >(3) As Kristian at that time also had found out, this works "out of the box", > since the LV2-headres already define the necessary visibility attribute > on the interface functions. These are: > > LV2_SYMBOL_EXPORT > const LV2_Descriptor * lv2_descriptor(uint32_t index); > > LV2_SYMBOL_EXPORT > const LV2UI_Descriptor* lv2ui_descriptor(uint32_t index); > > > Where LV2_SYMBOL_EXPORT is defined as > __attribute__((visibility("default"))) > > >(4) Now I have tried the following: instead of only activating this for the > Plugin object alone, we could rather activate it globally via a CMake > policy. I have attached a patch for that change. > > As usual, you can apply this patch with > > git am 3d9b60-Avoid-exporting-dynamic-symbols.patch > > > >(5) However, I am not sure this actually addresses the main problem indicated > by the Arch Linux folks. After rebuilding with this change, indeed the > exported symbols on the LV2-Plugin object are somewhat less (and > drastically > less on the main "yoshimi" executable). But there still remain some > further > dynamic symbols aside of the two interface functions > > These further symbols are almost all marked "weak" on my system, but these > are essentially the same kind of stuff, which showed up in the error > message > forwarded by the Arch people: These are some helper functions generated > from > function templates of the C++ standard library for those custom types, > which > we now pass to pthreads and use with the C++ futures. It might well be > that > these functions must be indeed exported (and thus were marked specifically > by the standard library) in order to allow for throwing some standard > exceptions from those facilities and for similar "framework" stuff. > But I am far from understanding this topic enough in-depth to come > to a conclusion. > >Thus, we could try the proposed change (because it is generally desirable >always >to link with visibility=hidden), and then ask the Arch Linux folks, if this >changed the FATAL alarm on LV2 lint. On the other hand, changing this kind of >intricate stuff could always break some backwards compatibility in corner cases >and on some platforms, and so there remaines some risk. > >-- Hermann Hi again, That seems to work fine here across middle aged machines along with Raspberry Pi 4B. In the descriptive link you showed, it said 'recent' but I couldn't find any date info, so have no idea when it was thought to be, erm, recent! We've not had any complaints about moving to C++14, so if that's about the same time we should be OK - anyway it's now in 'master'. I'll contact David again, and see if he'd like to try the latest build. Incidentally, once I got LV2lint working I didn't see any crashes either. However I still can't work out exactly what needs to be changed for the uri's to be valid. -- Will J Godfrey https://willgodfrey.bandcamp.com/ http://yoshimi.github.io Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song. _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
