gmp.h needs to detect bit width more dynamically to support universal builds on mac
dank at kegel.com
Tue Jan 7 01:38:33 UTC 2014
So, I've bumped up against this again.
I think that Torbjorn's position (that one should let the operating system's
multiarch machinery handle different .h files for different architectures)
is fine when it's available.
But that mechanism is not present on all operating systems, nor in some
simplified homebrew toolchains, so it's worth looking at how one might
handle the problem without it.
One approach would be to make a trivial wrapper .h file that selects between
the two installed .h files using the preprocessor
to select the right version. That's probably what I'll end up doing,
since it requires the least thought.
On Thu, Dec 5, 2013 at 2:43 PM, Niels Möller <nisse at lysator.liu.se> wrote:
> Torbjorn Granlund <tg at gmplib.org> writes:
>> This is a can of worms. I think a GMP-specific solution to this problem
>> would be a mistake. Instead, a GNU-wide solution is needed.
> For libraries, I understand this position.
> But I don't think it's the same for headers. Most libraries have system
> independent headers. And those which haven't, I think the common case of
> system dependencies are definitions of types of particular bit size,
> which is a problem of the past as <stdint.h> gets adopted.
> Here, GMP is an exception, and we could have a GMP specific solution.
> And then gmp.h depends not only on the system, but also on the
> --enable-nails configure flag, which makes it more hairy. Now, nails are
> not really working, but are there any system with multiple ABIs where
> using nails would make sense? If not, it makes the problem a bit easer
> to solve.
> Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
> Internet email is subject to wholesale government surveillance.
More information about the gmp-bugs