ev-compile-cpp-source regression in r14 beta 2 #302

alexcohn · 2017-02-20T14:37:55Z

Description

Same C++ code (boost 1.63's asio/detail/impl/epoll_reactor.ipp) compiles in r13, but fails in r14β2. I could trace the change back to file definitions.mk, scripts ev-compile-cpp-source and her kin. In r13, the _FLAGS end with

-isystem $$(call host-path,$$(SYSROOT_INC)/usr/include) \

While in r14, this has changed to

--sysroot $$(call host-path,$$(SYSROOT_INC)) \
$(SYSROOT_ARCH_INC_ARG) \

Now if we call ndk-build with APP_UNIFIED_HEADERS=true, the compile command ends with

--sysroot <ndk-root>/sysroot -isystem <ndk-root>/sysroot/usr/include/i686-linux-android

and the result is:

<path>/boost/asio/detail/impl/epoll_reactor.ipp: In static member function 'static int boost::asio::detail::epoll_reactor::do_epoll_create()':
<path>/boost/asio/detail/impl/epoll_reactor.ipp:463:39: error: 'epoll_create1' was not declared in this scope
  int fd = epoll_create1(EPOLL_CLOEXEC);

If I use ndk-build with APP_UNIFIED_HEADERS=false, the compile command line does not contain -isystem at all, with equally unpleasant result:

<path>/boost/asio/impl/serial_port_base.ipp: In member function 'boost::system::error_code boost::asio::serial_port_base::baud_rate::store(termios&, boost::system::error_code&) const':
<path>/boost/asio/impl/serial_port_base.ipp:118:3: error: '::cfsetspeed' has not been declared
  ::cfsetspeed(&storage, baud);

Environment Details

NDK Version: 14.0.3675639-beta2.
Build sytem: ndk-build
Host OS: Mac
Compiler: GCC; clang does not provide a workaround for Clang only uses TLS for stack protector on x86 #297
ABI: x86
STL: c++_shared (but switching to gnustl does not resolve the issue)
NDK API level: 14
Device API level: not applicable

The text was updated successfully, but these errors were encountered:

enh · 2017-02-20T17:47:37Z

epoll_create1 and cfsetspeed were both introduced in API level 21, so it's expected that they wouldn't be visible at 14...

alexcohn · 2017-02-20T22:47:36Z

but boost can use cfsetinspeed() instead, if configured correctly. It knows not to use epoll_create1(), too. The fact is that with GCC and r13 compilation succeeds without tuning.

DanAlbert · 2017-02-21T19:12:39Z

https://github.com/boostorg/asio/blob/develop/include/boost/asio/detail/impl/epoll_reactor.ipp#L462

We didn't used to have EPOLL_CLOEXEC. That seems like the wrong way to check if epoll_create1 is available (presumably boost has some "is this function available?" configure mechanism?). imo this is a bug in boost.

https://github.com/boostorg/asio/blob/develop/include/boost/asio/impl/serial_port_base.ipp#L117

The cfsetspeed is used instead of cfsetispeed #if defined(_BSD_SOURCE). This also looks like a fragile feature test. _BSD_SOURCE is the way to tell the C library that you want the extensions hidden by it, not the way for the C library to indicate that it actually has all that functionality.

alexcohn · 2017-02-22T12:59:00Z

@DanAlbert I agree that in both cases boost did not do their best to protect against hostile build environment. They don't have ./configure or other mechanisms to check which functions are available in the libc, and I believe this their conscious approach, and they rely on the toolchain headers to be consistent.

I think that both cases can be safely resolved without changing boost code, and being a regression in the r14 beta, don't justify filing bug reports at https://svn.boost.org/trac/boost/newticket.

Regarding EPOLL_CLOEXEC: I believe that #if __ANDROID_API__ >= 21 in both linux/eventpoll.h and sys/epoll.h will not do any harm to NDK users. Even if presence of #define EPOLL_CLOEXEC O_CLOEXEC is not a strong evidence that epoll_create1() is available, its absence definitely is a strong enough evidence that a workaround epoll_create1() should be used.

As for cfsetspeed(), I believe that NDK r13 compiled our code 'by lucky chance'. It so happens that with -isystem, we get platforms/android-14/arch-x86/usr/include/asm/posix_types.h included, but not toolchains/x86-4.9/prebuilt/darwin-x86_64/lib/gcc/i686-linux-android/4.9.x/include-fixed/asm/posix_types.h, which happens to include platforms/android-14/features.h which defines _BSD_SOURCE.

Now the things get weird. In unified headers, _BSD_SOURCE is not defined, and left to be defined by the user. This is a breaking change from the older behavior, and I am sure some code will not compile anymore. IMHO, this is a legitimate change, but it should be explicitly documented in the changelog.

On the other hand, on Android platform 21 and higher, cfsetspeed() is defined, and boost will be OK with it, regardless whether _BSD_SOURCE is defined or not.

But for platform less than 21, while cfsetspeed() is missing, it is enough to #define cfsetspeed cfsetispeed - anyways the latter is inlined in termios.h. So, to make boost happy again, you can simply add cfsetspeed to android/legacy_termios_inlines.h. It is a breaking change; but it is 'breaking' in the sense that code that did not compile before, will simply compile, and compile correctly. People who introduced their private workarounds for cfsetspeed will need to touch their code, alas.

DanAlbert · 2017-02-22T19:39:52Z

Hiding EPOLL_CLOEXEC does break the case of people adding behavior conditionally via dlsym though. They'd have to define EPOLL_CLOEXEC themselves. That sort of use case is pretty core to the NDK, so I don't think we should break that.

Agreed that the _BSD_SOURCE change should be called out in the release notes. https://android-review.googlesource.com/342472

As for cfsetspeed(), I believe that NDK r13 compiled our code 'by lucky chance'. It so happens that with -isystem, we get platforms/android-14/arch-x86/usr/include/asm/posix_types.h included, but not toolchains/x86-4.9/prebuilt/darwin-x86_64/lib/gcc/i686-linux-android/4.9.x/include-fixed/asm/posix_types.h, which happens to include platforms/android-14/features.h which defines _BSD_SOURCE.

I'm confused about the rest of this though. You're saying that with r13 you didn't have _BSD_SOURCE defined, but now you do? That sounds like it would have the opposite effect; cfsetspeed would only get used by boost if _BSD_SOURCE was defined. Similarly, the fact that the choice is now left to the user should make this work, so I'm not sure why it's breaking. Presumably I've missed something here.

enh · 2017-02-22T20:00:24Z

<linux/eventpoll.h> is a Linux uapi header, not one of ours, so we won't be changing that. going forward the Android platform and NDK unified headers will always have the latest Linux structs and constants, but functions appropriate to the API level you're targeting, so boost's model is just broken there. (it kind of has to be this way since Android API levels don't imply anything about kernel versions.)

(we might want to remove the duplication and have <sys/epoll.h> include <linux/eventpoll.h>; it's mildly awkward because the kernel header has an opaque struct where the real userspace header should have a more helpful one.)

the specific case of missing system call stubs like epoll_create1 should solve itself, hopefully in r15, though, because we can trivially just statically link all the system call stubs.

as for cfsetspeed, i think what the reporter is saying is that with r13 they did have _BSD_SOURCE defined via <features.h>.

changing legacy_termios_inlines.h to match termios.cpp (which, as the reporter says, defines cfsetispeed and cfsetospeed as calls to cfsetspeed) sounds fine to me though, if we assume the legacy inlines live on in r15.

DanAlbert · 2017-02-22T20:34:17Z

as for cfsetspeed, i think what the reporter is saying is that with r13 they did have _BSD_SOURCE defined via <features.h>.

I think I typo'd something in my comment, but now I'm having trouble untangling things. Based on the behavior (boost compiles fine), _BSD_SOURCE would have to not be set.

changing legacy_termios_inlines.h to match termios.cpp (which, as the reporter says, defines cfsetispeed and cfsetospeed as calls to cfsetspeed) sounds fine to me though, if we assume the legacy inlines live on in r15.

Yeah, this is doable. I think boost needs to make some fixes anyway because of the epoll issue though, so I'd rather avoid respinning. I'll go file bugs with boost and see how accommodating they are.

DanAlbert · 2017-02-22T20:46:56Z

https://svn.boost.org/trac/boost/ticket/12863

enh · 2017-02-23T07:26:31Z

https://android-review.googlesource.com/342780 removes the EPOLL_CLOEXEC duplication.

alexcohn · 2017-02-23T08:37:14Z

Hiding EPOLL_CLOEXEC in unified headers for API < 21 cannot, IMHO, break someone's code even if they use dlsym, because this simply reflects the current situation in platform headers.

DanAlbert · 2017-02-23T08:54:10Z

They could syscall(__NR_epoll_create1, EPOLL_CLOEXEC) though.

DanAlbert · 2017-02-23T08:55:43Z

And, actually, that'd probably be the simplest fix for boost.

alexcohn · 2017-02-23T09:03:29Z

The story of _BSD_SOURCE defined or not defined in our file is purely academic. It just happens so that the chain of includes with r14 w/o unified headers includes <features.h> and this causes the wrong side of #if to be compiled.

DanAlbert · 2017-02-23T09:18:49Z

Okay, so yes, I did misunderstand you earlier (you actually said it quite clearly in the OP, but apparently I can't read). It's the APP_UNIFIED_HEADERS=false case where the _BSD_SOURCE problem is an issue. That makes a lot more sense.

I suppose we can fix that the same way we plan to for the unified headers: we'll just add the inline definition to the deprecated headers.

With that fixed you should be able to keep using the old headers if you like, or with a small fixup to boost to use syscall instead of using epoll_create1 directly, unified headers would work too.

alexcohn · 2017-02-23T12:37:24Z

Well I have forged a workaround for cfsetspeed() as soon as I understood where _BSD_SOURCE came from.

I believe that we will not switch to unified headers with r14, but the command-line workaround for epoll_create1() is easy, as well:

APP_CXXFLAGS='"-Depoll_create1(x)=-1; errno=EINVAL"'

By the book, this would be even more precise:

APP_CXXFLAGS='"-Depoll_create1(x)=-1; errno=ENOSYS"'

DanAlbert · 2017-02-23T19:29:57Z

I've uploaded a fix for the old headers so you should be able to remove your workaround when r14 ships: https://android-review.googlesource.com/c/343306/

I believe that we will not switch to unified headers with r14

Any other issues we can help with? We're going to be turning these on by default in r15 unless things go horribly wrong (not sure if you've seen our roadmap before).

Thanks a ton for trying these out early, by the way. It helps a lot.

DanAlbert · 2017-02-23T21:48:22Z

The cfsetspeed fix is in now. The epoll issue will need a fix on the boost side.

Test: make checkbuild # with my versioner-in-build patches Bug: android/ndk#302 Change-Id: Ib00b5dadf23592d101486b4f2188285ec03c9e2a

alexcohn · 2017-02-23T22:18:09Z

I appreciate your quick response times.

I don't know of specific issues with unified headers, but I prefer to make small steps, and testing the result on the real users every time. There exist too many weird devices on this planet, and some require very special shims. I guess we will be ready to switch when we upgrade to r15.

This fixes some issues with using boost's asio (which wrongly assumes _BSD_SOURCE implies that these things are available) following our change from -isystem to --sysroot. Test: Manual, check that we can build when using cfsetspeed on ICS. Bug: android/ndk#302 Change-Id: Iab50221e4864f9a09a8fb00691252170eb6e8d09

This fixes some issues with using boost's asio (which wrongly assumes _BSD_SOURCE implies that these things are available) following our change from -isystem to --sysroot. Test: Manual, check that we can build when using cfsetspeed on ICS. Bug: android/ndk#302 Change-Id: Iab50221e4864f9a09a8fb00691252170eb6e8d09 (cherry picked from commit 3b59037)

Bug: android/ndk#302 Test: builds Change-Id: Ia3074326a128c38f2488e342c028cc030801cfd9

DanAlbert · 2017-03-01T20:49:42Z

FYI, build 3770861 is the one I'm expecting to push to stable later this week. If you're feeling adventurous you can download it now by following https://android.googlesource.com/platform/ndk/+/master/docs/ContinuousBuilds.md

alexcohn · 2017-03-02T13:52:19Z

@DanAlbert I can wait for the official release; I am much more concerned with the patch for Clang x86 stack protection, which is not expected to be available this week.

Test: None, markdown only Bug: android/ndk#302 Change-Id: I0cf5dcea4abe5f719bf77050c3bfcbcae05c8e9a

IgorGanapolsky · 2017-05-11T13:30:54Z

@DanAlbert I tried the continuous build #3996500 from https://android.googlesource.com/platform/ndk/+/master/docs/ContinuousBuilds.md, and it didn't solve the problem. Still getting compilation errors:

Error:(28, 10) 'asm/page.h' file not found
#include <asm/page.h> // http://code.google.com/p/android/issues/detail?id=39983
^~~~~~~~~~~~
1 error generated.
FAILED: /android-ndk-r16-canary/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++ --target=armv5te-none-linux-androideabi --gcc-toolchain=/android-ndk-r16-canary/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64 --sysroot=/android-ndk-r16-canary/sysroot -Dandros_EXPORTS -I../../../../ext-libs/live555/basicusageenvironment/include -I../../../../ext-libs/live555/usageenvironment/include -I../../../../ext-libs/live555/groupsock/include -I../../../../ext-libs/live555/livemedia/include -I../../../../ext-libs/live555/openRTSP/include -I/mobilegroup_shared/boost_shared/android/boost_1_57_0/include -I../../../../ext-libs/cpp_netlib/include -I../../../../ext-libs/openssl/include -I../../../../src/main/jni -I../../../../src/main/jni/Logger -I../../../../src/main/jni/BinaryCIPClient -I../../../../src/main/jni/JSON -I../../../../src/main/jni/JSONSpirit -I../../../../src/main/jni/SettingsManager -I../../../../src/main/jni/SystemManager -I../../../../src/main/jni/AutoDiscovery -I../../../../ext-libs/curl/include -I../../../../ext-libs/iconv/include -I../../../../ext-libs/pjsip/include -I../../../../src/main/jni/andros -I../../../../src/main/jni/SIP -I../../../../src/main/jni/MjpegStreamInterface -I../../../../src/main/jni/MjpegStreamLib -I../../../../src/main/jni/ReservedJoinManager -I../../../../src/main/jni/Utility -I../../../../src/main/jni/VideoStreaming -I../../../../src/main/jni/VideoStreaming/StreamManager -I../../../../src/main/jni/VideoStreaming/StreamManager/H264 -I../../../../src/main/jni/VideoStreaming/Stream/H264 -I../../../../src/main/jni/VideoStreaming/Stream/H264/hls_web_server/src -I../../../../src/main/jni/VideoStreaming/Stream/H264/transport_stream -I../../../../src/main/jni/VideoStreaming/Stream -I../../../../src/main/jni/VideoStreaming/StreamManager/MJPEG -I../../../../src/main/jni/VideoStreaming/Stream/MJPEG -I../../../../src/main/jni/VideoStreaming/PlatformAdapter -I../../../../s
rc/main/jni/VideoStreaming/PlatformAdapter/android -I../../../../src/main/jni/VideoStreaming/UrlProcessor -I../../../../src/main/jni/VideoStreaming/Live555Igor -I../../../../src/main/jni/third_party_app_launch -I../../../../src/main/jni/reserved_joins -I../../../../src/main/jni/reserved_join_handlers -I../../../../src/main/jni/service_manager -I../../../../src/main/jni/bcip_client_ng -isystem /android-ndk-r16-canary/sources/cxx-stl/gnu-libstdc++/4.9/include -isystem /android-ndk-r16-canary/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi/include -isystem /android-ndk-r16-canary/sources/cxx-stl/gnu-libstdc++/4.9/include/backward -isystem /android-ndk-r16-canary/sysroot/usr/include/arm-linux-androideabi -D__ANDROID_API__=16 -g -DANDROID -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -march=armv5te -mtune=xscale -msoft-float -fno-integrated-as -mthumb -Wa,--noexecstack -Wformat -Werror=format-security -std=c++11 -Wno-error=format-security -fexceptions -frtti -DANDROID_H264 -Os -DNDEBUG -fPIC -MD -MT CMakeFiles/andros.dir/src/main/jni/AutoDiscovery/device_discovery_timeout_worker.cpp.o -MF CMakeFiles/andros.dir/src/main/jni/AutoDiscovery/device_discovery_timeout_worker.cpp.o.d -o CMakeFiles/andros.dir/src/main/jni/AutoDiscovery/device_discovery_timeout_worker.cpp.o -c /workspace/cmake2/trunk/jni-code/src/main/jni/AutoDiscovery/device_discovery_timeout_worker.cpp
In file included from /workspace/cmake2/trunk/jni-code/src/main/jni/AutoDiscovery/device_discovery_timeout_worker.cpp:11:
In file included from ../../../../src/main/jni/AutoDiscovery/device_discovery_timeout_worker.h:12:
In file included from /mobilegroup_shared/boost_shared/android/boost_1_57_0/include/boost/thread.hpp:13:
In file included from /boost_shared/android/boost_1_57_0/include/boost/th
read/thread.hpp:12:
In file included from /boost_shared/android/boost_1_57_0/include/boost/thread/thread_only.hpp:17:
/boost_shared/android/boost_1_57_0/include/boost/thread/pthread/thread_data.hpp:28:10: fatal error: 'asm/page.h' file not found
#include <asm/page.h> // http://code.google.com/p/android/issues/detail?id=39983
^~~~~~~~~~~~
1 error generated.
FAILED: /android-ndk-r16-canary/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++ --target=armv5te-none-linux-androideabi --gcc-toolchain=/android-ndk-r16-canary/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64 --sysroot=/android-ndk-r16-canary/sysroot -Dandros_EXPORTS -I../../../../ext-libs/live555/basicusageenvironment/include -I../../../../ext-libs/live555/usageenvironment/include -I../../../../ext-libs/live555/groupsock/include -I../../../../ext-libs/live555/livemedia/include -I../../../../ext-libs/live555/openRTSP/include -I/boost_shared/android/boost_1_57_0/include -I../../../../ext-libs/cpp_netlib/include -I../../../../ext-libs/openssl/include -I../../../../src/main/jni -I../../../../src/main/jni/Logger -I../../../../src/main/jni/BinaryCIPClient -I../../../../src/main/jni/JSON -I../../../../src/main/jni/JSONSpirit -I../../../../src/main/jni/SettingsManager -I../../../../src/main/jni/SystemManager -I../../../../src/main/jni/AutoDiscovery -I../../../../ext-libs/curl/include -I../../../../ext-libs/iconv/include -I../../../../ext-libs/pjsip/include -I../../../../src/main/jni/andros -I../../../../src/main/jni/SIP -I../../../../src/main/jni/MjpegStreamInterface -I../../../../src/main/jni/MjpegStreamLib -I../../../../src/main/jni/ReservedJoinManager -I../../../../src/main/jni/Utility -I../../../../src/main/jni/VideoStreaming -I../../../../src/main/jni/VideoStreaming/StreamManager -I../../../../src/main/jni/VideoStreaming/StreamManager/H264 -I../../../../src/main/jni/VideoStreaming/Stream/H264 -I../../../../src/main/jni/VideoStreaming/Stream/H264/hls_web_server/src -I../../../../src/main/jni/VideoStreaming/Stream/H264/transport_stream -I../../../../src/main/jni/VideoStreaming/Stream -I../../../../src/main/jni/VideoStreaming/StreamManager/MJPEG -I../../../../src/main/jni/VideoStreaming/Stream/MJPEG -I../../../../src/main/jni/VideoStreaming/PlatformAdapter -I../../../../s
rc/main/jni/VideoStreaming/PlatformAdapter/android -I../../../../src/main/jni/VideoStreaming/UrlProcessor -I../../../../src/main/jni/VideoStreaming/Live555Igor -I../../../../src/main/jni/third_party_app_launch -I../../../../src/main/jni/reserved_joins -I../../../../src/main/jni/reserved_join_handlers -I../../../../src/main/jni/service_manager -I../../../../src/main/jni/bcip_client_ng -isystem /android-ndk-r16-canary/sources/cxx-stl/gnu-libstdc++/4.9/include -isystem /android-ndk-r16-canary/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi/include -isystem /android-ndk-r16-canary/sources/cxx-stl/gnu-libstdc++/4.9/include/backward -isystem /android-ndk-r16-canary/sysroot/usr/include/arm-linux-androideabi -D__ANDROID_API__=16 -g -DANDROID -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -march=armv5te -mtune=xscale -msoft-float -fno-integrated-as -mthumb -Wa,--noexecstack -Wformat -Werror=format-security -std=c++11 -Wno-error=format-security -fexceptions -frtti -DANDROID_H264 -Os -DNDEBUG -fPIC -MD -MT CMakeFiles/andros.dir/src/main/jni/AutoDiscovery/cip_sendpacket_worker.cpp.o -MF CMakeFiles/andros.dir/src/main/jni/AutoDiscovery/cip_sendpacket_worker.cpp.o.d -o CMakeFiles/andros.dir/src/main/jni/AutoDiscovery/cip_sendpacket_worker.cpp.o -c /cmake2/trunk/jni-code/src/main/jni/AutoDiscovery/cip_sendpacket_worker.cpp
In file included from /cmake2/trunk/jni-code/src/main/jni/AutoDiscovery/cip_sendpacket_worker.cpp:10:
In file included from ../../../../src/main/jni/AutoDiscovery/cip_sendpacket_worker.h:12:
In file included from /boost_shared/android/boost_1_57_0/include/boost/asio.hpp:21:
In file included from /boost_shared/android/boost_1_57_0/include/boost/asio/basic_datagram_socket.hpp:20:
In file included from /Users/
/android/boost_1_57_0/include/boost/asio/basic_socket.hpp:20:
In file included from /boost_shared/android/boost_1_57_0/include/boost/asio/basic_io_object.hpp:19:
In file included from /boost_shared/android/boost_1_57_0/include/boost/asio/io_service.hpp:767:
In file included from /boost_shared/android/boost_1_57_0/include/boost/asio/impl/io_service.hpp:71:
In file included from /boost_shared/android/boost_1_57_0/include/boost/asio/detail/task_io_service.hpp:198:
In file included from /boost_shared/android/boost_1_57_0/include/boost/asio/detail/impl/task_io_service.ipp:24:
In file included from /boost_shared/android/boost_1_57_0/include/boost/asio/detail/reactor.hpp:21:
In file included from /boost_shared/android/boost_1_57_0/include/boost/asio/detail/epoll_reactor.hpp:239:
/boost_shared/android/boost_1_57_0/include/boost/asio/detail/impl/epoll_reactor.ipp:463:12: error: use of undeclared identifier 'epoll_create1'; did you mean 'epoll_create'?
int fd = epoll_create1(EPOLL_CLOEXEC);
^~~~~~~~~~~~~
epoll_create
/android-ndk-r16-canary/sysroot/usr/include/sys/epoll.h:76:5: note: 'epoll_create' declared here

DanAlbert · 2017-05-11T16:16:31Z

Something has gone wrong with your build.

`#include <asm/page.h> // http://code.google.com/p/android/issues/detail?id=39983

This line doesn't appear anywhere in that build, so one of the projects you're including there is probably the one including asm/page.h (that header doesn't exist any more). I've cases where iptables actually has its own copies of old Linux headers, but that doesn't seem to be here. Possibly something similar though?

IgorGanapolsky · 2017-05-11T16:23:40Z

@DanAlbert Doing a machine wide search located this for me: /android-ndk-r16-canary/platforms/android-14/arch-x86/usr/include/linux - where you can see
#include <asm/a.out.h>

enh · 2017-05-11T16:25:49Z

(looks like current boost says

#if defined(__ANDROID__)
# ifndef PAGE_SIZE
#  define PAGE_SIZE 4096
# endif
#endif

instead: http://www.boost.org/doc/libs/1_64_0/boost/thread/pthread/thread_data.hpp)

DanAlbert · 2017-05-11T16:26:25Z

I see plenty of includes of asm/page.h, but I don't see any that include that bug URL.

$ grep -r 39983 .android-ndk-r16-canary/

Turns up nothing.

The specific header you've pointed at shouldn't be used in your build anyway. Those are the deprecated headers, not the ones that should have this fixed.

enh · 2017-05-11T16:31:13Z

the line with the bug URL was a boost file. but like i said, the current version looks different. so it looks like an out of date boost that won't work with unified headers.

IgorGanapolsky · 2017-05-11T17:04:15Z

That URL is being reported by org.gradle.internal.buildevents.BuildExceptionReporter ninja build system.
Furthermore, tracing back to the build error - I see that the problem is in /boost/universal/include/boost/threadthread_only.hpp where it includes:
#include <boost/thread/pthread/thread_data.hpp>

Anyhow, the solution is to downgrade to Android Studio 2.3.2 and ndk-r13b.

Some third-party code uses the existence of EPOLL_CLOEXEC to detect the availability of epoll_create1. This is not correct, since having up-to-date UAPI headers says nothing about the C library, but for the time being we don't want to harm adoption to the unified headers. We'll undef EPOLL_CLOEXEC if we don't have epoll_create1 for the time being, and maybe revisit this later. Test: make checkbuild Bug: android/ndk#302 Bug: android/ndk#394 Change-Id: I8ee9ce62768fb174070ec51d114f477389befc4a

yan12125 · 2018-01-30T06:16:10Z

Hello, https://android-review.googlesource.com/c/platform/bionic/+/401372 breaks building CPython with NDK r15+ and android-19 (https://bugs.python.org/issue28914). Is there a chance to revert the aforementioned change in r17? I guess after r15 and r16 cycles, most third-party codes have been fixed.

enh · 2018-01-30T06:57:08Z

because of the workaround, no third-party code will have changed: the workaround ensures that they continue to build because they won't see the constants if the function isn't available.

yan12125 · 2018-01-30T07:31:30Z

Thanks I guess you're right. I'll go back to CPython for a fix.

enh · 2018-01-30T16:00:55Z

python/cpython@b8d9032 (using configure to detect epoll_create1) looks like the right fix.

We did actually change the unified headers to not expose constants before the corresponding functions are available (at least in the epoll/inotify cases that caused trouble, plus sync_file_range which we spotted in passing). Bug: android/ndk#302 Bug: android/ndk#394 Test: N/A Change-Id: Ia46b56862475f68a8ae3fa3677532c828eec390c

This is a partial https://android-review.googlesource.com/c/343952/. We shipped this in r14, but r15 beta 1 is shipping the O preview headers, which is older than this change. Test: ndk/checkbuild.py && ndk/validate.py Bug: android/ndk#302 Change-Id: Icbc8693bcdead9195bf8a74978a9a684048ef5a9 (cherry picked from commit 8af1f77ac680bba3535e83d2b06208e82230a81c)

Bug: android/ndk#302 Test: builds Change-Id: Ia3074326a128c38f2488e342c028cc030801cfd9

Bug: android/ndk#302 (comment) Test: builds Change-Id: Ia3074326a128c38f2488e342c028cc030801cfd9

Bug: android/ndk#302 Test: builds Change-Id: Ia3074326a128c38f2488e342c028cc030801cfd9

DanAlbert added this to the r14 milestone Feb 23, 2017

DanAlbert self-assigned this Feb 23, 2017

DanAlbert closed this as completed Feb 23, 2017

hubot pushed a commit to aosp-mirror/platform_bionic that referenced this issue Feb 23, 2017

Add legacy inlines for more termios stuff.

4473e34

Test: make checkbuild # with my versioner-in-build patches Bug: android/ndk#302 Change-Id: Ib00b5dadf23592d101486b4f2188285ec03c9e2a

hubot pushed a commit to aosp-mirror/platform_bionic that referenced this issue Feb 24, 2017

Use <linux/eventpoll.h> to implement <sys/epoll.h>.

893fd97

Bug: android/ndk#302 Test: builds Change-Id: Ia3074326a128c38f2488e342c028cc030801cfd9

DanAlbert mentioned this issue Mar 20, 2017

Unified Headers: pthread_barrier_t defined when __ANDROID_API__ < 24 #336

Closed

a252539783 pushed a commit to a252539783/aosp-platform-ndk that referenced this issue May 3, 2017

Add a note about _BSD_SOURCE behavior changing.

e855d0f

Test: None, markdown only Bug: android/ndk#302 Change-Id: I0cf5dcea4abe5f719bf77050c3bfcbcae05c8e9a

DanAlbert mentioned this issue May 11, 2017

boost_1_57 no longer compiles with CMake 3.6.3155560 #392

Closed

alexcohn mentioned this issue May 16, 2017

Undefined reference to syscalls in r15 #394

Closed

DanAlbert mentioned this issue May 16, 2017

fix building boost with unified headers #395

Closed

DanAlbert mentioned this issue May 23, 2017

r15 beta2 openMP #401

Closed

kokje mentioned this issue Feb 16, 2018

dlsym crashes in Android API < 21 tokio-rs/mio#820

Closed

sepehrst pushed a commit to spsforks/android-bionic-libc that referenced this issue Apr 22, 2024

Use <linux/eventpoll.h> to implement <sys/epoll.h>.

b3a2bac

Bug: android/ndk#302 Test: builds Change-Id: Ia3074326a128c38f2488e342c028cc030801cfd9

sepehrst pushed a commit to spsforks/android-bionic-libc that referenced this issue Apr 22, 2024

Use <linux/eventpoll.h> to implement <sys/epoll.h>.

f697809

Bug: android/ndk#302 Test: builds Change-Id: Ia3074326a128c38f2488e342c028cc030801cfd9

sepehrst pushed a commit to spsforks/android-bionic-libc that referenced this issue Apr 22, 2024

Use <linux/eventpoll.h> to implement <sys/epoll.h>.

03c6769

Bug: android/ndk#302 (comment) Test: builds Change-Id: Ia3074326a128c38f2488e342c028cc030801cfd9

sepehrst pushed a commit to spsforks/android-bionic-libc that referenced this issue Apr 22, 2024

Use <linux/eventpoll.h> to implement <sys/epoll.h>.

57fc8c8

Bug: android/ndk#302 Test: builds Change-Id: Ia3074326a128c38f2488e342c028cc030801cfd9

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ev-compile-cpp-source regression in r14 beta 2 #302

ev-compile-cpp-source regression in r14 beta 2 #302

alexcohn commented Feb 20, 2017 •

edited

Loading

enh commented Feb 20, 2017

alexcohn commented Feb 20, 2017

DanAlbert commented Feb 21, 2017

alexcohn commented Feb 22, 2017 •

edited

Loading

DanAlbert commented Feb 22, 2017

enh commented Feb 22, 2017

DanAlbert commented Feb 22, 2017

DanAlbert commented Feb 22, 2017

enh commented Feb 23, 2017

alexcohn commented Feb 23, 2017

DanAlbert commented Feb 23, 2017

DanAlbert commented Feb 23, 2017

alexcohn commented Feb 23, 2017

DanAlbert commented Feb 23, 2017

alexcohn commented Feb 23, 2017 •

edited

Loading

DanAlbert commented Feb 23, 2017

DanAlbert commented Feb 23, 2017

alexcohn commented Feb 23, 2017

DanAlbert commented Mar 1, 2017

alexcohn commented Mar 2, 2017

IgorGanapolsky commented May 11, 2017

DanAlbert commented May 11, 2017

IgorGanapolsky commented May 11, 2017

enh commented May 11, 2017 •

edited by DanAlbert

Loading

DanAlbert commented May 11, 2017

enh commented May 11, 2017

IgorGanapolsky commented May 11, 2017 •

edited

Loading

yan12125 commented Jan 30, 2018

enh commented Jan 30, 2018

yan12125 commented Jan 30, 2018

enh commented Jan 30, 2018

ev-compile-cpp-source regression in r14 beta 2 #302

ev-compile-cpp-source regression in r14 beta 2 #302

Comments

alexcohn commented Feb 20, 2017 • edited Loading

Description

Environment Details

enh commented Feb 20, 2017

alexcohn commented Feb 20, 2017

DanAlbert commented Feb 21, 2017

alexcohn commented Feb 22, 2017 • edited Loading

DanAlbert commented Feb 22, 2017

enh commented Feb 22, 2017

DanAlbert commented Feb 22, 2017

DanAlbert commented Feb 22, 2017

enh commented Feb 23, 2017

alexcohn commented Feb 23, 2017

DanAlbert commented Feb 23, 2017

DanAlbert commented Feb 23, 2017

alexcohn commented Feb 23, 2017

DanAlbert commented Feb 23, 2017

alexcohn commented Feb 23, 2017 • edited Loading

DanAlbert commented Feb 23, 2017

DanAlbert commented Feb 23, 2017

alexcohn commented Feb 23, 2017

DanAlbert commented Mar 1, 2017

alexcohn commented Mar 2, 2017

IgorGanapolsky commented May 11, 2017

DanAlbert commented May 11, 2017

IgorGanapolsky commented May 11, 2017

enh commented May 11, 2017 • edited by DanAlbert Loading

DanAlbert commented May 11, 2017

enh commented May 11, 2017

IgorGanapolsky commented May 11, 2017 • edited Loading

yan12125 commented Jan 30, 2018

enh commented Jan 30, 2018

yan12125 commented Jan 30, 2018

enh commented Jan 30, 2018

alexcohn commented Feb 20, 2017 •

edited

Loading

alexcohn commented Feb 22, 2017 •

edited

Loading

alexcohn commented Feb 23, 2017 •

edited

Loading

enh commented May 11, 2017 •

edited by DanAlbert

Loading

IgorGanapolsky commented May 11, 2017 •

edited

Loading