Re: argp, strndup and MinGW

[Daniel Martin]

Thanks for the reply,

Bruno Haible pointed out that my version of gnulib is old (I had thought
that gnulib-tool downloads from CVS the most recent sources), I think
I'm going to update gnulib and see what problems remain. After all
there's no point in fixing bugs that have already been fixed!

Sorry to have caused you so much trouble.



Daniel.

On Thu, 2006-10-19 at 14:44 -0700, Paul Eggert wrote:
> Daniel Martin <address@hidden> 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?
> 
> > 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?
> 
> >  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
> 
> 
> > 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.
> 
> > ../../../../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.