Julia fails to build on arm64 due to missing __NR_epoll_wait

[petercolberg]

Dear Julia maintainers,

I am forwarding Debian bug #807701:

On Fri, Dec 11, 2015 at 06:36:09PM +0000, Edmund Grimley Evans wrote:

It failed to build on arm64:

https://buildd.debian.org/status/package.php?p=julia&suite=sid

The error was:

signal (6): Aborted
gsignal at /lib/aarch64-linux-gnu/libc.so.6 (unknown line)
Aborted

The problem seems to be that there is no system call epoll_wait on
arm64, only epoll_pwait, so you need a patch like this:

The issue had already been fixed in libuv/libuv@1d8332f, which calls either uv__epoll_wait
or uv__epoll_pwait, depending on availability [libuv/libuv#308].

What is the current status of migrating Julia to upstream libuv?

Switching sooner than later would help avoid duplicate work such as in this case.

Regards,
Peter

[tkelman]

What is the current status of migrating Julia to upstream libuv?

See #12266 for updating to a more recently rebased branch. That's currently broken on Windows due to upstream changes.

As far as directly using upstream libuv without any local changes, that requires more extensive changes similar to joyent/libuv#451 to be upstreamed.

[yuyichao]

This is not 0.4 specific. I've just hit this on master too (which works pretty well otherwise, apart from some threading related functions).

The workaround I used was,

diff --git a/src/unix/linux-syscalls.c b/src/unix/linux-syscalls.c
index 1ff8abd..1266aac 100644
--- a/src/unix/linux-syscalls.c
+++ b/src/unix/linux-syscalls.c
@@ -263,7 +263,7 @@ int uv__eventfd(unsigned int count) {
 #if defined(__NR_eventfd)
   return syscall(__NR_eventfd, count);
 #else
-  return errno = ENOSYS, -1;
+  return uv__eventfd2(count, 0);
 #endif
 }

@@ -281,7 +281,7 @@ int uv__epoll_create(int size) {
 #if defined(__NR_epoll_create)
   return syscall(__NR_epoll_create, size);
 #else
-  return errno = ENOSYS, -1;
+  return uv__epoll_create1(0);
 #endif
 }

@@ -311,7 +311,7 @@ int uv__epoll_wait(int epfd,
 #if defined(__NR_epoll_wait)
   return syscall(__NR_epoll_wait, epfd, events, nevents, timeout);
 #else
-  return errno = ENOSYS, -1;
+  return uv__epoll_pwait(epfd, events, nevents, timeout, NULL);
 #endif
 }

@@ -339,7 +339,7 @@ int uv__inotify_init(void) {
 #if defined(__NR_inotify_init)
   return syscall(__NR_inotify_init);
 #else
-  return errno = ENOSYS, -1;
+  return uv__inotify_init1(0);
 #endif
 }

which is a simpler way of "falling back" to new syscall's if the deprecated ones are not available (or not even implemented).

What's the status of #12266? Should I submit (in a PR) this to our fork for now before we figure out how to upgrade to a newer libuv?

[tkelman]

Would rather use a solution more directly cherry-picked from upstream if possible, so it becomes reduntant at the next rebase. We've had a handful of more recent commits on our fork that should probably be pulled in to the next rebase.

[yuyichao]

The issue is that the upstream have changed a lot before fixing this issue.

The commit mentioned above (libuv/libuv@1d8332f) isn't actually the commit that fixes the issue. It was only a fix of a regression that is introduced when fixing another regression of this fallback logic.

The signature of uv__epoll_pwait (the one we need to fallback to) is also changed compare to our fork.

An imcomplete list of commits that we need to backport is (not tested and not in the order they should be applied).

libuv/libuv@1d8332f
libuv/libuv@67bb2b5
libuv/libuv@861de3d
libuv/libuv@2daf944
libuv/libuv@751ac48

At this point I think it is cleaner to either move to a new version (which is why I'd like to know the status of #12266) or applying a simpler downstream patch that we can just throw away when we upgrade.

(The commit list is assuming we want to stick with upstream commits without much modification of them. Otherwise, it's not so different from adding our own commits.)

[yuyichao]

Hmm. Having a closer look. Fortunately, it seems that the fallback is added before the signature of uv__epoll_pwait is changed so we can probably just backport libuv/libuv@861de3d without dealing with other changes or regression due to other additional features. I (or someone else) need to check if it actually works when I'm home later today.

[tkelman]

As I said 2 weeks ago, the status of upgrading libuv is that it's still broken on Windows. Don't think that has changed.