Bruno Haible wrote:
> Replying to Jim I wrote:
>> > "_rpl_open", referenced from:
>> > _grepfile in grep.o
>> 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
Bruno Haible writes:
> Simon, is it ok to remove the GNULIB_GC_CAMELLIA macro? I see it nowhere
> used in gnulib. Is it used in one of your packages?
I don't recall -- but please remove it, and if I notice any problems
I'll follow with a proper solution.
/Simon
Hello Bruno,
* Bruno Haible wrote on Sun, Mar 28, 2010 at 01:39:24AM CET:
> +Comment:
> +This module should not be used as a dependency from a test module,
> +otherwise when this module occurs as a tests-related module, it will
> +have side effects on the compilation of the main modules in lib/.
> ... change the expansion of @GNULIB_OPEN@ in lib/fcntl.in.h
> so that it expands to
> defined IN_GREP_GNULIB_TESTS
> instead of to 1
Actually I made it expand to
IN_GREP_GNULIB_TESTS
not
defined IN_GREP_GNULIB_TESTS
because I wanted to use the same expansion also for the GNULIB_OPEN C
> Resolve conflict between the two kinds of module indicators.
> * m4/gnulib-common.m4 (gl_MODULE_INDICATOR_FOR_TESTS): Define
> GNULIB_TEST_XYZ instead of GNULIB_XYZ.
After this change, some GNULIB_XYZ macros are unused. I'm applying the
patch below.
Simon, is it ok to remove t
> After cleaning up the @GNULIB_XYZ@ variables for possible use in tests-related
> modules, now the same for the GNULIB_XYZ C macros.
Here's the change for the modules 'malloc', 'realloc', 'sigpipe'. These modules
cannot be used among tests-related modules, due to the way the GNULIB_MALLOC_GNU
mac
> Even worse, for some modules, the GNULIB_XYZ macro is used in both ways:
This is fixed by this patch, which consistently uses the macro GNULIB_TEST_XYZ
to test for the presence of module 'xyz' in gllib/ or gltests/.
2010-03-27 Bruno Haible
Resolve conflict between the two kinds of
Hi,
After cleaning up the @GNULIB_XYZ@ variables for possible use in tests-related
modules, now the same for the GNULIB_XYZ C macros.
Two third of the gl_MODULE_INDICATOR invocations produce a GNULIB_XYZ macro
that is used to test whether the 'xyz' module _can be used_.
The other third of the gl_
Hi,
Replying to Jim I wrote:
> > "_rpl_open", referenced from:
> > _grepfile in grep.o
> 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
Jim Meyering wrote:
> 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.
In general, you don't want this. Let's take this precise example: Your program
needs 'dup2'. We decided to make a test for dup2 which happens
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:
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
>
t: [PATCH] build: avoid link failure on systems using gnulib's fcntl but
not open
* bootstrap.conf (gnulib_modules): Using gnulib's fcntl module
and including , but not also using gnulib's "open" module
would result in link failure due to references to rpl_open
on systems re
13 matches
Mail list logo
