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.
Sign upCheck 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.
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 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.
Has anyone else seen this? I've looked a bit into how we might tweak the invocation of |
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 Executing this in the |
commented Sep 18, 2015
My current workaround is this:
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. |
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 |
commented Sep 18, 2015
Now it also looks like |
commented Sep 18, 2015
Finally got it to build all the way through
Afther that, resuming with |
commented Sep 18, 2015
for gmp, the following patch works for me: There is no difference in the generated 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 |
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: |
commented Sep 18, 2015
This is definitely specific to msys2 which is why I didn't notice in testing. edit: though the |
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 Virtualenv/python using |
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 |
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 |
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 |
commented Nov 27, 2015
Can you confirm you applied the patch and post the output of |
commented Nov 27, 2015
You may also need to do |
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 |
commented Dec 16, 2015
well make works, but make install still fails as above |
commented Dec 16, 2015
Agh, |
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 |
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
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 |
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 - |
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 |
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 |
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
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.
Install MSYS2 and mingw-w64.
Follow their instruction manual, once you have setup pacman install required toolchains and other packages:
Download GMP and MPFR source code
Extract the source code folders, for example to
c:libs
.
For extracting .lz file you can usetar --lzip -xvf gmp-*.tar.lz
.Open the correct shell for the compilation
This is by default
MSYS2 64bit/MinGW 32-bit
orMSYS2 64bit/MinGW 64-bit
in the Windows startup menu.
Check your gcc version bygcc -v
. Note the compiler and the configuration flags there.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.Dynamic linking
- 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 undermingw32
ormingw64
a filelicenses/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
andCOPYING.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 WindowsThe 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
andlicenses/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).