Re: checking command to parse /usr/bin/nm -B output from gcc object... failed

[Nick Bowler]

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.

Cheers,
  Nick