-
Notifications
You must be signed in to change notification settings - Fork 47
BinaryProvider 0.5.9 breaks packages #194
Comments
Can you set |
OK, I edited
BTW, similar error with a package not by us:
|
What happens if you try to |
|
Here is another one I just run into, with yet another package:
|
It seems this issue only happens for me on macOS; I just tried it on a Linux server, and everything (?) seems fine so far |
BTW, is it on purpose that the |
Chiming in to report similar issues with Libtask on Arch Linux. Manually running the build file, ie |
History is a bit convoluted, there are two branches:
I also use Arch Linux, but I can't reproduce any of the issues reported. For example,
|
I encounter the same issue, with Window10, and julia v1.4.1. |
I've now also experienced this on a Gentoo machine:
The same ( |
Can someone please try and debug the issue on the platforms where they can reproduce it? It's a bit hard for me to understand what's going wrong without being able to experience it. |
I'd love to but I have no idea where to start? I guess the "satisfied" function needs to be scrutinized? I'll try tonight, but some guidance would be appreciated |
This should be the main difference between v0.5.8 and v0.5.9: e6710a7. For the rest I backported some changes there were on |
I think the problem is isolated dlopen in Products.jl:
If I turn isolate into false, it works. |
This is interesting, since e6710a7 was meant to fix another bug, observed in jump-dev/CSDP.jl#56.
It runs |
So, interestingly, I can't reproduce the issue if I do it "interactively". Here is a verbatim copy of something I just tried; note that I first get an error when
|
I've used the traditional debugging method of "insert lots of println to get a better idea", and am ever more baffled... Here is what the code inside
And here is what I see:
And yet, if I directly perform the "isolated" call to
"But", one may complain, " this is not exactly what the code in BinaryProvider does, it uses Base.julia_cmd()!". OK, let's try that; I already printed it above for that reason:
So this still works. At this point the only thing I can think of is "what's the environment like". And so I start
I assume this is being set by I can investigate further tomorrow but now need to get some sleep. |
@giordano any other ideas what I could/should try? This issue is really concerning to me; while it only affects a fraction of users, for those it's a showstopper. I've considered to just hardcode a dependency on BinaryProvider 0.5.8 in all our packages, but that's not nice either. |
If you have a system where you can reproduce the issue, can you play with the value of the |
BTW, I don't know if it's clear that I have zero experience with |
@giordano ah, sorry, I did in fact not realize it :-) Just had a look at https://github.com/JuliaPackaging/BinaryProvider.jl/graphs/contributors and I guess the person to bug about this is @staticfloat . Sorry for being dogged about this, but I really think this is a serious issue that potentially affects many, many users (and then is basically impossible to debug for them); in my eyes, |
And yeah, turning I have a machine where I can reproduce this 100% and still am willing to run any kind of tests there, but I need some guidance, because e.g. understanding and then debugging the Pkg sandbox code looks like a LOT of work if done blindly. |
I have the same problem on Windows 10. Several packages fail to build using I'm willing to help test on Windows 10, if someone can provide guidance. |
I'd step into BTW, to fix the issue can't you just set |
I am not sure people saw this, so let me repeat parts of my comments from above... First, some background: I have two Linux systems I test on a lot; on one the issue occurs, on the other it does not. They run two different Linux flavors, and I am guessing some minor difference in there triggers the bug. Now, I did a lot of testing on the two systems in parallel.. identical Julia 1.4.1 setups. First observation: if I run If I extract the shell command which gets executed, i.e., So it's not the command that is being invoked "in isolation", but rather something else that effects it... in its "environment"... so let's look at environment variables: I then went on and inserted Alas, I tried to "disable" JULIA_LOAD_PATH before running the command, but no luck so far. At this point I can't think of anything else that could be a source of difference, or anything else to try. I am happy to perform more tests, but as I said before, I need suggestions. And to be clear, the reason |
If you can reproduce this under linux you could try running the subprocess under strace or with debugging from ld-linux by adding one of the following to the julia command in
Maybe this gives an idea why dlopen fails, at least for linux, I have no idea if something similar can be done on mac os. I have tried on gentoo, manjaro and opensuse and so far cannot reproduce this. |
Thanks @benlorenz that was very helpful! Both command told me that in the "bad" case (triggered via e.g. |
Ignoring startup file seems to have fixed the issue for me. Thanks! Julia |
Awesome, thanks for the confirmation! Note that the fix is already in v0.5.10: JuliaRegistries/General#15196 |
Ok, it does look like the problem was that the startup file was creating some issues: JuliaMath/DecFP.jl#126 (comment) is a further evidence of it, and also on Slack a user reported that they had a non-trivial startup file that was probably making dlopen fail. For these reasons, I'm going to close this as fixed by #195. While BinaryProvider was not doing the right thing by loading the startup file, this points out that all users experiencing the issue have code in their init file that cause conflicts when running Julia non-interactively, so it's probably a good occasion to revisit its content. For example, if you use Revise or OhMyRepl I'd like to remind you that these are the recommended configuration to use:
Unconditionally loading these packaging and not guarding them with a |
As the title says. I see errors like this:
or this
And on the Julia slack, I saw other people report similar issues.
CC @fieker
The text was updated successfully, but these errors were encountered: