On Thu, 2015-02-26 at 19:51 +0100, Bert Wesarg wrote:
> David.
>
> On Thu, Feb 26, 2015 at 4:54 PM, David Malcolm <dmalcolm@xxxxxxxxxx> wrote:
> > 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.
>
> sorry, I should have been more informative when resending to gcc@.
>
> >
> > 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.
>
> Correct, and it gets worse when building with an in-tree GMP, than no
> gmp.h header is installed at all.
>
> I was playing by installing the GMP host module besides the 'plugin'
> diretory. But this resulted in ugly make arguments, as changing the
> $prefix for these modules is hard.
>
> >
> > It may be best if you file a bug about this, with a minimal recipe for
> > reproducing it:
> > https://gcc.gnu.org/bugs/
>
> Done.
Thanks. For reference (and the archives), the bug is:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65226
> > FWIW, I'm hoping to build a more robust plugin API for gcc in the gcc 6
> > timeframe (time permitting...)
>
> Very honorable. Honesty. If you need input what we need for our
> plugin, than don't hesitate to contact me. But I already have some
> (non-technical GCC) requirements for these headers:
>
> - please no autoconf header
> - projects using the plugin headers may also have an autoconf
> header, and thus gets duplicate definition warnings for the PACKAGE_*
> macros
>
> - do not rely on, that the plugin API header is the first header the
> compilation unit includes
> - GCC 5 defines __STDC_FORMAT_MACROS to get the PRI* macros from
> inttypes.h, but this only works, if the compilation unit does not
> include inttypes.h itself before the plugin header. this may actually
> be a regression, isn't it?
The approach I'm thinking of is to have an entirely new set of header
files, without any public references to the existing GCC implementation
headers. (it would use the "hourglass" API design pattern: C++ bindings
on top of a C API, talking to a C++ implementation [1]).
Although all of these wrapper layers imply a performance hit for plugins
using it, it has several big benefits: we can (in theory) have a stable
plugin API, and maybe even a stable ABI e.g. build a plugin once, and
have it work against multiple gcc versions (and possibly even have a
shim implementation for working with older gcc releases). It may be
possible to also support using the API to use libgccjit also (e.g. by
using the C++ "pimpl" implementation approach).
I've been toying around with this, using the gcc-python-plugin as a
testbed/proof-of-concept, but I'm not yet in a position to be able to
post code.
Dave
[1]
http://www.slideshare.net/StefanusDuToit/cpp-con-2014-hourglass-interfaces-for-c-apis
