I traced through the precise calls to libflint and libgmp that make it segfault and wrote a few test programs from the msys2 command line, taking Julia right out of the loop.
At first I thought that it was only segfaulting when gmp was called from flint. But in fact I can make it segfault calling gmp directly from the program, though only in slightly strange circumstances. If I take the integer a = 123456789, I can compute the square and cube of this without problems. But if I try to compute the fourth power it segfaults. If I call gmp_printf it segfaults. And I checked that the mpz_t I'm trying to print contains valid data and that accessing it doesn't cause a segfault. In fact, the MPIR test suite fails most of its tests. In particular I notice that C only functions pass their tests, but assembly ones don't. I've got a feeling that msys have changed how it reports itself in a way that autotools hasn't kept up with, causing it to compile in linux assembly functions instead of Windows ones. Given that patching the linux assembly file and not the Windows one causes msys2 to not barf on that file, I'd say that's a certainty. Now I just have to hack autotools one more time to recognise msys2 and I should be ok. This is why I don't use autotools in flint. Bill. On Sunday, 14 September 2014 19:21:53 UTC+2, Bill Hart wrote: > > I checked that the MPIR dll's produced with the updated msys2 also don't > work with Julia 0.2. > > I can't think of many other variables here. It has to be msys2 related. I > could try not patching the assembly file it barfs on, but have it built > from C fallback code. But I know for a fact that file is not being used in > the functions I'm calling that cause it to segfault. > > I can try uninstalling msys2 completely and reinstalling it and mingw64 > and see if I get any joy. > > On Sunday, 14 September 2014 19:05:55 UTC+2, Bill Hart wrote: >> >> >> >> On 14 September 2014 17:46, Tony Kelman <[email protected]> wrote: >> >>> >>> > Unfortunately it doesn't even work on my machine. It seems ok for some >>> calls into the dll, but as soon as I try to say print something using a >>> function in the MPIR dll it segfaults. I suppose it must be linked against >>> subtly different Microsoft dll's than Julia and some kind of conflict >>> results. >>> >>> Or maybe different GCC dll's. Exactly which version of MinGW-w64 are you >>> using? >>> >> >> I've just updated the msys2 packages with pacman. Recently I updated just >> some of the packages and not others, and I thought this might have >> introduced some incompatibilities. I noticed that if I build MPIR even with >> msys2 and not via Julia, the resulting dll doesn't work any more. >> >> After updating msys2 fully to msys 2.0.1, it still doesn't work. So it >> looks to me like some new issues have been introduced by the more recent >> msys or something. >> >> Their gas also barfs on one of the assembly files which we now have to >> patch. This issue affects GMP too, not just MPIR since we use the same code >> for that file. >> >> >>> Might not be compatible with what was used to build Julia. Or there >>> could be some issue due to having gmp and mpir both loaded within the same >>> process? >>> >> >> Just to reiterate, it was working fine before. I even went back to the >> precise configure invocation I used before in my bash history to ensure I >> was building MPIR the same way as before, and I checked which alpha version >> of MPIR I used. >> >> Admittedly I was using Julia 0.2.1 before, not Julia 0.3, which I have >> now upgraded to. >> >> I can try downloading Julia 0.2 for Windows again and see if that fixes >> the issue I guess. >> >> >>> We've seen sort-of-similar issues with blas and lapack and various >>> packages, though not so much on Windows. >>> >>> > The problem must be what libtool is doing on mingw64. Make install >>> doesn't even copy the generated dll across to the install directory, so you >>> have to do this manually. >>> >>> Hm, yeah, libtool can be very picky, especially when it comes to dll's. >>> I think I've used the "subtle and quick to anger" quote on this list before >>> when talking about libtool... I've found configuring >>> with lt_cv_deplibs_check_method=pass_all can sometimes help. >>> >>> > I also can't build flint against the Julia mpir and mpfr since Julia >>> doesn't seem to distribute the gmp.h and mpfr.h files, and flint requires >>> these when building. >>> >>> Oh, right, damn. Sorry I forgot about that! That is an issue, maybe we >>> should open a separate discussion on that general topic. It has come up >>> before that various packages would like to link against the same libraries >>> as Julia (in the Blas and Lapack cases we're building with an incompatible >>> ABI which makes this actually not a good idea in most cases, but for GMP >>> and MPFR I think we're configuring them in the default way), so installing >>> the corresponding headers would actually be necessary. >>> >>> Even though I'm not entirely sure what Nemo or Flint do or whether I >>> would personally have a use for them, I have some strange desire to see >>> more Julia packages be painless to install cross-platform and want to help >>> here. >>> >> >> I can understand that. >> >> >>> Let me know how the runtime configuration of the text file location >>> goes, >>> >> >> It won't happen for a while. I'm afraid I'm currently 14 days behind >> schedule at work. I've spent days trying to get this to work on Windows and >> have just run out of time to keep working on it. I will have to come back >> to it when I catch up with everything else that has been piling up. Perhaps >> I can spend some more time on it next weekend. >> >> >>> then I can mock up what BinDeps would look like. It should simplify your >>> deps/build.jl script by automating the standard download, extract, >>> configure, make steps. There are also some Julia idioms like >>> joinpath("a","b") that would be cleaner than what you're doing now with if >>> statements to switch between forward slashes and backslashes, and things >>> like >>> >>> cd(newdir) do >>> ... >>> end >>> >>> that work in a nicer way including returning to the old directory even >>> on failure. >>> >>> >>> Thanks, I will try to incorporate these suggestions in a later >> incarnation of the code. >> >> Bill. >> >
