Re: option -pthread in LDADD

Am 28.11.2021 um 11:09 schrieb nia:
> On Sun, Nov 28, 2021 at 01:30:14AM +0100, Roland Illig wrote:
>> Hi,
>>
>> On https://releng.netbsd.org/cgi-bin/builds.cgi, the lint builds
>> currently fail since lint cannot handle the option -pthreads. This
>> option has been added in sbin/cgdconfig/Makefile on 2021-11-22.
>>
>> Is it OK to add the option -pthreads to LDADD? If so, the 3 lint
>> commands in share/mk/bsd.*.mk probably need to be adjusted to filter out
>> -pthreads. Or maybe better, filter out anything but -llib and -Llibdir,
>> as this would allow me to occasionally add --coverage to LDADD for
>> testing purposes.
>>
>> If it's not OK to add -pthreads to LDADD, where should it go instead?
>>
>> Roland
>
> Pardon my ignorance, but why does lint need to concern itself with
> link-stage flags? lint by definition shouldn't be linking anything.

Lint operates in two phases. The first is lint1, which analyzes a single
translation unit and writes the exported and imported symbols to a .ln file.

At link time, lint2 takes the .ln files from all translation units and
checks whether the definitions are compatible. For libraries, it creates
.ln files for the complete library and stores them for later use by
programs that link to this library.

So for example, there is llib-curses.ln that contains all symbols from
libcurses.so. So when a program links with -lcurses, lint translates
this option into loading the definitions from llib-curses.ln, to
cross-check the prototypes of the functions. For this it uses LDADD.

Lint2 is not good at reporting errors though. The messages it spits out
look ugly, most are useless or even wrong and even if there are
messages, lint2 still exits successfully. At some point I may get to
clean up these messages, but not now.

I successfully used these messages once to find unnecessarily exported
symbols across the translation units of a program. That was nice and
straight-forward.

Roland