Hi Tony, A quick reply as I am about to be unavailable for some hours.
On Saturday, 13 September 2014 09:19:27 UTC+2, Tony Kelman wrote: > > > 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? > We tend not to use tags. But there's no problem introducing a named tag to pin things. > > > 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 way it currently works is the user will specify --prefix. This is where libflint will be installed (in a subdirectory called lib). Obviously a default is chosen otherwise. Flint is at first built inside its own source tree. Flint knows where to find the file relative to this source tree. But when make install is issued, it will be moved across to --prefix. As flint is compiled, --prefix is used to generate an absolute path where the text file will be stored, and this is baked into the library, which then also looks in this absolute path. Of course the absolute path is computed at compile time to be some path relative to --prefix. It is passed to the relevant parts of flint via a -D define. I don't know of a way to encode a path relative to where the library is installed. That would be very useful, if possible. But I'm not sure if it can be done. > > 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, > Ah, I think JULIA_HOME should be useful. I didn't know about this. > 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"]). > Ok. > > > 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. > Those are fine for now of course. If not I can easily push patches to flint to ensure that it is. > > > > 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. > Great. > > > 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. > Since git is installed with Julia, I'd like to git clone flint as part of the install process, so that the user always has the source code of flint (and the license, etc). Flint is GPL, not LGPL. There is no linking exemption for flint. On the other hand, the FSF seems to be pretty isolated in its position that dynamic linking to a library results in a derived work. Fortunately there is almost no FSF code in flint and it is all LGPL'd. No one else is going to care. > > > 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. > > Sure. More when I return in a few hours. I think I will get things going temporarily on Windows by modifying PATH first. Then I will promise a binary distribution method to come, which we can work on. Bill.
