Re: argp, strndup and MinGW

[Daniel Martin]

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 <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?

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.