Re: [PATCH] build: avoid link failure on systems using gnulib's fcntl but not open

[Jim Meyering]

Bruno Haible wrote:
> Jim Meyering wrote:
>> I noticed this build failure for grep:
>>
>>     http://hydra.nixos.org/build/329919
>>
>>       CCLD   grep
>>     Undefined symbols:
>>       "_rpl_open", referenced from:
>>           _grepfile in grep.o
>>     ld: symbol(s) not found
>>     collect2: ld returned 1 exit status
>>     make[2]: *** [grep] Error 1
>>
>> I fixed it with this change to grep, and do appreciate
>> the implied warning that grep needs the "open" module,
>> but this must be a bug in gnulib...
>> ...
>> * bootstrap.conf (gnulib_modules): Using gnulib's fcntl module
>> and including <fcntl.h>, but not also using gnulib's "open" module
>> would result in link failure due to references to rpl_open
>> on systems requiring the replacement (e.g., Cygwin and Darwin).
>
> I wouldn't say that it's a bug in gnulib. The situation in the 'grep'
> package is as follows:
>   - The main part, in lib/, has the module 'fcntl' and therefore
>     implicitly 'fcntl-h', but not the 'open' module.
>   - The tests part, in gnulib-tests/, has the module 'open', as a
>     dependency from 'dup2-tests'.
>   - The presence of the 'open' module is indicated through an
>     AC_SUBSTed variable GNULIB_OPEN. There is only one GNULIB_OPEN
>     for the entire package, and it is set to 1.
>   - Therefore the lib/fcntl.h replacement defines "#define open rpl_open".
>
> It's a limitation of gnulib that you cannot decide to not use a module in
> the main part but use it in the tests. If you really wanted that, you
> would need a setup with two different configure.ac files, one for the
> main part and one for the tests.

I see your point: in a way it's my own fault for making grep's
gnulib-tests/ share the same headers and library used for the
rest of the package.

Nonetheless, in that situation it would be nice to have a way
to ensure that the primary module list is a superset of
those used for the tests.  Offhand, I don't see how to obtain
the test-induced list of modules.

Of course, what I really would like is the difference of
the transitive closure of the test-induced module set and
the TC of the primary module list.