On Thu, 2015-02-26 at 16:34 +0100, Bert Wesarg wrote:
> [ Sending to gcc@, in the hope to get a statement from the GCC
> developers finally. ]
>
> On Fri, Feb 20, 2015 at 2:35 PM, Bert Wesarg <bert.wesarg@xxxxxxxxxxxxxx> wrote:
> > On Fri, Feb 20, 2015 at 1:33 PM, Basile Starynkevitch
> > <basile@xxxxxxxxxxxxxxxxx> wrote:
> >> On Fri, Feb 20, 2015 at 09:25:30AM +0100, Bert Wesarg wrote:
> >>> [ Cc'ing all known plug-in authors. ]
> >>>
> >>> Guys, are you aware of this gmp.h dependency and by chance how are you
> >>> dealing with it?
> >>
> >>
> >> In pratice, I just install the gcc-4.9-plugin-dev package on my Debian
> >> (and also all the packages required to *build* gcc-4.9).
> >
> > Sure, that probably covers 90% of the usages, and I also checked that
> > the gcc-4.9-plugin-dev package also requires libgmp-dev. So for this
> > case everything seems good.
> >
> >>
> >> You probably need to have a gmp library very close to the one
> >> linked into your compiler. If that is an issue, you'll need to recompile
> >> GCC from its source code.
> >
> > And this is the real problem. Building GCC from source wither with
> > ---with-gmp or with an embeded gmp source renders the installed
> > plug-in headers useless. This may only be a fraction of all users who
> > will build a plug-in against GCC, but leaving them out should not be
> > an option.
> >
> > I could successfully build a plug-in by providing this fake gmp.h
> > header as an fallback:
> >
> > {{{
> > #ifndef FAKE_GMP_H
> > #define FAKE_GMP_H
> >
> > typedef void* mpz_t;
> >
> > #endif
> > }}}
> >
> > But honestly, this looks so bad, that I'm reluctant to accept this as
> > an work around, for people who build their GCC with --with-gmp or with
> > an embedded gmp.
> >
> > Bert
> >
> >>
> >> Good luck!
> >>
> >> (it is a bit sad that there are so few GCC plugin developers)
Some of the relevant content appears to have been trimmed during the
discussion; the top of the thread on gcc-help appears to be:
https://gcc.gnu.org/ml/gcc-help/2015-02/msg00035.html
In particular, if I reading things right, the issue you're running into
seems to be that if you use:
$ gcc -print-file-name=plugin/include
to capture the include path for plugins, it omits the path to the gmp.h
used by those headers.
FWIW in gcc-python-plugin I use a similar construction in my Makefile:
GCCPLUGINS_DIR:= $(shell $(CC) --print-file-name=plugin)
CPPFLAGS+= -I$(GCCPLUGINS_DIR)/include \
-I$(GCCPLUGINS_DIR)/include/c-family \
-I. $(PYTHON_INCLUDES)
and I believe it's working for me since I've always been either building
against the system gcc (which uses the system gmp), or against a minimal
rebuild of gcc that's built against the system gmp.
So I *think* the issue here is when attempting to build a plugin against
a gcc with a non-system gmp, and it appears that there's currently no
clean way to get the includes needed.
It may be best if you file a bug about this, with a minimal recipe for
reproducing it:
https://gcc.gnu.org/bugs/
FWIW, I'm hoping to build a more robust plugin API for gcc in the gcc 6
timeframe (time permitting...)
Hope this is helpful
Dave
