Installing ZMQ on Windows 7+ seems to require admin privileges

[jakebolewski]

When helping a students install Julia today on their Windows machines, launching julia without administrator privileges caused the ZMQ build to fail. @tkelman I saw that you recently updated the ZMQ Windows binary dependencies to use WinRPM, do you need to be an administrator to install some of these binary dependencies?

cc @stevengj

[jiahao]

Ref: mitmath/julia-mit#8 (comment)

[tkelman]

No, I don't think that should be the case at all. (edit: whoops I forgot something, see below) The downloads from WinRPM can be a bit flaky, so working when running with admin privileges may have been a coincidence. The ZMQ from WinRPM should be consistent with the Nettle download that's also using WinRPM, figured it was better to have them coming from the same place. And having both 32 and 64 bit versions installed simultaneously did not work with the old downloads, plus some reports of trouble with proxies.

[tkelman]

Exactly what was the error?

[jakebolewski]

Running julia as admin seemed to fix the problem for 4 different students, may have been a coincidence as you said but this was after repeated attempts at getting this working so I am unsure.

I should have saved the backtrace, but they were a bit impatient that this was not immediately working. I 'll try again on a Windows computer we have lying around to see if I can reproduce the problem.

[tkelman]

Oh, actually come to think of it I know what this might be, I forgot about an annoying detail with WinRPM - see https://github.com/JuliaLang/WinRPM.jl/blob/master/deps/build.jl. If you have Julia installed in program files or somewhere else that requires admin access to modify files, then WinRPM binaries won't work (pretty sure this includes nettle, zmq, and most of the JuliaOpt stack), you'll get a confusing "Provider PackageManager failed to satisfy dependency," until WinRPM can sucessfully replace the libgcc dll's that come with the binary installer with updated ones from WinRPM. OpenSUSE bumped their mingw cross-compilers to 4.9, so we need the libgcc dll's to match to use any binaries built from there. Cygwin's mingw cross-compilers are still on 4.8, so the buildbots don't have the latest version.

Short term, when people are installing Julia, encourage them to install somewhere non-default that doesn't require admin privileges to modify. Longer term I'll try to incorporate a build-time mini version of WinRPM that we can use to get the opensuse versions of the libgcc dll's (and a few other things while we're at it) to bundle with the Julia binaries.

[jakebolewski]

Ahh, that was indeed the error. Thanks so much for this information, and for all your hard work making Julia happen on Windows.

[jakebolewski]

I don't know where would be the best place to put this information, but it would be useful to highlight it somewhere.

[tkelman]

Yes - not sure where to put a note such that people will actually see it though. WinRPM issues tend to get reported all over, IJulia, base julia, packages using it directly (Nettle, ZMQ, Gtk, Cbc), etc. Ideally people wouldn't have to notice it doing its thing, but it's not there yet.

[jakebolewski]

I added a note to the class instructions. In general I don't know either. I feel a lot of useful information gets locked up in threads like this.

[tkelman]

Yeah, usually wherever the problem is originally found (JuliaPackaging/WinRPM.jl#33) and fixed (JuliaPackaging/WinRPM.jl#34). Dunno where to put a "miscellaneous categorized pro-tips, tricks, and troubleshooting tidbits" that would end up discoverable, useful, and not get too long.

What's a little odd about this one is I thought our default install location on Windows should not require admin rights. @ihnorton can you remember anything about that?

[ihnorton]

We install in AppData by default which should not require admin privileges.
I suppose some domain configurations could lock it, but that would be weird
and very restrictive, and is anyway unlikely for a personal laptop.

On Wed, Feb 11, 2015 at 11:42 PM, Tony Kelman notifications@github.com
wrote:

Yeah, usually wherever the problem is originally found (
JuliaPackaging/WinRPM.jl#33 JuliaPackaging/WinRPM.jl#33)
and fixed (JuliaPackaging/WinRPM.jl#34
JuliaPackaging/WinRPM.jl#34). Dunno where to put a
"miscellaneous categorized pro-tips, tricks, and troubleshooting tidbits"
that would end up discoverable, useful, and not get too long.

What's a little odd about this one is I thought our default install
location on Windows should not require admin rights. @ihnorton
https://github.com/ihnorton can you remember anything about that?

—
Reply to this email directly or view it on GitHub
#69 (comment).

[stevengj]

Can't WinRPM check for this and print a more comprehensible error message?

[tkelman]

I do to try repeat the error message in WinRPM, yes. I have an open BinDeps issue to add more explanatory output, particularly when dlopen fails. Just haven't gone digging deep enough into BinDeps to know where to put that yet.

[tkelman]

Alright, I got this to happen locally. Turns out, as long as Julia is installed to a non-admin location (which the default should be), you just need to restart Julia once after the first time WinRPM builds, and run Pkg.build("ZMQ") once after restarting. I even have a message saying as much, but it gets drowned out by a bunch of other blue INFO: messages. I could turn it into a warning so maybe it's slightly more noticeable? And this package needs a better error suggesting to run Pkg.build("ZMQ") if deps/deps.jl does not exist.

[stevengj]

What does restarting Julia accomplish?

[tkelman]

Loads the new replaced versions of libgcc, libstdc++, etc instead of the old incompatible ones. Surprisingly Windows lets you move the in-use dll's and put new files in their place, but keeps the old ones loaded in memory until you close the process. I could try something with dlclose but I'm not sure if it would work.

[stevengj]

Can we update Julia to use the up-to-date libgcc etc to start with?

[tkelman]

Yes. It requires either some fiddling with the buildbots to do manually, or changing the code in Julia's build system that currently copies the versions of these dll's from the build system's compiler, to instead download them straight from opensuse. I'm working on the latter, it requires some messy rpm metadata xml parsing - rewriting WinRPM.jl in bash/python/powershell, basically.

[davidanthoff]

Can whatever triggered this problem be reverted until this is fixed? My sense is that right now this problem breaks one of the main Julia features, i.e. IJulia, and such a critical piece should really not be down for a week or so...

[tkelman]

Sure. But this is fixable by restarting Julia, despite the non-obvious error message. What was broken before, that reverting to the old binaries would re-break, is simultaneously having both 32 and 64 bit versions of ZMQ (and hence IJulia) installed at the same time, and being able to install when behind a proxy.

[davidanthoff]

Hm, my sense is that the first-user-experience here is more important. This kind of error will just scare lots of people away, when they get an error right at the start of trying to work with julia. The workaround with restarting julia really doesn't help on that count... Having 32 and 64 bit versions of IJulia around at the same time seems a very specialized use case, and maybe those people that need that can checkout a different version of ZMQ for the time being?

But this issue should probably be looked at by more people from the core team and decided, an error in such a vital user-experience piece should really trigger immediate attention from a bunch of people.

[tkelman]

This kind of error will just scare lots of people away

So does a package manager that takes 10 minutes to do Pkg.update(), and I haven't seen rewriting the package manager get immediate attention from anyone...

This problem happens with any library that links to libstdc++ and comes from WinRPM. Restarting Julia once is a little annoying, but Julia has much bigger problems that scare off new users (package load times? BinDeps being a confusing mess that nearly every package uses but no one understands? still no debugger?). We can revert to the old binaries for now, but those binaries are a year and a half old, and no one even remembers who built them, much less how. It's not the right solution. At least I've got a workaround for the proxy issue on BinDeps master.

Any time you work with third-party binaries, where a subset of them only work with 32 bit and a different subset only work with 64 bit, you will frequently need to be switching back and forth between the two versions of Julia, and have a large set of Julia packages installed and working for both simultaneously. This isn't specialized, packages that don't support this are broken.

[ihnorton]

I'm working on the latter, it requires some messy rpm metadata xml parsing - rewriting WinRPM.jl in bash/python/powershell, basically.

You could install a release version of julia on the buildbot and run WinRPM that way. It's a little ugly, but less so than trying to do xml parsing in bash.

Or we could just manually (scriptedly) cache newer versions on S3 and download those. I don't think they change so frequently that this would need to be done more than (...once a month?). Probably would be good to avoid a buildbot dependency on WinRPM anyway, considering how flakey it can be.

[tkelman]

xml parsing in bash

I'm not quite that crazy. I'm using libxml2's command-line driver xmllint which should either exist or be easy to get on every build platform we care about.

Or we could just manually (scriptedly) cache newer versions on S3 and download those. I don't think they change so frequently that this would need to be done more than (...once a month?)

This is what we did with expat and zlib, and I'd rather fix that than do this for more libraries.

So I have a version written up that appears to work, and I was going to use it for the libgcc dll's instead of copying the build system's compiler's versions, as well as simplifying win-extras by using it for zlib and expat. Unfortunately this didn't work the first way I tried to do it. llvm-config built by cygwin's mingw-w64 g++ 4.8 won't run using libstdc++ from opensuse's mingw-w64 g++ 4.9. When llvm-config won't run, julia won't compile correctly.

So I'm trying a slightly different approach where instead of replacing some of win-extras with this, I'm adding the libgcc dll's to win-extras. I think the win-extras don't get moved until make dist gets run, so this might avoid breaking llvm-config. Though it could break llvm-config after running make dist and need to be cleaned up...

We should probably be using the opensuse gcc 4.9 for building all of Julia and dependencies on the buildbots, but this would require overwiting the cygwin copies so should start from a fresh separate copy of cygwin to avoid breaking things.

[tkelman]

I was about to revert to the old binaries for now, but testing them locally they fail an assertion (https://github.com/JuliaLang/libuv/blob/abcbb0c22faa527c427e1ea6b55f073836b26f69/src/uv-common.c#L83) in Pkg.test("ZMQ"). So I'm not so sure that's even the right temporary fix any more.

[tkelman]

Running the test content manually, Julia just dies at line 24 https://github.com/JuliaLang/ZMQ.jl/blob/2f52beb2b6bc3fcec6d461932e90e5acb49d8d36/test/runtests.jl#L24 with the old binaries - potentially the same problem as #58

[tkelman]

See JuliaLang/julia#10244

[datnamer]

@tkelman I'm getting a ZMQ (and RCall) build error on win 7 64 with julia 3.5. Julia is installed in appdata and I tried restarting. Any suggestions?

[tkelman]

Exactly what was the error?

I can't read your computer's mind.

[tkelman]

In addition to the full error message, and any info or warning messages you may have seen, which so far no one who has hit this issue has actually posted, the output of run(ls -al $JULIA_HOME) would be useful.

[tkelman]

This should also be fixed in 0.3.7.

[datnamer]

@tkelman its fixed in 0.3.7 latest. Thanks :)