[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] build: avoid link failure on systems using gnulib's fcntl bu
Re: [PATCH] build: avoid link failure on systems using gnulib's fcntl but not open
Sun, 21 Mar 2010 20:44:17 +0100
Bruno Haible wrote:
> Jim Meyering wrote:
>> I noticed this build failure for grep:
>> CCLD grep
>> Undefined symbols:
>> "_rpl_open", referenced from:
>> _grepfile in grep.o
>> ld: symbol(s) not found
>> collect2: ld returned 1 exit status
>> make: *** [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.