Problem building linbox on top of MPIR from 2.5.x

[Jean-Pierre Flori]

Dear all,

While trying to upgrade MPIR in Sage, we got problems building Linbox on top of MPIR > 2.5.x, including MPIR 2.6.0.
You can see the discussion at
http://trac.sagemath.org/sage_trac/ticket/13137

The problem seems to be with the C++ version of mpz_get_[s|u]x which now get defined in gmpxx.h depending on the previous inclusion of stdint.h, which Linbox seems to include, and which makes the intmax_t et al. types available if I understand correctly.
These C++ functions just call their C counterparts which are prototyped (and used to be in 2.4.x as well) in mpir.h, depending on the same condition.
But somehow gcc complains that mpz_get_[s|u]x do not exist...
So now I'm confused on what goes wrong here.

And if I prevent the C++ member functions to be defined in gmpxx.h, the problem disappears.
In particular, Linbox does not use them, which provides a dirty workaround for the time being.

Cheers,
JP

[Jean-Pierre Flori]

I think I solved the problem, in some file we were including  first gmp.h then stdint.h and finally gmpxx.h, whence the problems.

[Bill Hart]

Good to know. Thanks!

Bill.

--
You received this message because you are subscribed to the Google Groups "mpir-devel" group.
To view this discussion on the web visit https://groups.google.com/d/msg/mpir-devel/-/Zo1m1nK4LK0J.
To post to this group, send email to mpir-...@googlegroups.com.
To unsubscribe from this group, send email to mpir-devel+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.

[Marc]

 mpir.h could define a macro _MPIR_H_HAVE_STDINT that mpirxx.h would check. As an alternative, since mpir.h already defines __GMP_BITS_PER_UINTMAX, mpirxx.h could test that. But in any case the stdint detection magic should not be duplicated in several files.

[Jean-Pierre Flori]

I agree.
If I understand correctly you'd rather propose to only check for stdint.h at build time, define a macro in mpir.h and then use it?
Unless you really want to run with or without stdint.h on similar hardware (but I don't think you distribute binaries anyway?)
Maybe that's not exactly what you mean but I would find this easier to manage :)
And would prevent problems like the one above which are kind of misleading and can easily happen and be difficult to diagnosis if mpir.h and mpirxx.h are included through some long chains of headers inclusion.

[Bill Hart]

The check for stdint.h at build time is not available when using
mpirxx.h from another project. Autotools puts the flag in config.h,
which is not generally available to mpirxx.h.

Bill.

> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/mpir-devel/-/uQBcch1RTnEJ.

[Bill Hart]

On 25 November 2012 16:22, Jean-Pierre Flori <jpf...@gmail.com> wrote:
>

> If I understand correctly you'd rather propose to only check for stdint.h at
> build time, define a macro in mpir.h and then use it?
> Unless you really want to run with or without stdint.h on similar hardware
> (but I don't think you distribute binaries anyway?)

This doesn't work when installing mpir on some systems with multiple
compilers. Hence it cannot be done this way.

Bill.

[Jean-Pierre Flori]

Ok, anyway the fix in LinBox is easy to setup so it's no real issue now.

[Jean-Pierre Flori]

And I think I now understand what Marc suggested:
* in mpir.h if _STDINT_H or related is defined, then define MPIR_H_HAVE_STDINT and related functions
* in mpirxx.h (which includes mpir.h all the time) just check that variable rather than _STDINT_H and related.
In the case as above where someone includes in this order mpir.h, then stdint.h, then mpirxx.h, the problem would disappear (although the user won't be able to use the get_cx/ux functions, but that's better than failing, isnt it? and if he needs them, hell just have to change the order of includes).

[Bill Hart]

Sure. One thing we do need to do is document more clearly the intended
include order and some of these subtleties. We hit these ourselves
when preparing the release.

We thought it would make sense for the test files to be written like
user files without dependence on config.h. Unfortunately, our project
is infected with the autotools virus which assumes that downstream
projects will also be using autotools and hence have config.h included
I think. It was impossible to easily remove the dependence on config.h
from the tests. For years people have been assuming it is available.
It's included anyway from tests.h I think, which is required to make
many of the tests work.

But we are kind of stuck with the hackish mess we have forever I think.

Bill.

[Bill Hart]

Something like this might work. Unfortunately there are widespread
issues with standard C++ header files interacting poorly, and the
obvious thing simply didn't work when we were preparing the release. I
don't recall the specifics.

However, I've added this issue to the todo list for the next release,
(which is a long way off), so it will get revisited.