[gmp] Build error - 'fat' does not build on Windows x64 #27957
Comments
fkonvick
added
the
category:port-bug
|
I spent some time reviewing various threads, notably
The key thing is that the current default build of gmp by vcpkg is only guaranteed to run on the machine it was built on, on others it might crash with 'illegal instruction'. This is certainly bad for making universal packages. The 'fat' build would be the solution, but it's not compiling with vcpkg. Some of the above links suggest it could be possible in general, the last one (by the GMP authors) is pessimistic. So I'm not sure. But I assume that other packages ship some generic version, either "unoptimized" (with no special CPU instructions) or a 'fat' version (which chooses the code dynamically based on the actual CPU). My ultimate goal is packaging MPFR; this library can be link either GMP or MPIR, but vcpkg only recognizes the GMP option. I wonder whether there is a way of configuring MPFR to use MPIR with vcpkg. Now, MPIR is more Windows-friendly, but it could still have issues generating a 'fat' build. In both cases, GMP or MPIR, it might be a solution to switch the build to the "generic" unoptimized code path, which is slower than "fat" but works on any CPU. |
|
I already started looking into this issue.
This version has two significant changes for this issue:
I would propose to start without using
|
|
@dg0yt thanks! I tried installing MSYS and used mingw-x64 to build GMP I wasn't aware that vcpkg builds GMP using the MSVC toolchain (it makes sense, though) - but I cannot tell what does it take to fix things. Based on this wbhart/mpir#236 I would assume that it's no easy thing. In all, I think that having the |
|
|
For the record - I dug deeper into the crash that motivated building So like GMP, also the MPFR package could use an option for a 'safe' build. My comment in the above link shows how I worked around this bug. I'm not sure how to add flags to vcpkg; all this is quite low-level this-or-that way stuff (do you prefer portability or speed...), and I'm not sure how all this fits in the vcpkg ecosystem. |
|
@dg0yt based on the discussions with the MPFR dev team, my conclusions/comments are this:
I'm not familiar enough with vcpkg so I'm not sure what's possible. Is there a way of providing such builds as separate features? Perhaps it is, since |
|
Can you re-confirm that the bug is in port gmp, not in mpfr? What I found is that our port does not create native-to-host-CPU builds, because running autoreconf replaces gmp's sophisticated cpu detection scripts (condig.guess, config.sub). Last not least, I'm not convinced that any choice apart from I can create a draft PR from my WIP but I'm a little bit short on time for this topic. That's why I want to know if there is something which needs to be fixed immediately in port |
|
The bug that I observed was in the MPFR as built by vcpkg, not in GMP. What I think that needs to be fixed in the gmp port is what you already suggested - mark I haven't checked but based on what you are saying regarding using special Thanks a lot for your support! |
|
For the record, I opened a separate issue for the mpfr port here: #28005 |
|
@sfhacker Sure! The system is a plain vanilla Windows Server 2008 R2 with SP1. Here's CoreInfo64 output: coreinfo64.txt. Notably, BMI1 & BMI2 are missing. I believe that this is because "Hypervisor is present", as according to the specs this CPU model does support BMI. I think the minimal repro could be as simple as calling I can provide instructions for building the binaries above. Gecode's sources are available from GitHub, and the first step is running the x64 VS command prompt and |
Sure, but distributing a pre-compiled library package requires that we choose a specific toolchain (unless we provide many variants). All preceding versions of Gecode distributed a similar .msi package suitable for use with MSVC (the key dependency is the CRT). The key reason I believe is to make this easily available for beginners. Of course, anyone may build from source whenever the pre-compiled binary does not work for any reason - license restrictions of the optional dependencies (GMP + MPFR, Qt), incompatible compiler, etc. Hopefully we could also provide a vcpkg port at some point. The error that you copied here indicates the lack of the MSVCRT, which I mentioned earlier. I could send you the required DLLs for copying into the executables directory (for the 'local deployment' of the CRT). Alternatively, download from Microsoft from here and install system-wide. Should you have issues compiling Gecode please let me know. Again, the failed app is the |
Yes, but note that this is only expected to crash when you build your binaries on a computer with BMI2 support and then run the resulting binary on another machine which does not support the BMI2. |
|
@fkonvick To make it clear, sfhacker is not talking about helping with vcpkg. |
|
@LilyWangLL I'm not sure it's clear what needs to be done, so I'll recap: we should mark |
Hi @dg0yt, did you have created a branch to fix this issue in your repo? Do I need to submit a PR to modify the |
|
@LilyWangLL TBH I still don't know if it works or not, due to the mpfr aspect in this discussion. I'm very limited in what I can do for (MSVC) windows triplets. |
Thanks for your reply. About
I will submit a PR to change |
|
@LilyWangLL #28005 is no longer an issue with the most recent MPFR version, so I think that there are no more questions regarding this. |
and others
This might be a bug in GMP itself, I cannot tell. The reason for building
gmp[fat]for me is that the plain build crashes with 'illegal instruction' on older CPUs without certain instruction sets.Package: gmp[core,fat]:x64-windows -> 6.2.1#14
Host Environment
vcpkg-scripts version: 34d2cf7 2022-11-21 (16 hours ago)
To Reproduce
vcpkg install gmp[fat]Failure logs
C:\BUILD\vcpkg\buildtrees\gmp\build-x64-windows-dbg-out.log
C:\BUILD\vcpkg\buildtrees\gmp\build-x64-windows-dbg-err.log
The text was updated successfully, but these errors were encountered: