On 3/16/07, Bruno Haible <[EMAIL PROTECTED]> wrote:
The 'dummy' module is hardly used in practice, because it gets disabled
as soon as you have at least one gnulib module with an unconditional
lib_SOURCES augmentation.
IMHO it's the things that only happen sometimes that really bite you in the
Bruno Haible <[EMAIL PROTECTED]> writes:
> The 'dummy' module is hardly used in practice, because it gets disabled
> as soon as you have at least one gnulib module with an unconditional
> lib_SOURCES augmentation. But anyway, it doesn't cost much to choose a
> different symbol. I applied this:
II
James Youngman wrote:
> On 3/11/07, Bruno Haible <[EMAIL PROTECTED]> wrote:
> [...]
> > + #ifdef __sun
> > + /* This declaration ensures that the library will export at least 1
> > symbol. */
> > + int dummy;
> > + #else
> [...]
>
> Could we maybe pick an external symbol name that's less likely
On 3/11/07, Bruno Haible <[EMAIL PROTECTED]> wrote:
[...]
+ #ifdef __sun
+ /* This declaration ensures that the library will export at least 1 symbol.
*/
+ int dummy;
+ #else
[...]
Could we maybe pick an external symbol name that's less likely to
clash? I don't mind gnulib defining external
The 'dummy' module should avoid errors when libgnu.a is empty. But it does
not work with the Solaris /usr/ccs/bin/ranlib and Sun C 5.0. In such a case,
although libgnu.a contains a dummy.o, the compiler complains:
cc -O -DHAVE_CONFIG_H -I. -I.. -g -c dummy.c
rm -f libgnu.a
ar cru libgnu.a dum
