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.

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.

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.

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.

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

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.

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.

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.

@tkelman:

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

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

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

Here is the error I get:

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.

@tkelman, apparently so:

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

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.

did gmp 6.1.0 change anything here?

Unfortunately not (MSYS2).

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.

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

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

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

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

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

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

well make works, but make install still fails as above

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

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.

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.

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?

MSYS. This line

Like this (for context)

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.

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.

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

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

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.

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?

msys2 is currently on gcc 5.2.

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.

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.

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

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.

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.