On 2020-01-08, Martin Liška <mli...@suse.cz> wrote: > On 1/7/20 10:40 PM, Nick Bowler wrote: >> Regardless, $global_symbol_pipe is part of the documented libtool >> interface, which says you can do: >> >> eval "$NM progname | $global_symbol_pipe" >> >> This is obviously busted because the failed configure test leads to >> global_symbol_pipe='' which will obviously cause problems in this >> usage (I just tested one of my scripts and yup, it is busted). > > Yes, that's what I see for many package failures in openSUSE when I enable > -fno-common in optimization flags:
Interestingly, I noticed that the dlpreopen support bits seems to actually have code to handle the case where global_symbol_pipe is empty (and appears to make an effort to display a big fat warning message that the feature is unlikely to work, but allows the user to proceed anyway). However the -export-symbol-regex implementation uses global_symbol_pipe without any check so if global_symbol_pipe is empty then you get shell syntax errors when using this feature. In principle a big fat warning message would be OK for this feature as well, falling back to a no-op. The libtool documentation does not seem to mention an empty global_symbol_pipe as a possibility so I expect any users of this feature will not check this (this was the case with my script). The libtool configure test could be improved so that the test for global_symbol_pipe does not depend on global_symbol_to_cdecl working. Cheers, Nick