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.
>
> 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?
>
> Hope this is helpful
Thanks. I hope, this is helpful for you too.
Bert
> Dave
>
