1

I'm trying to compile Box86 on Alpine Linux, a Linux distribution which uses the musl libc implementation rather than glibc. At 46% completion, the compilation halts with the following errors:

/home/newbyte/box86/src/emu/x86syscall.c:124:11: error: '__NR_gettimeofday' undeclared here (not in a function); did you mean 'gettimeofday'?
  124 |     { 78, __NR_gettimeofday, 2 },
      |           ^~~~~~~~~~~~~~~~~
      |           gettimeofday
/home/newbyte/box86/src/emu/x86syscall.c:210:12: error: '__NR_clock_gettime' undeclared here (not in a function); did you mean 'clock_gettime'?
  210 |     { 265, __NR_clock_gettime, 2 },
      |            ^~~~~~~~~~~~~~~~~~
      |            clock_gettime
/home/newbyte/box86/src/emu/x86syscall.c:211:12: error: '__NR_clock_getres' undeclared here (not in a function); did you mean 'clock_getres'?
  211 |     { 266, __NR_clock_getres, 2 },
      |            ^~~~~~~~~~~~~~~~~
      |            clock_getres

Naturally, my first instinct was to look these names up and figure out what they are for so that I can find a suitable replacement, but I had little luck doing so, which leads me to my question: What are these __NR_-prefixed symbols, and what do they do?

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Newbyte
  • 2,421
  • 5
  • 22
  • 45
  • They're not supposed to be functions, but macros which should expand to numbers, i.e. system call numbers. You should include `` in order to pull the definitions in. –  Sep 29 '20 at 16:06
  • @user414777 Right, I realised halfway through writing that these probably aren't functions and changed my subsequent wording (but forgot to change the title). Thanks. I'll see if that works. – Newbyte Sep 29 '20 at 16:09
  • @user414777 Actually, `` already seems to be included? https://github.com/ptitSeb/box86/blob/master/src/emu/x86syscall.c#L7 (and I don't see any ifndef:s surrounding it) – Newbyte Sep 29 '20 at 16:11
  • 1
    Then your system headers don't define them. Not all system call numbers exist on all platforms and linux kernel versions. Try ifdef'ing them out, as e.g. `__NR_getrandom` already is. But better submit a bug report, so they fix their code. –  Sep 29 '20 at 16:20

2 Answers2

2

You seem to be compiling using musl 1.2.0 or later, which has a 64-bit time_t even on 32-bit targets. This means that the 32-bit system calls (gettimeofday, clock_gettime, clock_getres) are not compatible with musl's definition of struct timeval and struct timespec. To protect from accidentally calling those system calls with the wrong types, the corresponding system call constants are not available in this environment.

Florian Weimer
  • 32,022
  • 3
  • 48
  • 92
1

Identifiers starting with __NR_ are non-portable, Linux-kernel-specific names for the constants defining system call numbers. The portable names that user space programs should use, start with SYS_ instead.

GNU libc allows the non-portable names to pass through from the kernel's headers into <sys/syscall.h>; it sounds like musl libc doesn't. Try search-and-replace changing __NR_ to SYS_ throughout this file.

zwol
  • 135,547
  • 38
  • 252
  • 361
  • 1
    Your musl theory sounds reasonable, but what's odd is that there are plenty of other `__NR_`-prefixed constants that it doesn't complain about ([like literally every `__NR_`-prefixed constant here apart from the ones I mentioned](https://github.com/ptitSeb/box86/blob/master/src/emu/x86syscall.c)). What gives? Could musl be missing these? – Newbyte Sep 30 '20 at 13:59
  • I am not super familiar with musl libc. Perhaps it does define some `__NR_` names for compatibility with Linux-specific programs developed against GNU libc, but they are added manually and so it's not an exhaustive set. Perhaps it does pass through `__NR_*` from the kernel's own headers (specifically, `asm/unistd*.h`) but the copies of those headers on the system where you're doing the build are out of date relative to the systems used by the Box86 developers. Perhaps something even stranger is going on. I probably can't help you any further. – zwol Sep 30 '20 at 14:08