The library cross-compiles okay (at least at the last released version, I can try git master if you've made changes that are necessary), see https://build.opensuse.org/package/show/home:kelman/mingw32-flint and https://build.opensuse.org/package/show/home:kelman/mingw64-flint
It was made a little more challenging by the fact that flint uses a hand-rolled configure script that errors on unrecognized arguments. That configure script uses --build for what is conventionally meant by --host, the two differ in a cross compile. --host is where the compiled code is intended to run, --build is (in standard autotools) the machine that is doing the compiling. There was an existing openSUSE Linux package for flint here https://build.opensuse.org/package/show/science/flint with a patch to use real autotools, though it's not completely usable for a cross compile at the moment since it doesn't handle using GMP instead of MPIR. MPIR is not available as a cross-compiled package yet, though making one would probably be easy. The existing cross-compiled version of MPFR already links to GMP so I think it would be redundant. Flint has configure-time checks for popcnt and tls that run executables, neither of which work properly in a cross-compile. Locally on Windows they both succeed, but could those potentially be processor-dependent in any way? I could patch configure to override the results for the purposes of cross compiling, if you can recommend one way or the other. On the text file, it's really bad for library relocatability to hard-code the compile-time location of required data. Is the content of the file ever expected to change? If not, I would just hard-code its contents into a string or more appropriate data structure. If so, then its location should really be made a runtime setting, either through a library initialization API or from an environment variable or something. I could be wrong, but I don't think rpath does anything on Windows. Standard practice for MinGW libraries is to put dll files in bin/ rather than lib/ for this reason. If you were using libtool, it would create a .dll.a import library stub in lib/ to assist in linking to the dll if you wanted to compile a C/C++ application or library with -lflint. Luckily Julia doesn't need that stub to just ccall into a dll. -Tony On Friday, September 12, 2014 6:11:49 PM UTC-7, Tony Kelman wrote: > > > I'm worried about the legality of downloading binaries for users, since > the packages involved, GMP/MPIR, MPFR and FLINT are (L)GPL. > > Quite a few packages rely on (L)GPL code. The GPL is a long confusing > document, and limits commercial application of some code, that's for sure, > but to the best of my (IANAL) understanding it's not too onerous to comply > with for open-source projects. Mostly including the license in the > documentation and being careful about bundling/derived works. The spec > files on the build service have to clearly state the license, plenty of > libraries there are GPL and/or have GPL dependencies. > > > I see now that Julia adds things to the system PATH, which is why it is > picking up things in the GitBash bundled in Julia. If I can figure out how > to get PATH back to its original state temporarily, I think I can get the > build to succeed (supposing the user has MSYS2 and Mingw64 correctly > installed -- not easy, admittedly). > > You can modify ENV["PATH"] as you like, but I recommend against this > approach. Compare the relative difficulty of building Julia from source to > downloading and using the binary installer. On a slightly smaller scale, > having the package rely on MSYS2 and MinGW vs just downloading binaries > will lead to a similar usability comparison for your package. On Linux > there's much more variety in compiler and library versions so the best way > to download binaries is going through the system package manager, but if > your library isn't available in the package manager then building from > source is easy because compilers are really easy to install. On Mac it's a > little more annoying to install compilers, so a decent number of packages > use Homebrew.jl to distribute binaries. (Just have to set up a short > "formula" file with instructions on how to build, and bug Elliot, > @staticfloat on github, to build binaries for you). > > > I agree binary distribution is the normal method on Windows. But I've > already been forced to go through one FSF "license compliance review" > because a GNU project reported us for being in breach of the license. I'm > not doing it again. > > > > If there is a way to do things in strict accordance with the LGPL and > GPL I can go down that route. In that case, you can see the invocations > here: > > I can imagine that experience would give you pause here. If you can link > directly to the same version of GMP and MPFR as Julia is using (they are > currently required dependencies, so this should be fairly safe - just have > to figure out the best way to do it that would also work if someone is > using their system's version of GMP and/or MPFR), then you don't need to > worry about distributing anything except Flint itself. Would GMP be a > drop-in replacement for MPIR for you? If we use WinRPM, I believe it would > automatically detect GMP and MPFR (both are already available there) as > linked DLL's and automatically download them, we just have to declare the > dependency in the spec file and make sure configure picks them up or is > told explicitly where they are located. They would be in a standard > predictable location on the cross-compiling build machine. > > > https://github.com/wbhart/Nemo/blob/master/deps/build.jl > > > > Is that sufficient? > > I can see from that script how you're configuring, yes. Downloading and > building your own copy of MPIR and MPFR seems slightly redundant and > possibly problematic to load them from within the same process as Julia's > copies of GMP and MPFR. > > > I should mention that there are some complications. Flint needs to be > built in situ because it needs a large .txt file at runtime which contains > data it uses (Conway polynomials). The only way to tell flint where it will > be is through the build system, and the only way to know where it will be > is to actually build flint. > > Can that text file be included along with the binary? > > > Moreover, the system linker cannot find the dependencies MPIR and MPFR > of flint unless the -rpath is set by flint during build. And again, the > only way -rpath can be set is if flint knows where it is being built. > > You can't just provide a full -L path? > > A few minor notes, standard convention for Julia packages is to name the > Git repository include the ".jl" extension in its name. This helps visually > identify Julia package repositories easily, and is nice to keep consistent. > > You're also frequently doing "if on_windows", there's a pre-defined macro > for that: @windows_only, or the opposite @unix_only. > > -Tony > > >
