OpenWrt returns ModuleNotFoundError for site-packages/ephem/__init__.py", line 5, in <module> import ephem._libastro as _libastro

[BigBobDalton]

Is there a way to compile or correct this issue on OpenWrt?

[brandon-rhodes]

Alas, I have not heard of OpenWrt before. Were they any errors during the package install? Are there any files there with _libastro in their name?

[BigBobDalton]

I have opened a ticket with the makers of OpenWrt, it runs on archlinux. It's router software essentially.
no errors during install: pip install ephem Collecting ephem Using cached ephem-4.1.5-cp310-cp310-musllinux_1_1_aarch64.whl.metadata (6.0 kB) Using cached ephem-4.1.5-cp310-cp310-musllinux_1_1_aarch64.whl (1.8 MB) Installing collected packages: ephem Successfully installed ephem-4.1.5

Here is what is in the installation directory of /usr/lib/python3.10/site-packages/ephem

init.py pycache _libastro.cpython-310-aarch64-linux-gnu.so cities.py doc stars.py tests

Thanks for the quick reply 👍

[brandon-rhodes]

Oh! Router software? Then I might myself have used OpenWrt back years ago, or something similar — it was on a little Linksys WRT54G, think. But I never tried installing any third-party software.

The _libastro.cpython-310-aarch64-linux-gnu.so is the file that I would expect to be imported by that import statement in the code. You will probably have to use shared-object-file debugging tools to learn why it won't load dynamically from Python. Does OpenWrt have the strace command? I would run Python under strace, try doing the import, then see what system calls were invoked as it tried importing the module.

[BigBobDalton]

Strace is available, It returns still the same general error that ephem._libastro is not found.

munmap(0x7fbca29000, 8192)              = 0
munmap(0x7fbca81000, 8192)              = 0
write(2, "    import ephem\n", 17    import ephem
)      = 17
write(2, "  File \"/usr/lib/python3.10/site"..., 82  File "/usr/lib/python3.10/site-packages/ephem/__init__.py", line 5, in <module>
) = 82
openat(AT_FDCWD, "/usr/lib/python3.10/site-packages/ephem/__init__.py", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=24492, ...}) = 0
ioctl(3, TIOCGWINSZ, 0x7fc34eb3c8)      = -1 ENOTTY (Not a tty)
lseek(3, 0, SEEK_CUR)                   = 0
fcntl(3, F_DUPFD_CLOEXEC, 0)            = 4
fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbca7f000
read(4, "# The core functionalty of PyEph"..., 1024) = 1024
lseek(4, -828, SEEK_CUR)                = 196
close(4)                                = 0
munmap(0x7fbca7f000, 16384)             = 0
lseek(3, 0, SEEK_SET)                   = 0
read(3, "# The core functionalty of PyEph"..., 8192) = 8192
close(3)                                = 0
madvise(0x7fbc9de000, 4096, MADV_FREE)  = 0
madvise(0x7fbc9dc000, 4096, MADV_FREE)  = 0
write(2, "    import ephem._libastro as _l"..., 40    import ephem._libastro as _libastro
) = 40
write(2, "ModuleNotFoundError: No module n"..., 55ModuleNotFoundError: No module named 'ephem._libastro'

I even tried compiling ephem to the build, but gcc fails with

extensions/_libastro.c: In function 'PyInit__libastro':
extensions/_libastro.c:3248:11: internal compiler error: Segmentation fault
3248 | PyObject *PyInit__libastro(void)
| ^~~~~~~~~~~~~~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See https://dev.openwrt.org/ for instructions.
error: command '/usr/bin/gcc' failed with exit code 1

So, I followed their instructions and submitted a bug report.

[brandon-rhodes]

Well — I'm confused that we don't see any trace of Python trying to open the _libastro file. Usually there's a flurry of open() attempts looking for a module under different possible names, before Python gives up and raises an ImportError. But in this case it doesn't even try the name _libastro.py before giving up?

[BigBobDalton]

here Is the complete event list....there were just so many lines that I copied the failed...

pyStrace.txt

[brandon-rhodes]

Ah, yes, that provides an example: when you try to import ephem, it looks under a whole series of different names:

newfstatat(AT_FDCWD, "/usr/lib/python3.10/site-packages/ephem/__init__.cpython-310.so", 0x7fc019f018, 0) = -1 ENOENT (No such file or directory)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f88e96000
munmap(0x7f88e96000, 4096)              = 0
newfstatat(AT_FDCWD, "/usr/lib/python3.10/site-packages/ephem/__init__.abi3.so", 0x7fc019f018, 0) = -1 ENOENT (No such file or directory)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f88e96000
munmap(0x7f88e96000, 4096)              = 0
newfstatat(AT_FDCWD, "/usr/lib/python3.10/site-packages/ephem/__init__.so", 0x7fc019f018, 0) = -1 ENOENT (No such file or directory)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f88e96000
munmap(0x7f88e96000, 4096)              = 0
newfstatat(AT_FDCWD, "/usr/lib/python3.10/site-packages/ephem/__init__.py", {st_mode=S_IFREG|0644, st_size=24492, ...}, 0) = 0

But then it somehow decides to say ModuleNotFoundError: without doing such a search. But maybe this is a more recent version of Python that lists directories and skips some of the stat calls? I see earlier a getdents64() call. So maybe my old-fashioned understanding of the import system is out of date here.

In any case, I'm not sure of what I can do from PyEphem's direction to help here — it looks like the _libastro module is getting successfully built, it just can't then be imported?

[BigBobDalton]

yeah that was my thoughts as well. The entire linux structure from openwrt is much different than what I am use to from Debian or Ubuntu. I have the same python script running flawlessly with your module on my RaspberryPi running Raspbian Debian. I will have to wait and see what the programmers over at OpenWrt have to say..that may take a week or two. 😂

Thanks for your time to look at this 👍

[brandon-rhodes]

Thanks for your time to look at this

I'm glad we were able to peer beneath the covers a bit and at least see that the module got compiled. I'll be interested to hear what the OpenWrt folks say!

I'm going to temporarily close this issue since I don't have any further information to go on, but feel free to ask further questions here on the issue, or even to re-open it if you come back from the OpenWrt folks with an action item for the PyEphem project.