Closed Bug 1091377 Opened 5 years ago Closed 5 years ago

Android NDK r10c build failure: error: undefined reference to '__futex_wake'

Categories

(Core :: General, defect)

ARM
Android
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla37

People

(Reporter: dougc, Assigned: glandium)

Details

(Whiteboard: [ndk-r10c])

Attachments

(1 file)

Seeing this build failure building with NDK r10c, gcc 4.9. It fails linking libmozglue.so with:

bionic/libstdc++/src/one_time_construction.cpp:49: error: undefined reference to '__futex_wake'
bionic/libstdc++/src/one_time_construction.cpp:43: error: undefined reference to '__futex_wake'
It also fails using gcc 4.8, so it does not appear to be a gcc 4.9 issue.
Whiteboard: [ndk-r10c]
it looks like a libstdc++/libc.so problem in the NDK itself...
$ readelf -s android-ndk-r8e/platforms/android-9/arch-arm/usr/lib/libstdc++.a | grep futex_wake 
    31: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __futex_wake
$ readelf -s android-ndk-r8e/platforms/android-9/arch-arm/usr/lib/libc.so | grep futex_wake
    64: 00008ab0    20 FUNC    GLOBAL DEFAULT    4 __futex_wake
    65: 00008ac4    20 FUNC    GLOBAL DEFAULT    4 __futex_wake_ex
    68: 00008ab0    20 FUNC    GLOBAL DEFAULT    4 __futex_wake
    69: 00008ac4    20 FUNC    GLOBAL DEFAULT    4 __futex_wake_ex


$ readelf -s android-ndk-r10c/platforms/android-9/arch-arm/usr/lib/libstdc++.a | grep futex_wake
    31: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __futex_wake
$ readelf -s android-ndk-r10c/platforms/android-9/arch-arm/usr/lib/libc.so | grep futex_wake
    64: 000086d8    20 FUNC    GLOBAL DEFAULT    4 __futex_wake_ex
    68: 000086d8    20 FUNC    GLOBAL DEFAULT    4 __futex_wake_ex
So, they essentially broke android version 9 libraries.

Fortunately, the version 21 ones are not broken

$ readelf -s android-ndk-r10c/platforms/android-21/arch-arm/usr/lib/libstdc++.a | grep futex_wake
     7: 00000001    44 FUNC    LOCAL  DEFAULT    4 __futex_wake.constprop.1
$ readelf -s android-ndk-r10c/platforms/android-21/arch-arm/usr/lib/libc.so | grep futex_wake
This problem persists with r10d. Mike, can we add a workaround? I looked at it some, but it's not enough to add something to BionicGlue.cpp, as we use libstdc++ for a bunch other small libs (test plugins, etc). What's a convenient place to put the shim? All we need is this:

#include <sys/syscall.h>
#include <linux/futex.h>
#include <errno.h>

extern "C" int
__futex_wake(volatile void *ftx, int count)
{
  int saved_errno = errno;
  int result = syscall(__NR_futex, ftx, FUTEX_WAKE, count, NULL);
  if (__builtin_expect(result == -1, 0)) {
    result = -errno;
    errno = saved_errno;
  }
  return result;
}
Flags: needinfo?(mh+mozilla)
I'm not particularly thrilled by adding shims that are only required because the fake libraries in the NDK are broken. The shims we currently have are there because actual libraries on actual devices can be broken. That's a different problem space.

So the first question I'll ask is whether there is actually a need to support building with r10* with android-9?
Flags: needinfo?(mh+mozilla)
(In reply to Mike Hommey [:glandium] from comment #6)

> So the first question I'll ask is whether there is actually a need to
> support building with r10* with android-9?

I imagine we'll eventually need to build with r10*; a skim of my bugmail looks like we end up bumping the NDK version once every six months or so, due to the need for newer compiler versions or other compatibility issues.

I doubt we'll stop supporting API 9 by the next time we need to upgrade (regrettably so), so perhaps a narrower question is whether we are able to, or want to, support multiple NDK versions on builders.

That's not a question I can answer, but I think that if the answer is no, then we should prepare for the eventuality.

Otherwise, we're betting that we won't have a need to upgrade until we stop shipping API 9.
So, I was about to file the NDK issue "upstream", so I tried reproducing with the NDK build environment to increase the chances of it being considered a bug. It turns out -static-libstdc++ is not one of the many STL build options you get when using ndk-build. Now, looking back at bug 850332, bug 861973 and bug 850576, it seems to me we may actually not need -static-libstdc++ anymore. And building with the dummy shared libstdc++ that comes from the NDK seems to work with r10*. From a look at the resulting libmozglue.so, it looks like it should be fine, although I haven't looked at a complete build.

If you want to test if the build goes through on your end, just remove -static-libstdc++ from build/stlport/moz.build. I'll further check whether this is something that would actually work for all our builds.
(In reply to Richard Newman [:rnewman] from comment #7)
> I doubt we'll stop supporting API 9 by the next time we need to upgrade
> (regrettably so), so perhaps a narrower question is whether we are able to,
> or want to, support multiple NDK versions on builders.

FWIW, mobile/android/config/tooltool-manifests/android*/releng.manifest allow to use different NDKs for armv7, armv6 and x86 builds.
Assignee: nobody → mh+mozilla
Attachment #8545082 - Flags: review?(mshal)
Attachment #8545082 - Flags: review?(mshal) → review+
https://hg.mozilla.org/mozilla-central/rev/18557b56adbe
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
You need to log in before you can comment on or make changes to this bug.