> Firstly, GMP 5 is currently a drop-in replacement for MPIR for us. We prefer to use MPIR since I am the maintainer of the latter, and significant work has gone into making various features faster.
If the reverse is true, and MPIR would be a drop-in replacement for GMP for Julia, then it could also be a possibility that Julia could try to use MPIR instead of GMP in the future. I'm not aware of the specific differences other than MPIR intends to be more compatible with MSVC, and compiling Julia with MSVC is an ongoing experiment that I've done a fair amount of work on. Having the maintainer of a dependency library happen to be a user of Julia might be convenient for... reasons. > For flint we definitely require the latest bleeding edge git version. Even the last official release from us, flint-2.4.4, will not work with Nemo. We can experiment with bleeding edge git instead. We'll have to see how many more changes will be needed. Presumably you can tag a release of flint once we're happy things are working? > The CP text file is absolutely enormous (nearly a megabyte). Encoding it as a string is certainly out of the question (we strictly adhere to the ANSI standard, which limits strings to something like 750 bytes). We've discussed many other ways of handling it, and numerous people have tried various things. It's a major pain in the backside, but totally necessary to have it (mathematically speaking). > > Currently it is not too bad in that once flint is installed, so is the file, in a location with a fixed offset from the library (which will have been specified by --prefix). If the user chooses to build flint in the source tree, it is located in a fixed location within the source tree which flint can also find it. This is all fine, so long as nothing gets moved after compilation and installation, which is the usual case, it seems. So is the path a relative path between the library and the text file, or an absolute path to the text file? When installing from a binary we can keep the relative path consistent pretty easily, absolute path definitely not. If it's an absolute path, would it be feasible to check the compile-time defined path first by default (as is done currently), but fall back to using an environment variable or other runtime path initialization method if the default location fails? > The problem with linking against Julia's GMP and MPFR was as follows. We can tell Julia where to find flint by pushing to DL_LOAD_PATH. But this only tells Julia where to find flint. The system linker is the one that tries to subsequently link flint with MPIR and MPFR, and it hasn't got a clue where to find them. What we push on DL_LOAD_PATH is irrelevant, as only Julia knows about that. This actually causes Julia to report that it can't find flint. I spent many, many hours figuring that one out. I'm not proposing to push anything to DL_LOAD_PATH for GMP or MPFR. Rather we tell flint's build system at compile time where to find Julia's GMP and MPFR via -L. Those libraries will always be either at a consistent relative path vs JULIA_HOME, or in standard system library paths if the user (or package manager) built Julia against system GMP/MPFR. I think it would be safe to check if joinpath(JULIA_HOME,"..","lib","libgmp.$(sys.dlext)") is openable via dlopen_e, and if not then falling back to find_library(["libgmp"]). > Now it occurs to me that perhaps if we build flint against Julia's GMP and MPFR (assuming GMP is version 5 and MPFR version 3.1), then because Julia's libs are placed in the path by Julia, the system linker might just find them. That hadn't occurred to me as a possibility. The obvious problem is GMP is not MPIR and we are limited to using whatever version of GMP Julia chooses. Actually, maybe the git version of flint already supports GMP 6 nowadays too. For Julia 0.3.0, GMP is version 5.1.3, MPFR is version 3.1.2. Check https://github.com/JuliaLang/julia/blob/768187890c2709bf2ff06818f40e1cdc79bd44b0/deps/Versions.make for the default version numbers used. On Julia master, GMP has been bumped to 6.0.0. > Also, flint uses libgcc_s and pthreads (and libm). We've currently set it up to statically build libgcc_s into flint, but we can't do that with pthreads. Initially at least we could disable pthreads when building flint (there is an option for it) but I guess in the long run we won't want to do that. I guess we can for now, but it seems like a compromise. You don't need to do this if you use WinRPM. If libgcc_s and/or pthreads are dynamically linked, the RPM packaging scripts on the build service detect that and mark the dll's as dependencies, so they get correctly downloaded when you install the package. Linking dynamically will make your binaries smaller, and many other things also link to these same libraries. > Regarding licenses, I would guess the GPL v3 and LGPL v3 license texts need to be distributed with Julia binaries, along with a written offer to provide the source code (or the actual source code). Certainly the LGPL allows Julia to dynamically link against LGPL libraries without becoming a derivative work. I don't want to make absolute statements about that issue, as IANAL, but I'd be interested in more details of how Julia is satisfying the conditions summarised here http://en.wikipedia.org/wiki/GNU_General_Public_License#Terms_and_conditions LICENSE.md was clarified recently, and DISTRIBUTING.md has some additional information on this too. I don't think any of Julia's required dependencies are GPL-3 only, it looks like all the GPL ones are either GPL-2 or GPL-2+. Binaries of flint would need to include its own license, but flint is not being distributed with Julia here, just available to easily download in a user-triggered fashion. > I didn't realise @unix_only was the opposite of @windows_only. I thought unix meant Free BSD, Net BSD, Unix, etc. And I couldn't see a way to combine Unix, Linux and OSX using the macros. Given that OSX is probably going to need something special, I'm not sure what the best combination of macros will be. OSX is a Unix. It is special and needs its own modified code much of the time, yes. > Popcnt is processor dependent. TLS is more OS dependent and I think available on Mingw. We can just disable hardware popcnt. It's not vitally important for more than about one noncritical function. The TLS check passes on a local MinGW configure. Should I enable TLS then? I'll leave popcnt disabled if you recommend as much.
