Ok, after installing the latest version of gnulib one of the issues
remains:
On Thu, 2006-10-19 at 14:44 -0700, Paul Eggert wrote:
> Daniel Martin <[EMAIL PROTECTED]> writes:
>
> > ../../../../gnulib/src/argp-parse.c:872: error: conflicting types for
> > 'argp_parse'
> > ../../../../gnulib/src/argp.h:413: error: previous declaration of
> > 'argp_parse' was here
> > ../../../../gnulib/src/argp-parse.c:872: error: conflicting types for
> > 'argp_parse'
> > ../../../../gnulib/src/argp.h:413: error: previous declaration of
> > 'argp_parse' was here
> > make[4]: *** [argp-parse.lo] Error 1
> >
> > I can work around this though but editing argp.h:410-413 and removing
> > the names of the arguments.
>
> Why does removing argument names help?
I don't know. As I said I tend to avoid the Pre-Processor so I don't
understand what's going on.
> > But of course this isn't really the
> > _correct_ way to fix this problem.
>
> We need to know what the actual problem is. Is it that your compiler
> mishandles __restrict, or is it something else?
>
> Does it help to add __restrict in the header of the implementation of
> argp_parse?
No it doesn't help I get exactly the same error.
When I run it through i386-mingw32 the version in argp-parse.c has the
first argument named `argp' whilst the version in argp.h has it named
`__argp'. (I would assume the other arguments are the same but I haven't
checked.)
> > i386-mingw32-gcc -DHAVE_CONFIG_H -I. -I../../../../gnulib/src -I../..
> > -I/usr/local/i386-mingw32/include -c ../../../../gnulib/src/argp-help.c
> > -DDLL_EXPORT -DPIC -o .libs/argp-help.o
> > ../../../../gnulib/src/argp-help.c: In function `argp_doc':
> > ../../../../gnulib/src/argp-help.c:1498: warning: assignment makes pointer
> > from integer without a cast
>
> Does this patch fix that?
>
> --- argp-help.c.~1.25.~ 2006-09-12 02:06:40.000000000 -0700
> +++ argp-help.c 2006-10-19 14:33:51.000000000 -0700
> @@ -1495,7 +1495,7 @@ argp_doc (const struct argp *argp, const
> }
> }
> else
> - inp_text = post ? 0 : argp->doc;
> + inp_text = post ? NULL : argp->doc;
> trans_text = inp_text ? dgettext (argp->argp_domain, inp_text) : NULL;
> }
> else
This warning has disappeared in the latest version.
> > guis/.libs/libguis.a(libwxwidgetsgui_la-main.o): In function
> > `_Z7wx_mainP9arguments':
> > ../../../../../src/guis/wxwidgets/main.cpp:11: undefined reference to
> > `wx_main(int, char**)'
> > ../gnulib/src/.libs/libgnu.a(argp-help.o):argp-help.c:(.text+0x21cd):
> > undefined reference to `_strndup'
>
> > When I run strndup.c and argp-help.c through i386-mingw32-cpp they both
> > reference/implement strndup and not _strndup. So I don't understand what
> > is causing this.
>
> Most likely one of your standard include files (<string.h>, perhaps?)
> has something like "#define strndup _strndup". You need to find out
> which file it is. Look at the output of i386-mingw32-cpp and find all
> the include files that it mentions, and look for strndup in all those
> include files. We need to figure out why "#define strndup _strndup"
> is overriding the "# define strndup rpl_strndup" in strndup.h.
> strndup.h should win this battle, but for some reason it's losing in
> your environment.
This error has disappeared in the latest version.
> > ../../../../gnulib/src/printf-args.c: In function `printf_fetchargs':
> > ../../../../gnulib/src/printf-args.c:82: warning: `wint_t' is promoted to
> > `int' when passed through `...'
> > ../../../../gnulib/src/printf-args.c:82: warning: (so you should pass `int'
> > not `wint_t' to `va_arg')
> > ../../../../gnulib/src/printf-args.c:82: note: if this code is reached, the
> > program will abort
>
> You can safely ignore that diagnostic. Line 82 looks like this, right?
>
> ap->a.a_wide_char =
> (sizeof (wint_t) < sizeof (int)
> ? va_arg (args, int)
> : va_arg (args, wint_t));
>
> I assume that sizeof (wint_t) < sizeof (int) on your platform (please
> check this, though), so the diagnostic is about the va_arg (args,
> wint_t) subexpression that is never executed. Newer GCC versions get
> this right, and avoid generating the diagnostic in subexpressions that
> are not executed. Or maybe you just need to compile with -O.
This warning has disappeared in the latest version.
A new linker error has now appeared though:
../gnulib/src/.libs/libgnu.a(error.o):error.c:(.text+0xe1): undefined reference
to `_program_name'
../gnulib/src/.libs/libgnu.a(error.o):error.c:(.text+0x1a1): undefined
reference to `_program_name'
Here's what I've dug-up that may be useful to diagnose the problem:
$ i386-mingw32-cpp ../../../../gnulib/src/error.c | grep "program_name"
gnulib/src/error.c:22:21: config.h: No such file or directory
extern char *program_name;
fprintf ((&_iob[2]), "%s: ", program_name);
fprintf ((&_iob[2]), "%s:", program_name);
$ i386-mingw32-cpp -DHAVE_CONFIG_H -I. -I../../../../gnulib/src -I../..
-I/usr/local/i386-mingw32/include ../../../../gnulib/src/error.c | grep
"program_name"
extern char *program_name;
fprintf ((&_iob[2]), "%s: ", program_name);
fprintf ((&_iob[2]), "%s:", program_name);
As you can see I can't seem to get it to reference _program_name.
Note: When I build this is the bit relevant to error.c:
if /bin/sh ../../libtool --tag=CC --mode=compile i386-mingw32-gcc
-DHAVE_CONFIG_H -I. -I../../../../gnulib/src -I../..
-I/usr/local/i386-mingw32/include -MT error.lo -MD -MP -MF ".deps/error.Tpo" -c
-o error.lo ../../../../gnulib/src/error.c; \
then mv -f ".deps/error.Tpo" ".deps/error.Plo"; else rm -f ".deps/error.Tpo";
exit 1; fi
i386-mingw32-gcc -DHAVE_CONFIG_H -I. -I../../../../gnulib/src -I../..
-I/usr/local/i386-mingw32/include -MT error.lo -MD -MP -MF .deps/error.Tpo -c
../../../../gnulib/src/error.c -DDLL_EXPORT -DPIC -o .libs/error.o
i386-mingw32-gcc -DHAVE_CONFIG_H -I. -I../../../../gnulib/src -I../..
-I/usr/local/i386-mingw32/include -MT error.lo -MD -MP -MF .deps/error.Tpo -c
../../../../gnulib/src/error.c -o error.o >/dev/null 2>&1
I'm not sure if I missed a flag that I should have passed to cpp.
Thanks in advance for any help you can give me.
Daniel.
