15

I am currently trying to get python to run on my NAS which is a Zyxel NSA325.

I did manage to get python 2.7 and pip running and I was able to successfully install the watchdog module with pip. I followed these instructions to get python and pip running btw.

When I run a python script that uses the watchdog module I get a weir error, tough. 

/usr/local/zy-pkgs/ffproot/ffp/bin/python2.7: '/ffp/lib/libc.so' is not an ELF file

I googled what the header of a ELF file is supposed to look like and apparently it starts with 7f 45 4c 46 which translates to .ELF. So I did a quick cat /ffp/lib/libc.so and the result was:

/* GNU ld script
 * Use the shared library, but some functions are only in
 * the static library, so try that secondarily. */
OUTPUT_FORMAT("elf32-littlearm", "elf32-bigarm",
         "elf32-littlearm")
GROUP ( libc.so.0 uclibc_nonshared.a AS_NEEDED ( ld-uClibc.so.0 ) )

Clearly this is not an ELF file. So I spent some more time researching and I think it is a linker script.

But now I'm out of ideas. Why is there a linker script in a .so file? Is that right? How can I fix it?

System info:

# uname -a
Linux NSA325-v2 2.6.31.8 #2 Fri Jun 23 11:03:47 CST 2017 armv5tel GNU/Linux
Forivin
  • 779
  • 5
  • 18
  • 37

1 Answers1

17

When you see a file named .so, it’s not necessarily a shared library. These files are used when linking a program at build-time, not run-time; they are commonly symlinks to the real shared library, but at least on systems using GNU ld they can also be linker scripts, and that’s perfectly OK. If you look on a modern glibc-based system you’ll find that libc.so is a linker script there too.

That doesn’t explain why Python (or the watchdog module) is looking for libc.so instead of libc.so.0... It could be a mis-configuration of the Python interpreter perhaps, or an invalid assumption in the watchdog module. I’ll take a look at the latter later today; if it’s the former, you’d be better off asking on the forum you linked to in your question.

Stephen Kitt
  • 411,918
  • 54
  • 1,065
  • 1,164
  • I had this problem too for a special JNI library which looked for libxxx.so files as well. The JAVA environment can not load these kind of scripted libraries. Is there a way around this system wise or is the vendor of the library responsible to avoid such a behaviour of the libs? – Thomas Jan 06 '20 at 12:00
  • I reckon that the JNI library should be fixed — it should either load libraries by soname (typically `libxxx.so.N`), or embed the library it expects in its JAR file. – Stephen Kitt Jan 07 '20 at 13:59