no .eh_frame_hdr table will be created #428

Activity

1. DanAlbert commented on Jun 19, 2017

   

   DanAlbert

   on Jun 19, 2017

   Contributor

   More actions

   Unfortunately the linker doesn't provide a very helpful error message here. Googling for it turns up this though: https://gcc.gnu.org/ml/gcc-help/2009-04/msg00223.html

   Presumably bin/libx.o was not compiled by a current version of gcc.
   This error means that the linker did not understanding something in the
   exception frame information. gcc has asked the linker to create an
   exception frame header, but, because there is something wrong, the
   exception frame header will not be created.

   I think everything will still work more or less correctly. The effect
   is that throwing an exception will take longer at runtime.

   Were any components maybe built with an old NDK? It's also possible that maybe the inverse of the problem is happening and the Clang we have is actually too new for our linker...

   One thing that might explain the difference between 32-bit and 64-bit arm here: 64-bit arm still uses ld.bfd instead of ld.gold. If you add -fuse-ld=gold to your ldflags, does the problem go away?

   Note that you won't want to use -fuse-ld=gold for aarch64 in anything you ship right now because of https://groups.google.com/d/topic/android-ndk-announce/u8v7eIegIpM/discussion
2. stolk commented on Jun 19, 2017

   

   stolk

   on Jun 19, 2017

   Author

   More actions

   Thank you for the swift reply.

   The library I try to link (gpg.a) is pre-built and provided by Google. I have no control over the compiler.

   Your analysis was spot on: gold can successfully link.
   I added this to my CMakeLists.txt file:

   set ( CMAKE_SHARED_LINKER_FLAGS "-fuse-ld=gold ${CMAKE_SHARED_LINKER_FLAGS}" )
   

   That said, the resulting app does crash on 64-bit for me.
   Not sure if this is due to the switch to gold linker or not:

   E/ValidateServiceOp( 3257): android.os.DeadObjectException
   E/ValidateServiceOp( 3257): 	at android.os.BinderProxy.transactNative(Native Method)
   E/ValidateServiceOp( 3257): 	at android.os.BinderProxy.transact(Binder.java:505)
   E/ValidateServiceOp( 3257): 	at com.google.android.gms.common.internal.IGmsCallbacks$Stub$Proxy.onPostInitComplete(IGmsCallbacks.java:118)
   

   The 32 bit arm works just fine.
3. DanAlbert commented on Jun 19, 2017

   

   DanAlbert

   on Jun 19, 2017

   Contributor

   More actions

   Oh, Google Play Games, not GNU Privacy Guard :)

   I'm going to refile this in our other bug tracker so it's easier to loop in the Play Games folks. Does this happen for any trivial link of libgpg, or do you have a specific test case?
4. stolk commented on Jun 19, 2017

   

   stolk

   on Jun 19, 2017

   Last edited by stolk

   Author

   More actions

   Thanks, I already had an issue filed with the Google Play Games tracker.
   It is at: playgameservices/cpp-android-basic-samples#48

   I will download their samples, and build on 64-bit to see if those can be used as repro case.
   UPDATE: I can't for the life of me build the samples from cpp-android-basic-samples. I think they have not been maintained to build for current installs of NDK/SDK/AndroidStudio.
5. DanAlbert commented on Jun 19, 2017

   

   DanAlbert

   on Jun 19, 2017

   Contributor

   More actions

   Oh, I didn't realize they were also on GitHub. We'll just use that one then. I'll leave this open until we have a better idea of what the problem is though.
6. DanAlbert commented on Oct 3, 2017

   

   DanAlbert

   on Oct 3, 2017

   Contributor

   More actions

   Closing in favor of the Play Games bug. Will reopen if we have reason to believe this is an NDK issue, but for now we don't.
7. DanAlbert

   closed this as completedon Oct 3, 2017