This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: fixing libmudflap configuration
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: Per Bothner <per at bothner dot com>
- Cc: Gcc Patch List <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 3 Jun 2004 21:40:36 -0400
- Subject: Re: fixing libmudflap configuration
- References: <40BFC541.4080605@bothner.com>
Hi -
On Thu, Jun 03, 2004 at 05:41:37PM -0700, Per Bothner wrote:
> I too a look at fixing libmudflap configuration, so
> it can build (or fail gracefully) on MinGW.
Thanks!
> The first problem I encountered was in mf-runtime.c.
> The problem there is that mingw has signal.h, but it doesn't
> define SIGUSR1. The attached patch has a suggested fix.
Great, please commit at will.
> The next problem was the wrappers in mf-hooks2.c including
> lots of missing header files. The patch to configure.in
> and mf-hooks2.c is one solution, but perhaps not the right
> one.
It is a part of the solution.
> I'm guessing the intent that (say) WRAP_recv would be
> defined iff recv is defined, but I don't understand how
> that is supposed to work.
These WRAP_* macros are for libgcc-style repeated compilation
of a few sources to generate a number of objects. I have a
large pending patch that does away with that, in favour of
(optional) -f{function,data}-sections.
> [...]
> /home/bothner/GNU/MinGW/gcc/libmudflap/mf-runtime.c:68:
> /home/bothner/GNU/MinGW/gcc/libmudflap/mf-impl.h:43:2: #error "Cannot
> build libm
> udflapth without pthread.h."
>
> And indeed, mingw doesn't have pthread.h, but I don't know
> what the fallback is.
In this case, the configury is supposed to arrange things so that
libmudflapth (th == threaded) is not built at all.
- FChE