build failing on MSYS2 build

[cmundi]

Well this is a downer. I just spun up a new build machine and started cruising through the build, probably not paying as much attention as I should. Here's an excerpt:

checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking build system type... Invalid configuration `x86_64-pc-msys': system `msys' not recognized
configure: error: /bin/sh ../autoconf/config.sub x86_64-pc-msys failed
Makefile:369: recipe for target 'llvm-3.3/build_Release/config.status' failed
make[2]: *** [llvm-3.3/build_Release/config.status] Error 1
Makefile:43: recipe for target 'julia-release' failed
make[1]: *** [julia-release] Error 2
Makefile:32: recipe for target 'release' failed
make: *** [release] Error 2

Digging into the /deps/llvm-* and doing a make there confirms that the problem is that the LLVM configure is not detecting the build system.

$uname -a
MSYS_NT-6.1 VM-Win7x64 2.0.0(0.272/5/3) 2014-03-19 13:02 x86_64 Msys

Up to date:

$ git remote -v
origin  https://github.com/JuliaLang/julia.git (fetch)
origin  https://github.com/JuliaLang/julia.git (push)

$ git show --oneline
898962c Merge pull request #6200 from JuliaLang/sjk/sprintf

Just to be safe I did a pacman -S autoconf -- same build failure after updating autoconf.

Note that I have not bisected and I am not implicating this particular commit of course. I'll look for recent changes to the makefiles when I get back Monday.

[cmundi]

The problems start much earlier than LLVM. Failue on openlibm:

In file included from src/math_private.h:21:0,
                 from src/common.c:1:
/c/julia/deps/openlibm/include/fpmath.h:107:16: error: duplicate member ‘manl’
   unsigned int manl :32;
                ^
In file included from src/common.c:1:0:
src/math_private.h:75:3: error: conflicting types for ‘ieee_double_shape_type’
 } ieee_double_shape_type;
   ^
src/math_private.h:57:3: note: previous declaration of ‘ieee_double_shape_type’ was here
 } ieee_double_shape_type;
   ^
Make.inc:45: recipe for target 'src/common.c.o' failed
make[3]: *** [src/common.c.o] Error 1
Makefile:638: recipe for target 'openlibm/libopenlibm.dll' failed
make[2]: *** [openlibm/libopenlibm.dll] Error 2
make[2]: *** Waiting for unfinished jobs....

Will add recent commits to IEEE 857 to the list of things to look at.for...

[tkelman]

The problem is MSYS2 reports a different uname depending on which batch file you use to start it. Using msys2_shell.bat, I get MSYS_NT-6.1. With mingw64_shell.bat, I get MINGW64_NT-6.1. Reporting a uname of MSYS is something that only MSYS2 does, MSYS1 always reported itself as MINGW32.

In the case of openlibm, Make.inc checks the result of uname for the string MINGW, not MSYS. So openlibm has no idea what operating system you're using. In the case of LLVM or any other autotools project, MSYS2 is much newer than the versions of autotools that were used to generate configure and associated scripts, so they have a similar problem of not recognizing MSYS as a possible value for uname. Nothing changed in Julia or any of its dependencies here, rather the moral of the story is to avoid using msys2_shell.bat to start MSYS.

Nevermind the above, the trouble isn't with uname it's with the output of gcc -dumpmachine from using the MSYS2 version of GCC instead of a MinGW GCC. But similar end result, having msys in the build triple causes all sorts of problems.

[cmundi]

Regarding openlibm and IEEE floating pointL it appears that both _BIG_ENDIAN and _LITTLE_ENDIAN are evaluating to true. This results in redefined symbols and build failure. (This might be a result of failure to detect the build platform, noted above.) As an example I was able to get openlibm to compile by making the following edits. Note that these edits should not be necessary because the root cause seems to be failure to detect the build platform.

$ git diff
diff --git a/include/fpmath.h b/include/fpmath.h
index 3b06b7e..f9a8d9a 100644
--- a/include/fpmath.h
+++ b/include/fpmath.h
@@ -103,7 +103,8 @@ union IEEEd2bits {
                unsigned int    manh    :20;
                unsigned int    exp     :11;
                unsigned int    sign    :1;
-#if _IEEE_WORD_ORDER == _BIG_ENDIAN
+//#if _IEEE_WORD_ORDER == _BIG_ENDIAN
+#if 0
                unsigned int    manl    :32;
 #endif
 #else /* _BIG_ENDIAN */
diff --git a/src/math_private.h b/src/math_private.h
index 43781b4..2ace681 100644
--- a/src/math_private.h
+++ b/src/math_private.h
@@ -40,7 +40,8 @@
  * ints.
  */

-#if _IEEE_WORD_ORDER == _BIG_ENDIAN
+// #if _IEEE_WORD_ORDER == _BIG_ENDIAN
+# if 0

 typedef union
 {

[cmundi]

@tkelman -- That's very interesting. I've been using the msys2_shell.bat to start MSYS2 all along. So something in my environment changed. I'm glad it wasn't julia, but now I'm wondering what it was. Thanks for the quick reply.

[cmundi]

I see what you mean about the two batch files returning different results for uname. The VM I'm on right now was built tonight following README.windows -- yes, the one I updated a few weeks ago after extensive tear-down-and-restart testing on another machine. That other machine is still around but I can't get to it until Monday. I'll see if it also gives different uname outputs; or if msys2_shell is linked to mingw64_shell; or how else it could have worked. At a minimum it looks like I'll need to update the MSYS2 build instructions. Thanks @tkelman

[cmundi]

@tkelman ... hold on... I just did a fresh clone of julia (just to be sure) and used the mingw64_shell.bat. I confirm that uname comes back as MIGW64_NT-6.1, but I'm getting the same build errors with openlibm as I did before (before patching the headers). Something is going on here, could still be me.

[tkelman]

Yeah you're right, sorry for the wrong guess. I think I also used the msys2_shell.bat most of the time. But Julia's top-level Make.inc looks for both MINGW and MSYS, and should pass that on to openlibm. It might be an MSYS2 update that caused breakage, as I just pulled latest Julia master and things appear to be going okay - but I haven't updated my MSYS2 for a while.

[cmundi]

@tkelman -- I have the same suspicion. Need sleep now before I do something silly. Thanks. We'll get to the root of this!

[tkelman]

Ah, I think I've got it this time. What does gcc -dumpmachine say? If it's x86_64-pc-msys, that means you installed the MSYS2 version of GCC which would link everything to msys-2.0.dll, probably not what you want. I bet if you pacman -R gcc you'll be fine.

[cmundi]

You're right. Wrong gcc. I need to scrub this VM. I don't know how I
messed that up, other than SourceForge makes it really easy to accidentally
pull the wrong package. I think I better update/clarify the README.windows
for julia after I sort this out. Thanks and sorry for the false alarm.
All my bad.

On Sat, Mar 22, 2014 at 12:40 AM, Tony Kelman notifications@github.comwrote:

Ah, I think I've got it this time. What does gcc -dumpmachine say? If
it's x86_64-pc-msys, that means you installed the MSYS2 version of GCC
which would link everything to msys-2.0.dll, probably not what you want.
I bet if you pacman -R gcc you'll be fine.

Reply to this email directly or view it on GitHubhttps://github.com//issues/6234#issuecomment-38345369
.