Windows package binaries discussion [was: Julia C++ FFI code release]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Windows package binaries discussion [was: Julia C++ FFI code release]

Tony Kelman-2
Starting a separate thread here, like we should've done a few posts earlier.

> The hard part isn’t getting the binary to someone’s computer. The problem is getting exactly one copy of a binary, and making sure it is the correct version, built against the correct libc, and plays nice with the other binaries that want to depend upon it.

Yep. Especially for bigger libraries that other things are going to depend on, using a cohesive package manager for binaries makes sense. There are lots of subtleties here - for example the binaries from Isaiah's cross-compiled nightlies can't be used with the MinGW compiler versions that we recommend for from-source MSYS2 builds. If/when he upgrades his MinGW compilers to a new version, I hope he loudly warns us all. Same with OpenSuse build service, if they change their MinGW libgcc version on us it's entirely possible that we'll start running into a pile of problems.

For small packages that aren't going to be linked to by anything other than the one Julia package, it usually takes me about an hour to get them built and BinDeps+AppVeyor up and running, modulo portability bugs upstream and/or in the package code. I have been making a point to check the resulting binaries in Dependency Walker to see whether they're statically or dynamically linking to libgcc. So far most libraries have ended up statically linked, with no non-Windows dll dependencies. So sufficient is a good enough start in most cases.

What kind of delay does using the OpenSuse build service involve? I really don't want it to take a day to debug setting up a spec file from scratch, anything involving a build system of any kind always takes several iterations in my experience.

I wasn't able to find any documentation anywhere on OpenSuse, but this Fedora doc should hopefully be equivalent: https://fedoraproject.org/wiki/Packaging:MinGW

Reply | Threaded
Open this post in threaded view
|

Re: Windows package binaries discussion [was: Julia C++ FFI code release]

Jameson Nash


On Thu, Jul 31, 2014 at 9:23 AM, Tony Kelman <[hidden email]> wrote:
Starting a separate thread here, like we should've done a few posts earlier.

> The hard part isn’t getting the binary to someone’s computer. The problem is getting exactly one copy of a binary, and making sure it is the correct version, built against the correct libc, and plays nice with the other binaries that want to depend upon it.

Yep. Especially for bigger libraries that other things are going to depend on, using a cohesive package manager for binaries makes sense. There are lots of subtleties here - for example the binaries from Isaiah's cross-compiled nightlies can't be used with the MinGW compiler versions that we recommend for from-source MSYS2 builds. If/when he upgrades his MinGW compilers to a new version, I hope he loudly warns us all. Same with OpenSuse build service, if they change their MinGW libgcc version on us it's entirely possible that we'll start running into a pile of problems.

Definitely, but at least everything will break/work as a set. So there aren't too many places we need to go to fix it.

For small packages that aren't going to be linked to by anything other than the one Julia package, it usually takes me about an hour to get them built and BinDeps+AppVeyor up and running, modulo portability bugs upstream and/or in the package code. I have been making a point to check the resulting binaries in Dependency Walker to see whether they're statically or dynamically linking to libgcc. So far most libraries have ended up statically linked, with no non-Windows dll dependencies. So sufficient is a good enough start in most cases.

If the package author is will to do those checks, then it's probably fine to be distributing these separately. But how does one determine that it will never be used by more than one Julia package? Most C libraries exist to be linked against...

What kind of delay does using the OpenSuse build service involve? I really don't want it to take a day to debug setting up a spec file from scratch, anything involving a build system of any kind always takes several iterations in my experience.

I don't really know. My builds of mingw32-gtk3 updates seem to have happened almost immediately. There's some additional work because the RPM build engine forces you to confirm that the build file outputs matches expectations. But that's not necessarily a bad thing. I would hope that most users are just copying a template spec file, not trying to work completely from scratch. Building locally for testing just requires having an OpenSUSE VM (ideally) or anything that can read & install RPMs.

I wasn't able to find any documentation anywhere on OpenSuse, but this Fedora doc should hopefully be equivalent: https://fedoraproject.org/wiki/Packaging:MinGW

That link looks pretty good:
https://github.com/JuliaLang/WinRPM.jl/issues/28
Reply | Threaded
Open this post in threaded view
|

Re: Windows package binaries discussion [was: Julia C++ FFI code release]

Tony Kelman-2
> Definitely, but at least everything will break/work as a set. So there aren't too many places we need to go to fix it.

I'm not so sure about that. Only if OpenSuse does a rebuild-the-world within the MinGW project when they change compiler versions. If it's more piecemeal, where things only get rebuilt with new compilers the next time the maintainer bumps the packaging, then we'd have to go manually do that everywhere we need. It sounds like that's pretty easy to do, but you run the risk of something down the chain not building right with any new compiler version. Lots of potential for suck.

> If the package author is will to do those checks, then it's probably fine to be distributing these separately. But how does one determine that it will never be used by more than one Julia package? Most C libraries exist to be linked against...

True. We'll have to see. When something like Sundials or some other library gets Julia bindings written for it, the hope would be that other Julia packages can access the functionality through the Julia API instead of the C API. Of course that's impractical when the dependency is already there at the C level. The COIN-OR codebase is one example that's built as a big stack of interdependencies, right now there are only a few pieces of it in JuliaOpt but I anticipate more of the libraries getting bindings eventually, and it would make sense to break apart the binaries at a more granular level.

> Building locally for testing just requires having an OpenSUSE VM (ideally) or anything that can read & install RPMs.

Ugh. Time to familiarize myself with the VBoxManage CLI then. Or find yet another old machine to hijack.

> I would hope that most users are just copying a template spec file, not trying to work completely from scratch.

Ideally, yes. That Fedora example looks like a good minimum skeleton to start from, otherwise I'd have to go digging for some simple example to copy (and hope I picked one that was following "best practices").

Reply | Threaded
Open this post in threaded view
|

Re: Windows package binaries discussion [was: Julia C++ FFI code release]

Jameson Nash
AFAICS, it rebuilds dependants also afterwards. I doubt they would want to introduce a breaking change to the compiler ABI, although I still don't understand why the cross and native compile don't play nicely together.

I use virsh (CLI) / virt-manager (GUI) with kvm/qemu on a virtual X screen run by xpra and forwarded to my local machine with Window-Switch. I've been pretty happy with this setup (and then use VNC to view the VM once configured)


On Thursday, July 31, 2014, Tony Kelman <[hidden email]> wrote:
> Definitely, but at least everything will break/work as a set. So there aren't too many places we need to go to fix it.

I'm not so sure about that. Only if OpenSuse does a rebuild-the-world within the MinGW project when they change compiler versions. If it's more piecemeal, where things only get rebuilt with new compilers the next time the maintainer bumps the packaging, then we'd have to go manually do that everywhere we need. It sounds like that's pretty easy to do, but you run the risk of something down the chain not building right with any new compiler version. Lots of potential for suck.

> If the package author is will to do those checks, then it's probably fine to be distributing these separately. But how does one determine that it will never be used by more than one Julia package? Most C libraries exist to be linked against...

True. We'll have to see. When something like Sundials or some other library gets Julia bindings written for it, the hope would be that other Julia packages can access the functionality through the Julia API instead of the C API. Of course that's impractical when the dependency is already there at the C level. The COIN-OR codebase is one example that's built as a big stack of interdependencies, right now there are only a few pieces of it in JuliaOpt but I anticipate more of the libraries getting bindings eventually, and it would make sense to break apart the binaries at a more granular level.

> Building locally for testing just requires having an OpenSUSE VM (ideally) or anything that can read & install RPMs.

Ugh. Time to familiarize myself with the VBoxManage CLI then. Or find yet another old machine to hijack.

> I would hope that most users are just copying a template spec file, not trying to work completely from scratch.

Ideally, yes. That Fedora example looks like a good minimum skeleton to start from, otherwise I'd have to go digging for some simple example to copy (and hope I picked one that was following "best practices").

Reply | Threaded
Open this post in threaded view
|

Re: Windows package binaries discussion [was: Julia C++ FFI code release]

Isaiah Norton
On Thu, Jul 31, 2014 at 12:35 PM, Jameson Nash <[hidden email]> wrote:
AFAICS, it rebuilds dependants also afterwards. I doubt they would want to introduce a breaking change to the compiler ABI, although I still don't understand why the cross and native compile don't play nicely together.

This is very strange. The build system is using gcc 4.8.2 as opposed to 4.8.1, but is otherwise identical (same threading and exception models as we recommend for building from source).

Tony - is there an issue about this or notes somewhere?
 

I use virsh (CLI) / virt-manager (GUI) with kvm/qemu on a virtual X screen run by xpra and forwarded to my local machine with Window-Switch. I've been pretty happy with this setup (and then use VNC to view the VM once configured)


On Thursday, July 31, 2014, Tony Kelman <[hidden email]> wrote:
> Definitely, but at least everything will break/work as a set. So there aren't too many places we need to go to fix it.

I'm not so sure about that. Only if OpenSuse does a rebuild-the-world within the MinGW project when they change compiler versions. If it's more piecemeal, where things only get rebuilt with new compilers the next time the maintainer bumps the packaging, then we'd have to go manually do that everywhere we need. It sounds like that's pretty easy to do, but you run the risk of something down the chain not building right with any new compiler version. Lots of potential for suck.

> If the package author is will to do those checks, then it's probably fine to be distributing these separately. But how does one determine that it will never be used by more than one Julia package? Most C libraries exist to be linked against...

True. We'll have to see. When something like Sundials or some other library gets Julia bindings written for it, the hope would be that other Julia packages can access the functionality through the Julia API instead of the C API. Of course that's impractical when the dependency is already there at the C level. The COIN-OR codebase is one example that's built as a big stack of interdependencies, right now there are only a few pieces of it in JuliaOpt but I anticipate more of the libraries getting bindings eventually, and it would make sense to break apart the binaries at a more granular level.

> Building locally for testing just requires having an OpenSUSE VM (ideally) or anything that can read & install RPMs.

Ugh. Time to familiarize myself with the VBoxManage CLI then. Or find yet another old machine to hijack.

> I would hope that most users are just copying a template spec file, not trying to work completely from scratch.

Ideally, yes. That Fedora example looks like a good minimum skeleton to start from, otherwise I'd have to go digging for some simple example to copy (and hope I picked one that was following "best practices").


Reply | Threaded
Open this post in threaded view
|

Re: Windows package binaries discussion [was: Julia C++ FFI code release]

Tony Kelman-2
See https://github.com/JuliaLang/julia/pull/6028#issuecomment-38022073

I'm really not sure what the problem is, but get segfaults when I try any mixing-and-matching of binaries that involves the 4.8.1 MinGW-builds compilers.


On Thursday, July 31, 2014 9:56:28 AM UTC-7, Isaiah wrote:
On Thu, Jul 31, 2014 at 12:35 PM, Jameson Nash <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="YS_OTfXI6g8J" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">vtj...@...> wrote:
AFAICS, it rebuilds dependants also afterwards. I doubt they would want to introduce a breaking change to the compiler ABI, although I still don't understand why the cross and native compile don't play nicely together.

This is very strange. The build system is using gcc 4.8.2 as opposed to 4.8.1, but is otherwise identical (same threading and exception models as we recommend for building from source).

Tony - is there an issue about this or notes somewhere?
 

I use virsh (CLI) / virt-manager (GUI) with kvm/qemu on a virtual X screen run by xpra and forwarded to my local machine with Window-Switch. I've been pretty happy with this setup (and then use VNC to view the VM once configured)


On Thursday, July 31, 2014, Tony Kelman <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="YS_OTfXI6g8J" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">tav...@...> wrote:
> Definitely, but at least everything will break/work as a set. So there aren't too many places we need to go to fix it.

I'm not so sure about that. Only if OpenSuse does a rebuild-the-world within the MinGW project when they change compiler versions. If it's more piecemeal, where things only get rebuilt with new compilers the next time the maintainer bumps the packaging, then we'd have to go manually do that everywhere we need. It sounds like that's pretty easy to do, but you run the risk of something down the chain not building right with any new compiler version. Lots of potential for suck.

> If the package author is will to do those checks, then it's probably fine to be distributing these separately. But how does one determine that it will never be used by more than one Julia package? Most C libraries exist to be linked against...

True. We'll have to see. When something like Sundials or some other library gets Julia bindings written for it, the hope would be that other Julia packages can access the functionality through the Julia API instead of the C API. Of course that's impractical when the dependency is already there at the C level. The COIN-OR codebase is one example that's built as a big stack of interdependencies, right now there are only a few pieces of it in JuliaOpt but I anticipate more of the libraries getting bindings eventually, and it would make sense to break apart the binaries at a more granular level.

> Building locally for testing just requires having an OpenSUSE VM (ideally) or anything that can read & install RPMs.

Ugh. Time to familiarize myself with the VBoxManage CLI then. Or find yet another old machine to hijack.

> I would hope that most users are just copying a template spec file, not trying to work completely from scratch.

Ideally, yes. That Fedora example looks like a good minimum skeleton to start from, otherwise I'd have to go digging for some simple example to copy (and hope I picked one that was following "best practices").


Reply | Threaded
Open this post in threaded view
|

Re: Windows package binaries discussion [was: Julia C++ FFI code release]

Tony Kelman-2
And oh yeah, you can try this yourself by putting msys_build.sh from that PR under contrib/windows and running it in an MSYS environment. Preferably use a clean clone for this, should only take ~15 minutes to build using downloaded binaries.

If you try it in Cygwin with the MinGW-w64 compilers installed, it should work. Though now that Cygwin has bumped to 4.8.3 it might be broken, I've been intentionally holding my compiler versions back so I'm not sure.


On Thursday, July 31, 2014 10:46:17 AM UTC-7, Tony Kelman wrote:
See <a href="https://github.com/JuliaLang/julia/pull/6028#issuecomment-38022073" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2FJuliaLang%2Fjulia%2Fpull%2F6028%23issuecomment-38022073\46sa\75D\46sntz\0751\46usg\75AFQjCNEy5UEC1jbKWUwt12TnaHLYRyB8_w';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2FJuliaLang%2Fjulia%2Fpull%2F6028%23issuecomment-38022073\46sa\75D\46sntz\0751\46usg\75AFQjCNEy5UEC1jbKWUwt12TnaHLYRyB8_w';return true;">https://github.com/JuliaLang/julia/pull/6028#issuecomment-38022073

I'm really not sure what the problem is, but get segfaults when I try any mixing-and-matching of binaries that involves the 4.8.1 MinGW-builds compilers.


On Thursday, July 31, 2014 9:56:28 AM UTC-7, Isaiah wrote:
On Thu, Jul 31, 2014 at 12:35 PM, Jameson Nash <[hidden email]> wrote:
AFAICS, it rebuilds dependants also afterwards. I doubt they would want to introduce a breaking change to the compiler ABI, although I still don't understand why the cross and native compile don't play nicely together.

This is very strange. The build system is using gcc 4.8.2 as opposed to 4.8.1, but is otherwise identical (same threading and exception models as we recommend for building from source).

Tony - is there an issue about this or notes somewhere?
 

I use virsh (CLI) / virt-manager (GUI) with kvm/qemu on a virtual X screen run by xpra and forwarded to my local machine with Window-Switch. I've been pretty happy with this setup (and then use VNC to view the VM once configured)


On Thursday, July 31, 2014, Tony Kelman <[hidden email]> wrote:
> Definitely, but at least everything will break/work as a set. So there aren't too many places we need to go to fix it.

I'm not so sure about that. Only if OpenSuse does a rebuild-the-world within the MinGW project when they change compiler versions. If it's more piecemeal, where things only get rebuilt with new compilers the next time the maintainer bumps the packaging, then we'd have to go manually do that everywhere we need. It sounds like that's pretty easy to do, but you run the risk of something down the chain not building right with any new compiler version. Lots of potential for suck.

> If the package author is will to do those checks, then it's probably fine to be distributing these separately. But how does one determine that it will never be used by more than one Julia package? Most C libraries exist to be linked against...

True. We'll have to see. When something like Sundials or some other library gets Julia bindings written for it, the hope would be that other Julia packages can access the functionality through the Julia API instead of the C API. Of course that's impractical when the dependency is already there at the C level. The COIN-OR codebase is one example that's built as a big stack of interdependencies, right now there are only a few pieces of it in JuliaOpt but I anticipate more of the libraries getting bindings eventually, and it would make sense to break apart the binaries at a more granular level.

> Building locally for testing just requires having an OpenSUSE VM (ideally) or anything that can read & install RPMs.

Ugh. Time to familiarize myself with the VBoxManage CLI then. Or find yet another old machine to hijack.

> I would hope that most users are just copying a template spec file, not trying to work completely from scratch.

Ideally, yes. That Fedora example looks like a good minimum skeleton to start from, otherwise I'd have to go digging for some simple example to copy (and hope I picked one that was following "best practices").


Reply | Threaded
Open this post in threaded view
|

Re: Windows package binaries discussion [was: Julia C++ FFI code release]

Tony Kelman-2
In reply to this post by Jameson Nash
I hereby retract my "ugh" - my favorite thing of the day is officially vagrant.


On Thursday, July 31, 2014 9:35:33 AM UTC-7, Jameson wrote:
AFAICS, it rebuilds dependants also afterwards. I doubt they would want to introduce a breaking change to the compiler ABI, although I still don't understand why the cross and native compile don't play nicely together.

I use virsh (CLI) / virt-manager (GUI) with kvm/qemu on a virtual X screen run by xpra and forwarded to my local machine with Window-Switch. I've been pretty happy with this setup (and then use VNC to view the VM once configured)


On Thursday, July 31, 2014, Tony Kelman <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="EFdnH9tmcFMJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">tav...@...> wrote:
> Definitely, but at least everything will break/work as a set. So there aren't too many places we need to go to fix it.

I'm not so sure about that. Only if OpenSuse does a rebuild-the-world within the MinGW project when they change compiler versions. If it's more piecemeal, where things only get rebuilt with new compilers the next time the maintainer bumps the packaging, then we'd have to go manually do that everywhere we need. It sounds like that's pretty easy to do, but you run the risk of something down the chain not building right with any new compiler version. Lots of potential for suck.

> If the package author is will to do those checks, then it's probably fine to be distributing these separately. But how does one determine that it will never be used by more than one Julia package? Most C libraries exist to be linked against...

True. We'll have to see. When something like Sundials or some other library gets Julia bindings written for it, the hope would be that other Julia packages can access the functionality through the Julia API instead of the C API. Of course that's impractical when the dependency is already there at the C level. The COIN-OR codebase is one example that's built as a big stack of interdependencies, right now there are only a few pieces of it in JuliaOpt but I anticipate more of the libraries getting bindings eventually, and it would make sense to break apart the binaries at a more granular level.

> Building locally for testing just requires having an OpenSUSE VM (ideally) or anything that can read & install RPMs.

Ugh. Time to familiarize myself with the VBoxManage CLI then. Or find yet another old machine to hijack.

> I would hope that most users are just copying a template spec file, not trying to work completely from scratch.

Ideally, yes. That Fedora example looks like a good minimum skeleton to start from, otherwise I'd have to go digging for some simple example to copy (and hope I picked one that was following "best practices").