Gmp Windows Build

Join GitHub today

MPFR (libmpfr-4.dll) MPFR library built for Windows using msys2/mingw64. Prebuilt packages. The current prebuilt packages can be downloaded from dist/mpfr-3.1.5gmp-6.1.2. Note that libgcc is not shipped together with pacakges where libgmp-10.dll and libmpfr-4.dll have it as a runtime dependency. Get notifications on updates for this project. Get the SourceForge newsletter. Get newsletters and notices that include site news, special offers and exclusive discounts about IT products & services.

GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.

Install gmpSign up

Check it on VirusTotal: gimp-2.10.12-setup-3.exe. Older Downloads. Previous v2.10 installers for Windows can be found here: download.gimp.org. Previous v2.8 installers for Windows can be found here: download.gimp.org. GIMP User Manual. These links download language-specific Windows installers for GIMP's local help.

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Comments

commented Sep 18, 2015

A few days ago, in order to rebase a couple of my branches on an up-to-date master, I made a pull that forced me to rebuild my deps (maybe due to #12463?).

Since then, though, I have not been able to rebuild gmp. It fails during config with text like this near the end:

I also get this error on a fresh clone.

Some googling suggests something about having absolute paths in the configure line breaks things. If I go into the source directory and do a bare ./configure, it succeeds (and gives a size of mp_limb_t of 8).

Has anyone else seen this? I've looked a bit into how we might tweak the invocation of configure but the logic in deps/Makefile looks, um, complicated.

commented Sep 18, 2015

It looks like an out-of-tree build for gmp just won't work for windows/msys2 (at least without some sort of patch for gmp). The configure command that deps/Makefile wants to execute on my machine is:

Executing this in the deps/build/gmp-X.X.X directory, it fails. However, if I execute the same in the gmp source tree, it succeeds. A bare /c/tw/julia2/deps/srccache/gmp-6.0.0/configure also fails when run from deps/build/gmp-X.X.X, while it succeeds in the tree.

commented Sep 18, 2015

My current workaround is this:

  1. after I hit the failure, I copy the gmp source tree into deps/build/gmp-X.X.X;
  2. rerun the configure command within this directory, but referring to the local configure script.

I also get test failures in MPFR that kill the build. My workaround for it is analogous. These two tweaks were enough to complete a successful build.

changed the titlegmp bulid broken in windowsSep 18, 2015

commented Sep 18, 2015

Hi, I also tried to build both 32 and 64 bit julia on Windows 7 (64bit), but both trial has finished to fail with the same reason. I also be able to build only gmp-6.0.0 independently.

commented Sep 18, 2015

Now it also looks like virtualenv is broken, too. 😒

added buildwindows labels Sep 18, 2015
changed the titlegmp, mpfr bulid broken in windowsSep 18, 2015

commented Sep 18, 2015

Finally got it to build all the way through make binary-dist. To fix the virtualenv thing, I:

  1. copied the contents of depssrccachevirtualenv-XXX to depsbuildjulia-env;
  2. touched deps/build/julia-env/bin/activate into existence.

Afther that, resuming with make binary-dist completed.

commented Sep 18, 2015

for gmp, the following patch works for me:

There is no difference in the generated Makefiles, so the fact that this works is mystifying.

I'll make a PR, unless someone wants to dig further and figure out what is wrong with the GMP m4 macros. However, I'm not sure if realpath is supported on all of our target platforms (@tkelman?), and there may be some better way to accomplish the goal of calling configure as a relative path.

changed the titlegmp, mpfr, virtualenv bulid broken in windowsSep 18, 2015

Gmp Windows Builders

commented Sep 18, 2015

We have a relative_path.sh script in contrib. I think this was working in cygwin-cross last time I tried (I'll test again), so it might be an MSYS2-specific problem. Virtualenv is picky which python you're using, be sure you aren't using MSYS2's python there.

commented Sep 18, 2015

@tkelman:

closed this Sep 18, 2015
reopened this Sep 18, 2015
changed the titlegmp, mpfr, virtualenv build broken in windowsSep 18, 2015

commented Sep 18, 2015

This is definitely specific to msys2 which is why I didn't notice in testing.

edit: though the binary-dist installer target is broken for out-of-tree cygwin builds

commented Sep 19, 2015

And I was really enjoying using the Git for Windows SDK as my 1-click solution for all things POSIX. 😢

commented Sep 19, 2015

Should be fixable, just needs a few build patches probably. What was the virtualenv error, exactly?

commented Sep 19, 2015

Here is the error I get:

commented Sep 19, 2015

Ahk we need to use backslashes for mklink there. This is msys2 so cygpath_w is a no-op iirc

Virtualenv/python using bin on unix and Scripts for msvc-built python is endlessly annoying.

commented Sep 20, 2015

@tkelman, apparently so:

My msys2 (git sdk) has a working cygpath, though:

commented Sep 20, 2015

Right, but MSYS1 doesn't, and we're still using MSYS1 on appveyor. We aren't building gmp or mpfr from source on appveyor, but changing cygpath_w there would probably break other things. Apparently MSYS2 should now be available on the appveyor VM's appveyor/ci#352 but I haven't tried refactoring to use that.

Closed

commented Nov 14, 2015

did gmp 6.1.0 change anything here?

commented Nov 18, 2015

Unfortunately not (MSYS2).

commented Nov 18, 2015

Ah, thanks for testing. Still needs a PR to fix it then. Using relative_path.sh to call gmp's configure might be good enough here.

commented Nov 27, 2015

Can anyone test #14164 and confirm there whether that change fixes matters?

commented Nov 27, 2015

Sorry, not yet. Made a make cleanall but still errors

commented Nov 27, 2015

Can you confirm you applied the patch and post the output of make VERBOSE=1?

commented Nov 27, 2015

You may also need to do make -C deps distclean-gmp

commented Nov 28, 2015

Sorry, I had not notice that this is still a PR. Applied the patch and it's building fine now (though not finished yet)

commented Nov 28, 2015

should be fixed, leave a comment and we'll reopen if not

closed this Nov 28, 2015

commented Dec 16, 2015

well make works, but make install still fails as above

commented Dec 16, 2015

Agh, /Scripts needless platform differences strike again. The arguments to mklink need to use backslashes rather than forward slashes.

commented Dec 16, 2015

It might be beneficial to just use python since you're assuming it anyway. Pass parameters canonically -- using / -- and then let python figure out if you really meant or / since that's built in.

commented Dec 16, 2015

Considering how long this code is to create an NTFS junction in Python: http://stackoverflow.com/questions/1143260/create-ntfs-junction-point-in-python
I think it would be easier to use the just-built Julia and call the symlink function. Unfortunately I don't think we can rely on having a working Julia executable yet at this stage of the build.

commented Dec 16, 2015

naw, it's just a regex, I think. Is the assumption cygwin or msys? This doesn't actually build from a windows command prompt right?

commented Dec 16, 2015

MSYS. This line

-[ -e $@/Scripts ] && ! [ -e $@/bin ] && cmd //C mklink //J $@bin $@Scripts

is only necessary in MSYS (1 or 2) since MSYS2's Python doesn't work with virtualenv (they may have fixed this, dunno?). Cygwin's Python works fine with virtualenv and puts things under /bin where sphinx can find them. We still use MSYS1 on AppVeyor so we can't assume the existence of cygpath -w when BUILD_OS WINNT, but maybe just a sed call to turn forward slashes into double-backslashes would do the trick here.

commented Dec 16, 2015

Like this (for context)

commented Dec 16, 2015

I would use a non-slash character as the sed fence, maybe |, and if you put single quotes around the expression can you get away with one fewer level of escaping? But yeah, I'd merge a PR that did something like that.

reopened this Dec 16, 2015

commented Dec 16, 2015

Hmm one set of escaping I think is because of executing in a shell (backtick execution), and the other set is because it's also the escape character for Makefiles -- and of course it's escape for sed. Maybe something other than |, it will confuse bash make it think it's another pipe symbol maybe.

the above does in fact work as is at least in MSYS2.

commented Dec 16, 2015

It won't confuse bash if it's inside quotes - sed -e 's|/||g'

commented Dec 16, 2015

vertical bar though.. how about another meta character. -- maybe #?

Have to double-up when in a Makefile.

Can remove one set, yea that's better

closed this in #14421Dec 17, 2015

commented Dec 17, 2015

I just tried to build again for the first time in a while. I'm currently getting a build failure due to two test failures in mpfr. I recently did an msys2 update. My best guess is it's a gcc regression.

commented Dec 17, 2015

Interesting. Is msys2 using gcc 5.2 or 5.3? Cygwin cross is still on 4.9. Maybe check if opensuse cross is applying some patch for this?

commented Dec 17, 2015

msys2 is currently on gcc 5.2.

commented Dec 17, 2015

But I thought the problem using packaged gcc on MSYS2 is it assumes the wrong threading model (POSIX not WinThreads) thus you must avoid using it and rather obtain the toolchain as a separate download.

commented Dec 17, 2015

If you want the source build to be compatible with packages from WinRPM, then using the opensuse toolchain is recommended, yes. I think the msys2 toolchain might still work at least for a basic build of Julia without considering package compatibility, though maybe more likely to work correctly on 64 bit than 32 bit where the exception handling model is also incompatible. The opensuse toolchain is on gcc 5.3 as of a couple weeks ago.

commented Dec 17, 2015

Gmp Windows Build In Windows 10

Hmmm. WinRPM compatibility is pretty important to me. I guess I should reconsider my toolchain.

commented Dec 17, 2015

The msys2 toolchain is not frequently tested, at least not by me. If you can test and verify otherwise I'm certainly willing to reconsider my recommendations.

Gmp Windows Build Version

commented Dec 17, 2015

Windows Build 7601

I just updated to the toolchain available from the get_toolchain.sh script and attempted a clean rebuild. I'm still getting those two mpfr test failures.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

MPFR library built for Windows using msys2/mingw64

Prebuilt packages

The current prebuilt packages can be downloaded from dist/mpfr-3.1.5_gmp-6.1.2.

Note that libgcc is not shipped together with pacakges where libgmp-10.dll and libmpfr-4.dll have it as a runtime dependency. This is because I was so far unable to obtain sources from which were mingw32 and mingw64 toolchains built under msys2. For now you can perhaps use those available directly from the mingw64 project.

For x32 Windows there is libgcc_s_dw2-1.dllhere.
For x64 Windows there is libgcc_s_seh-1.dllhere.

Install Gmp

How to build libmpfr-4.dll

  1. Example build script

    If you already know what to do, here is an example build/build.sh script. You can adapt it if you like.

  2. Install MSYS2 and mingw-w64.

    Follow their instruction manual, once you have setup pacman install required toolchains and other packages:

  3. Download GMP and MPFR source code

    Extract the source code folders, for example to c:libs.
    For extracting .lz file you can use tar --lzip -xvf gmp-*.tar.lz.

  4. Open the correct shell for the compilation

    This is by default MSYS2 64bit/MinGW 32-bit or MSYS2 64bit/MinGW 64-bit in the Windows startup menu.
    Check your gcc version by gcc -v. Note the compiler and the configuration flags there.

  5. Compile gmp and mpfr

    The following example code uses /c/libs/x32 directory just as an example.

    You can read more on what those configure flags do by ./configure --help in respective folders.
    For now it is enough to know that:

    • --enable-shared produces a shared .dll file

    • --disable-static disables compilation of a static library
      This is especially important for gmp, which can not do both static and dynamic compilation at once.

    • --prefix=<path> is where the result is installed after the compilation
      This is set by default to --prefix=/mingw32 or --prefix=/mingw64 based on the shell running.

    • --with-gmp=<path> is how you can specify your custom path to gmp, if you do not use the default one
      I used this option because otherwise configure posted a warning about not matching version of gmp.h.

    Note if you have encountered error: gmp.h isn't a DLL: use --enable-static --disable-shared
    during mpfr compilation, as I have, it is because mingw64 is not picking up any installed gmp dll.

  6. Dynamic linking

  1. Static linking

License information

Gmp Windows Build In House

  • GNU Compiler Collection (GCC), which libgcc is a part of, is distributed under GNU GPL 3+
    with GCC Runtime Library Exception. The runtime library exception is described in this rationale.
    As a result libraries linked statically to libgcc do not have any license restrictions,
    provided they are elegible to the exception.

  • mingw-w64GCC for Windows 64 & 32 bits states that it license is disclosed along with its sources and is permissive.
    This information is well hidden on their webpage in the support section.
    This also applies to winpthread library or libwinpthread-1.dll (not to confuse with POSIX Threads for Windows or pthread-win32).
    In binary distributions of msys2/mingw64 targeting x86 and x64 you can find under mingw32 or mingw64 a file licenses/mingw-w64/COPYING that states:

    With exception of certain parts that are prominently marked as being
    in the Public Domain, BSD, or LGPL this Software is provided under the
    Zope Public License (ZPL) Version 2.1.

    Also of note should be COPYING.MinGW-w64.txt and COPYING.MinGW-w64-runtime.txt where the first also states:

    The idea is that if you create binary packages of your software with MinGW-w64, you can simply copyCOPYING.MinGW-w64-runtime.txt into your package to fulfill the license requirements of the MinGW runtime.

    A separate license notice for winpthread is located in licenses/winpthread/COPYING.
    It seems fairly permissive, though it requires you to copy the notice and mentions having a part of posix-win32:

    Parts of this library are derived by:
    Posix Threads library for Microsoft Windows

  • The GNU Multiple Precision Arithmetic Library (GMP) uses dual licensing under GNU LGPL v3 and GNU GPL v2.

  • The GNU MPFR Library is licensed under GNU LGLP v3.

    LGLPv3 and GPLv2 impose requirements on source code distribution alongside binary distributions. The safest option is to simply distribute the source code with the provided binary distribution, because any other option usually results in long-term obligations.

    Note that mingw64 distribution also contains licenses/gmp and licenses/mpfr, because mingw64 ships with some version of GMP and MPFR. This shows what license notices must be provided in such case.

    You can read it all for yourself (though check your sanity first).