On Sat, 2020-12-05 at 12:38 -0300, Andreas Hasenack wrote: Hi Andreas, > > On Sat, Dec 5, 2020 at 6:32 AM Ian Kent <raven@xxxxxxxxxx> wrote: > > > Removing the LDFLAGS option -Wl,-Bsymbolic-functions makes the > > problem go away. > > Related: > https://www.spinics.net/lists/autofs/msg01903.html Sorry about not getting back to investigating this back then. I don't know what was happening at the time that caused me to not get back to it. > > In Ubuntu, -Wl,-Bsymbolic-functions is a system-wide default and we > remove it from the flags when building autofs in d/rules: > > # Taken from #1636781 as it's the same problem here. Also see > # > https://lists.ubuntu.com/archives/ubuntu-devel/2018-June/040369.html > ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes) > export DEB_LDFLAGS_MAINT_STRIP = -Wl,-Bsymbolic-functions > endif Not sure what #1636781 is? But in answer to the question about fixing this upstream. Based on what I have found recently I don't think simply reading the config. again and again is the right thing to do. In a threaded application you should be free to assume program variables and data referred to by them are available in the way defined by usual programming methods (eg. a static array defined in a program source module should not simply go away because the program has forked to become a daemon). Regardless of whether using the symbolic-functions link option is a good idea the segmentation faults that result from it means I need to work around it. Making the autofs static library a shared library fixes this and seems fairly straight forward to do. As I said before, hopefully I haven't made any mistakes. Would it be useful to provide Ubuntu with patches prior to the impending autofs 5.1.7 release (after which these patches would be present on kernel.org)? If so I can certainly do that and if we do then from that point any further changes would be done as follow up patches, so they would be final upstream patches even though they haven't been pushed to the repository yet. Ian
