Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
alexcohn opened this issue Feb 20, 2017 · 31 comments
Closed

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

alexcohn opened this issue Feb 20, 2017 · 31 comments
Assignees
Milestone

Comments

@alexcohn
Copy link

@alexcohn alexcohn commented Feb 20, 2017

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 #297
  • ABI: x86
  • STL: c++_shared (but switching to gnustl does not resolve the issue)
  • NDK API level: 14
  • Device API level: not applicable
@enh

This comment has been minimized.

Copy link
Contributor

@enh enh commented Feb 20, 2017

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

@alexcohn

This comment has been minimized.

Copy link
Author

@alexcohn alexcohn commented Feb 20, 2017

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

This comment has been minimized.

Copy link
Member

@DanAlbert DanAlbert commented Feb 21, 2017

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

This comment has been minimized.

Copy link
Author

@alexcohn alexcohn commented Feb 22, 2017

@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

This comment has been minimized.

Copy link
Member

@DanAlbert DanAlbert commented Feb 22, 2017

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

This comment has been minimized.

Copy link
Contributor

@enh enh commented Feb 22, 2017

<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

This comment has been minimized.

Copy link
Member

@DanAlbert DanAlbert commented Feb 22, 2017

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

This comment has been minimized.

Copy link
Member

@DanAlbert DanAlbert commented Feb 22, 2017

@enh

This comment has been minimized.

Copy link
Contributor

@enh enh commented Feb 23, 2017

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

@alexcohn

This comment has been minimized.

Copy link
Author

@alexcohn alexcohn commented Feb 23, 2017

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

This comment has been minimized.

Copy link
Member

@DanAlbert DanAlbert commented Feb 23, 2017

They could syscall(__NR_epoll_create1, EPOLL_CLOEXEC) though.

@DanAlbert

This comment has been minimized.

Copy link
Member

@DanAlbert DanAlbert commented Feb 23, 2017

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

@alexcohn

This comment has been minimized.

Copy link
Author

@alexcohn alexcohn commented Feb 23, 2017

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

This comment has been minimized.

Copy link
Member

@DanAlbert DanAlbert commented Feb 23, 2017

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.

@DanAlbert DanAlbert added this to the r14 milestone Feb 23, 2017
@DanAlbert DanAlbert self-assigned this Feb 23, 2017
@alexcohn

This comment has been minimized.

Copy link
Author

@alexcohn alexcohn commented Feb 23, 2017

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

This comment has been minimized.

Copy link
Member

@DanAlbert DanAlbert commented Feb 23, 2017

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

This comment has been minimized.

Copy link
Member

@DanAlbert DanAlbert commented Feb 23, 2017

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

@DanAlbert DanAlbert closed this Feb 23, 2017
hubot pushed a commit to aosp-mirror/platform_bionic that referenced this issue Feb 23, 2017
Test: make checkbuild # with my versioner-in-build patches
Bug: android/ndk#302
Change-Id: Ib00b5dadf23592d101486b4f2188285ec03c9e2a
@alexcohn

This comment has been minimized.

Copy link
Author

@alexcohn alexcohn commented Feb 23, 2017

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.

hubot pushed a commit to aosp-mirror/platform_development that referenced this issue Feb 23, 2017
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
hubot pushed a commit to aosp-mirror/platform_development that referenced this issue Feb 23, 2017
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)
hubot pushed a commit to aosp-mirror/platform_bionic that referenced this issue Feb 24, 2017
Bug: android/ndk#302
Test: builds
Change-Id: Ia3074326a128c38f2488e342c028cc030801cfd9
@DanAlbert

This comment has been minimized.

Copy link
Member

@DanAlbert DanAlbert commented Mar 1, 2017

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

This comment has been minimized.

Copy link
Author

@alexcohn alexcohn commented Mar 2, 2017

@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.

a252539783 pushed a commit to a252539783/aosp-platform-ndk that referenced this issue May 3, 2017
Test: None, markdown only
Bug: android/ndk#302
Change-Id: I0cf5dcea4abe5f719bf77050c3bfcbcae05c8e9a
@IgorGanapolsky

This comment has been minimized.

Copy link

@IgorGanapolsky IgorGanapolsky commented May 11, 2017

@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

This comment has been minimized.

Copy link
Member

@DanAlbert DanAlbert commented May 11, 2017

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

This comment has been minimized.

Copy link

@IgorGanapolsky IgorGanapolsky commented May 11, 2017

@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

This comment has been minimized.

Copy link
Contributor

@enh enh commented May 11, 2017

(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

This comment has been minimized.

Copy link
Member

@DanAlbert DanAlbert commented May 11, 2017

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

This comment has been minimized.

Copy link
Contributor

@enh enh commented May 11, 2017

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

This comment has been minimized.

Copy link

@IgorGanapolsky IgorGanapolsky commented May 11, 2017

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.

hubot pushed a commit to aosp-mirror/platform_bionic that referenced this issue May 23, 2017
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

This comment has been minimized.

Copy link

@yan12125 yan12125 commented Jan 30, 2018

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

This comment has been minimized.

Copy link
Contributor

@enh enh commented Jan 30, 2018

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

This comment has been minimized.

Copy link

@yan12125 yan12125 commented Jan 30, 2018

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

@enh

This comment has been minimized.

Copy link
Contributor

@enh enh commented Jan 30, 2018

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

miodragdinic pushed a commit to MIPS/ndk that referenced this issue Apr 17, 2018
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
miodragdinic pushed a commit to MIPS/prebuilts-ndk that referenced this issue Apr 17, 2018
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.