This is the mail archive of the
mailing list for the GDB project.
Re: MinGW compilation warnings in libiberty's waitpid.c
- From: DJ Delorie <dj at redhat dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: gcc-patches at gcc dot gnu dot org, gdb-patches at sourceware dot org
- Date: Mon, 22 May 2017 15:38:40 -0400
- Subject: Re: MinGW compilation warnings in libiberty's waitpid.c
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=dj at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 7FA994DB14
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7FA994DB14
Eli Zaretskii <email@example.com> writes:
> Hmm... no, this doesn't solve the problem. The expansion of AC_LIBOBJ
> for waitpid is gone from the configure script, but the value of
> LIBOBJS in libiberty/Makefile still includes waitpid.o. What else is
> related to this?
After re-reading the sources a bit, I come to the following
* $funcs is a list of functions libiberty should provide if the host
doesn't have them.
* We can override what the host *has* but not what it *shouldn't* have.
Since (or "if") nobody will (should) use waitpid() on mingw anyway, and
since libiberty really wants to include waitpid.o, how difficult would
it be to use some #ifdefs to have waitpid() just return an error on
mingw? That at least gets past the mingw build problem.
> One caveat: I needed to hack config/override.m4 to allow me to run
> autoconf 2.69 I have installed, because otherwise it insists on
> autoconf 2.64 which I don't have. I hope this isn't the reason for
> the incomplete solution.
I have many versions of autoconf installed, each in their own
directories, and add the right one to my $PATH on a per-project basis.
Autoconf works just fine that way, and there have been plenty of cases
of autoconf output changing in, er, "unexpected" ways across autoconf
releases. If you regen configure and an "svn diff" (or git diff) shows
unexpected changes, check your autoconf :-)
Same for automake and autogen.