[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: checking command to parse /usr/bin/nm -B output from gcc object... f
Re: checking command to parse /usr/bin/nm -B output from gcc object... failed
Wed, 8 Jan 2020 10:35:39 -0500
On 2020-01-08, Martin Liška <address@hidden> 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.