".nimble" File Detection broken on linux/arm/v7 via QEMU on amd64 Host
#1151
Comments
|
This is really weird. I don't have a lot of Docker experience. Perhaps Docker is doing something weird? My project which has a docker container works fine according to the person who implemented it, but perhaps something's changed in one of the latest commits? Can you run |
No problem. I am a very advanced Docker user. 😁
Does this include the
Where exactly? What do you need to know? What are you looking for? 🙂 |
|
Ah, I guess I didn't word this correctly. 😅 I'm curious as to why Nimble can't find the file with the ARM target but it can with ARM64. Execute this program: import std/os
writeFile("test", "hello!")
doAssert fileExists("test"), "File doesn't exist"what does it output? |
|
If the assertion fails and the file is indeed there, it's an upstream bug in the Nim std/os library with the ARM target. |
The Nim program with the assertion works. Notice, how it first does not find the local Nimble file. Then, it does not find the external one. This likely isn't related to file detection per sé, but to some permission madness with Nim on ARM... |
|
|
Nimble generally doesn't like being run under root. That being said, it shouldn't do what you're seeing either. |
Well, for other developers, which I have seen sometimes, it's usually easy to blame the environment, which is why I specifically have proof, that precisely the same setup works on |
|
Yeah, sorry if that came off as an excuse. I didn't mean for it to seem like one. I believe this is an issue with |
|
I just checked the code for that function and there is no way it's doing something wrong. Can Nimble/Nim run on your host OS? If it can, does it still do the same behaviour there as well? |
|
Do you have read permissions in the directory? @theAkito |
No, not at all, it did not come off as one. I actually was saying the opposite. Usually, I see others blaming the environment, but you do not do that. So, thanks! 😄
I am not sure about that. It starts to "work" when I add a file to the folder. How are those two actions even related? I am sure, if I would have a possibility to find out what random folder inside
I initialised a fresh container from a freshly built image & the directory in it looks like this. However, I'm running as root, anyway, so it shouldn't really matter. As an additional FYI, I can tell you, that I have quite a couple of Nim projects inside Docker images & containers & all build fine. This is however, the first project, which tries to run Nim Here, is an example of a project building fine on the official Nimage with Nim |
|
Ah, I meant if the non-root account had read access to the file. This doesn't seem to be an issue with Nim, probably Nimble doing something weird. I'll check that out once I get home. |
|
Hey. I've thoroughly checked Nimble and there is no way that it's either Nimble or Nim's fault. This is most likely an issue upstream with the POSIX library. Perhaps, Docker is doing something silly as well? |
I see. I saw this is a possibility, as well. What API would I need to call to be able to reproduce it in, for example, C? If I'm gonna open an issue on their side with Nim code, there's no way they will take it as an error with Docker or POSIX or whatever. They will say, it's because of Nim.... |
|
Nim calls stat() on POSIX systems. Perhaps, try that? |
|
|
That's so weird. I'll have to look further, but as far as I know, there shouldn't be any issues. This is really peculiar. |
|
Well, well, well.... So, I set up an entirely new Raspberry Pi with an Here is the result...
|
theAkito
changed the title
linux/arm/v7 via QEMU on amd64 Host
|
Afaik, Nim has nothing in place for VMs. It only has stuff for architectures, not VMs. |
I meant, maybe there are instructions that specifically do not work on certain virtual environments. So, if you do not account for those environments, you probably wouldn't catch the error, because it would always work on your system. However, that again sounds very unlikely, considering this only happens on ARM. Tested with precisely the same test, as before using the Raspberry Pi, just to make sure. Still, same result. So, I guess this must be a QEMU issue, then. Though, then I would need to do all this in a plain QEMU environment first, to make sure it happens there, as well. Otherwise, it still might be connected with Docker... Still plenty of work ahead! @xTrayambak Thanks for your help! Sorry, for making you put this much effort & time into this. It seems like, there is nothing wrong with Nimble in this case, although it all still smells fishy, because this error started happening with Nim 2.0.0 .... So, am not sure, if there is some new feature or whatever instruction, which did change to such behaviour. For now, I will pursue this on the QEMU end & see what happens then. Since this issue will not be solved, until it is fixed, wherever it ought to be fixed in, I think it's best to keep this issue open, because the original description is still true. Nimble does not fully work on ARM, from the perspective of a Nimble user. |
|
Alright. I wish you good luck in getting this fixed! 😄 |
|
@theAkito Any update on this? |
|
Probably should be tested on most recent Nim version, however I certainly won't be able to do that within the next two weeks. Perhaps, after that - I'll note that. |
https://github.com/theAkito/userdef
test.Dockerfile.arm64image.armimage.arm64image &nimble installproject dependencies & notice, that it works.armimage &nimble installproject dependencies & notice, that it does not work.Output from
nimble installonarm.Running
chown root:root -R .works around the local problem, but then the dependency cannot be installed, due to the same issue.All this works without an issue on
arm64. No errors, there.This is a showstopper for
armbuilds.The text was updated successfully, but these errors were encountered: