3 ms·
This sounds like Android NDK development will get quite painful in a few years. It previously included a botched libc++ missing a bunch of features. This is lib
by m0zg 7y ago
This sounds like Android NDK development will get quite painful in a few years. It previously included a botched libc++ missing a bunch of features. This is libc, but I imagine subtle feature disparities and incompatibilities there will cause plenty of pain as well.
- uep 7y agoThere are already some real pain points with bionic. I primarily write Linux code that sometimes has to run on Android (notably not any other UNIX). I've run into tons of problems porting to old versions of bionic, despite the kernel being the same.
- mrpippy 7y agoI don’t think the Android team is the interested party here, given the original poster’s interest only in x86_64
- m0zg 7y agoGoogle doesn't do "only x86_64". Even when I was there (years ago) at a minimum all software had to run on PowerPC as well, and non-portable assembly/intrinsics required explicit approval from "Eng Elders" and a portable fallback. I wouldn't be surprised if ARM compat is also required now.
- saagarjha 7y agoThat might be true, but the email posted here explicitly lists x86_64 as the architecture they are targeting initially.
- jdswain 7y agoIn my experience NDK development is quite painful now. Most of my NDK work is a little old now but I found the debugging process quite painful. This was for C++ code that was running on other platforms so almost all of the debugging was due to platform incompatibilities or bugs. But I did notice in the linked article that they are only targeting x86_64, so I don't think this libc is targeted at Android.
- pjmlp 7y agoAndroid NDK development was been quite painful since ever, to the point sometimes I miss Symbian, and Symbian C++ patterns were not to fall in love with. Not sure about you, but for me it was felt like a 20% project that someone on the Android team does something when they happen to be free of work. If it wasn't for JetBrains coming up with CLion we still wouldn't have a replacement for Eclipse CDT, multiple reboots of NDK build tools, no real story on how to share libraries between NDK projects, native APIs are C wrappers to C++ code that we wrap again in C++ for proper type safety, permissions or file access require JNI, no AndroidX/JetPack like libraries and the list goes on. The IO talk was more of state of nation than anything else. Apple and Microsoft platforms are definitly more C++ developer friendly regarding the overall tooling, and mixed language development support as well.