Home | News | Download | Packages | Forum | Wiki | Github

[SOLVED] Nim unable to access OS modules on Void musl


#1

I’ve started working with nim and I’m running into some issues that only seem to crop up on void. I run the musl version and I haven’t yet tried it with the glibc version but I may do a fresh install on a different system when I get home to see if this happens there.

It seems some libraries aren’t properly importing when compiling. Take this code:

import times, os

var start = epochTime()
os.sleep(1000)

echo epochTime() - start

When compiling

nim comile import.nim

I get this compiler output with error:

Hint: used config file '/usr/lib/nim/config/nim.cfg' [Conf]
Hint: system [Processing]
Hint: import [Processing]
Hint: times [Processing]
Hint: strutils [Processing]
Hint: parseutils [Processing]
Hint: math [Processing]
Hint: algorithm [Processing]
Hint: os [Processing]
import.nim(4, 4) Error: undeclared identifier: 'sleep'

I run the same code through the compiler on Ubuntu 16.04 and it works. I wonder if anyone here might have any ideas on how to get nim to properly import the os modules on musl? The standard nim libraries import and work (such as times in the example). I’m guessing it’s only these os level functions that are inaccessable and the only thing I can guess to be the cause it musl.

Are there any specific things I should check? My plan now is to install glibc void on a separate machine to see what the results are there. If it works there I’d guess it is an issue in musl? I’m new to debugging things with musl so I would be happy to have some imput.

Thanks!

P.S. I installed nim from xbps and, once I realized I was having issues, compiled it myself as well to check that it wasn’t the binary. No difference.


(Masato the Empty) #2

I don’t know much about nim beyond what I’ve briefly read (a general description) but if it saves you some trouble, I can tell you that on x86_64/glibc your code does build.

Based on glibc results, os.nim should be importing posix.nim, but I don’t see any output above to indicate that it is; however, if it does not, it should instead generate an error. (you can see the relevant code right near the beginning of /usr/lib/nim/lib/pure/os.nim)

Perhaps that detail can help you nail down the failure, but note that I’m deducing things (guessing, really) largely from context here so there could be things I don’t know about nim that could explain the difference in output…


#3

Thanks for trying it yourself. The note about the posix include is helpful. When I explicitly import it I get further and can compile. I’m not sure what to make of this since, as you pointed out, it should always be importing those headers.

I did set up a glibc filesystem anyway to test it there and surprisingly I also get the error there. I was beginning to wonder if I’m just missing some libraries or something but I’ve tried installing everything that seems relevant. But all based on my best guess so I could have missed something important. Do you have any suggestions as far as C libraries to check?


(Masato the Empty) #4

I don’t know.
The only devel libs I have on my system are the ones required by gcc and nim’s only dependencies are gcc and glibc (or musl on musl systems I’d think).

If you crank up the verbosity, you can actually try and see a line-by-line processing of all the code pulled in, in the order it gets pulled in. (you can see it processing pure/os.nim for a few lines before jumping to posix/posix.nim and returns back to pure/os.nim)

that’s on my system where this is working. I don’t know if it will tell you what’s wrong, but maybe it will tell you where exactly it stops processing os.nim, because it sounds like the thing is being short-circuited on your system before it ever even reads in the line for importing the posix module.

this generates many lines, so you’ll want to pipe it to a file.
nim compile --verbosity:3 import.nim > nimlog 2>&1
(all the juicy stuff goes to stderr, so you want to capture that too)


#5

I’m not completely sure how but I think either the nim cache or the source code was corrupted and not compiling properly. I was able to import the os.nim library in a new script and it executed like you’re describing.

All along I was noticing strange things like lines from other source files that I compiled previously showing up in the output and I bet that it was some confluence of things between the naming of the source file and the nim cache. Anyway, I don’t think it’s related to Void at all, which is a relief. Some folks over on the nim IRC pointed out that the forceRebuild flag should rebuild all the modules in the cache.

nim complile -f

Thanks for the help.