On Sunday, November 25, 2012 5:02:59 PM UTC+1, Marc wrote: > > On Sunday, November 25, 2012 3:35:05 PM UTC+1, Jean-Pierre Flori wrote: >> >> >> On Sunday, November 25, 2012 2:07:24 AM UTC+1, Jean-Pierre Flori wrote: >>> >>> 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 >>> >> 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. >> > > 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. > 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.
-- 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. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
