Android libc++ namespace change__1 in m74

3,327 views
Skip to first unread message

Bozhidar Varbanov

unread,
Mar 26, 2019, 5:51:47 AM3/26/19
to discuss-webrtc
I am trying to build WebRtc m74 and link with my own c++ project.
In m74 libwebrtc.a all libc++ objects are in namespace __1 - for example : std::__1::unique_ptr
in WebRtc v72 all libc++ objects are in std::__ndk1::unique_ptr

So the namespace of built libc++ has been changed from __ndk1 to __1
I cannot link anymore my Android C++ against libwebrtc.a .

Is it possible to change build of WebRTC m74 so that it uses explicit only libc++ from recent NDK and all namespaces are same ?

Attached in my attempt to build WebRTC using NDK 19, but still resulting in std::__1:: namespace


go.sh

Philip Davis

unread,
Mar 26, 2019, 6:59:35 PM3/26/19
to discuss-webrtc
It's also broken on Windows. Everything was peachy before but now I'm getting dozens of linker errors that look like this:

error LNK2001: unresolved external symbol "public: __cdecl std::__1::basic_string<char,struct std::__1::char_traits<char>,class std::__1::allocator<char> >::~basic_string<char,struct std::__1::char_traits<char>,class std::__1::allocator<char> >(void)" (??1?$basic_string@DU?$char_traits@D@__1@std@@V?$allocator@D@23@@__1@std@@QEAA@XZ)
1>

Surlogics Surlogics

unread,
Apr 11, 2019, 2:15:17 AM4/11/19
to discuss-webrtc
Same problem, any solutions?

在 2019年3月26日星期二 UTC+8下午5:51:47,Bozhidar Varbanov写道:

mbon...@webrtc.org

unread,
Apr 11, 2019, 2:38:34 AM4/11/19
to discuss-webrtc
The problem seems similar to the one on this other thread: https://groups.google.com/d/msg/discuss-webrtc/6s1Tk99Z9Pw/4Gs-9VVZAgAJ. I am not sure the solution posted there works, though.

kyle.robe...@gmail.com

unread,
Apr 12, 2019, 1:07:26 AM4/12/19
to discuss-webrtc

I have this exact same problem building libwebrtc for Android. I just dumped each of the libwebrtc.a libraries (one for m74, one for v72) with nm; then searched on ‘__1’ and ‘__ndk1’.


__1 in v72 found 36 times

__ndk1 in v72 found 17678 times

__1 in m74 found 28057 times

__ndk1 in m74 found 0 times


So, this merely confirms what you saw. M73 is also broken for me.

kyle.robe...@gmail.com

unread,
Apr 12, 2019, 1:07:26 AM4/12/19
to discuss-webrtc

I am having exactly the same problem as Bozhidar, with libwebrtc.a built for Android. When I use build-heads/m74, commit 884fb24, all the STL calls are in namespace std::__1, so when I link to my Android app, they are not found. In my environment the STL calls are in __ndk1 namespace; e.g., std::__ndk1::string. Our build.gradle has this:


externalNativeBuild {
    cmake {
        cppFlags "-std=c++14"
        arguments "-DANDROID_STL=c++_shared"
    }
}

The gn gen call is plain vanilla: gn gen out/debug-001 --args='target_os="android" target_cpu="arm64"'. I tried using use_custom_libcxx=false – this had no effect.


Now, when I built with build-heads/72, the linker problem goes away. So yeah, it looks like something changed between 72 and m73. I tried m73, too – same problem as with m74.


I’ve built for Linux (built on Linux, as I do for the Android version), which works fine linking in Linux application. I’ve also built libwebrtc.a for iOS (on Mac OSX) – there I had kind of the reverse problem, as we use gnu STL (libstdc++, instead of clang). The solution was, I added use_custom_libcxx=false to the gn parameters, and Xcode was happy. This is not an option for the Android build of libwebrtc.a (nor should it be…)



Message has been deleted

kyle.robe...@gmail.com

unread,
Apr 12, 2019, 7:20:23 AM4/12/19
to discuss-webrtc
>> I tried using use_custom_libcxx=false – this had no effect.

I meant, I tried using libcxx_abi_unstable=false -- this had no effect.  use_custom_libcxx is not supported for the Android build.


Tops luo

unread,
Apr 18, 2019, 8:07:03 AM4/18/19
to discuss-webrtc
I have the same problem. How do you solve it?

在 2019年4月12日星期五 UTC+8下午7:20:23,kyle.rob...@gmail.com写道:

kyle.robe...@gmail.com

unread,
Apr 18, 2019, 11:37:21 AM4/18/19
to discuss-webrtc
It's not yet solved, but I am further towards a solution. I decided to examine the actual build command for a single .cc file, comparing two branches.  I used branch-head/72 for the good branch (it uses std::__ndk1 STL namespace), and master for the bad branch (using std::__1, just like m73 & m74).  After building both in separate build folders, I touched modules/audio_mixer/audio_mixer_impl/audio_mixer_impl.cc (just a random cc file that has uses STL).  I ran ninja in verbose mode, via: ninja -v -C out/release-arm64

// build audio_mixer_impl.cc for v72:
../../third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF obj/modules/audio_mixer/audio_mixer_impl/audio_mixer_impl.o.d -DV8_DEPRECATION_WARNINGS -DNO_TCMALLOC -DSAFE_BROWSING_DB_REMOTE -DCHROMIUM_BUILD -DFIELDTRIAL_TESTING_ENABLED -D_GNU_SOURCE -DANDROID -DHAVE_SYS_UIO_H -DANDROID_NDK_VERSION_ROLL=r16_1 -DCR_CLANG_REVISION=\"346388-1\" -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D_FORTIFY_SOURCE=2 -D__GNU_SOURCE=1 -DCHROMIUM_CXX_TWEAK_INLINES -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DWEBRTC_ENABLE_PROTOBUF=1 -DWEBRTC_INCLUDE_INTERNAL_AUDIO_DEVICE -DRTC_ENABLE_VP9 -DHAVE_SCTP -DUSE_BUILTIN_SW_CODECS -DWEBRTC_ARCH_ARM64 -DWEBRTC_HAS_NEON -DWEBRTC_APM_DEBUG_DUMP=0 -DWEBRTC_LIBRARY_IMPL -DWEBRTC_NON_STATIC_TRACE_EVENT_HANDLERS=1 -DWEBRTC_POSIX -DWEBRTC_LINUX -DWEBRTC_ANDROID -DABSL_ALLOCATOR_NOTHROW=1 -I../.. -Igen -I../../third_party/abseil-cpp -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -funwind-tables -fPIC -fcolor-diagnostics -fmerge-all-constants -Xclang -mllvm -Xclang -instcombine-lower-dbg-declare=0 -no-canonical-prefixes -ffunction-sections -fno-short-enums --target=aarch64-linux-android -isystem../../third_party/android_ndk/sysroot/usr/include/aarch64-linux-android -D__ANDROID_API__=21 -Wall -Werror -Wextra -Wimplicit-fallthrough -Wthread-safety -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-unneeded-internal-declaration -Wno-undefined-var-template -Wno-null-pointer-arithmetic -Wno-ignored-pragma-optimize -Oz -fno-ident -fdata-sections -ffunction-sections -fno-omit-frame-pointer -g1 -fdebug-info-for-profiling -fvisibility=hidden -Xclang -load -Xclang ../../third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.so -Xclang -add-plugin -Xclang find-bad-constructs -Xclang -plugin-arg-find-bad-constructs -Xclang enforce-in-thirdparty-webkit -Xclang -plugin-arg-find-bad-constructs -Xclang check-enum-max-value -Xclang -plugin-arg-find-bad-constructs -Xclang check-ipc -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -Wexit-time-destructors -Wglobal-constructors -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wc++11-narrowing -Wimplicit-fallthrough -Wthread-safety -Winconsistent-missing-override -Wundef -Wunused-lambda-capture -Wno-shorten-64-to-32 -std=c++14 -fno-exceptions -fno-rtti --sysroot=../../third_party/android_ndk/sysroot -nostdinc++ -isystem../../third_party/android_ndk/sources/cxx-stl/llvm-libc++/include -isystem../../third_party/android_ndk/sources/cxx-stl/llvm-libc++abi/include -isystem../../third_party/android_ndk/sources/android/support/include -fvisibility-inlines-hidden -Wnon-virtual-dtor -Woverloaded-virtual -c ../../modules/audio_mixer/audio_mixer_impl.cc -o obj/modules/audio_mixer/audio_mixer_impl/audio_mixer_impl.o

// build audio_mixer_impl.cc for master:
../../third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF obj/modules/audio_mixer/audio_mixer_impl/audio_mixer_impl.o.d -DNO_TCMALLOC -DSAFE_BROWSING_DB_REMOTE -DCHROMIUM_BUILD -D_GNU_SOURCE -DANDROID -DHAVE_SYS_UIO_H -DANDROID_NDK_VERSION_ROLL=r16_1 -DCR_CLANG_REVISION=\"357692-1\" -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D_FORTIFY_SOURCE=2 -D_LIBCPP_ABI_UNSTABLE -D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS -D_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS -D_LIBCPP_ENABLE_NODISCARD -DCR_LIBCXX_REVISION=358423 -D__GNU_SOURCE=1 -DCHROMIUM_CXX_TWEAK_INLINES -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DWEBRTC_ENABLE_PROTOBUF=1 -DWEBRTC_INCLUDE_INTERNAL_AUDIO_DEVICE -DRTC_ENABLE_VP9 -DHAVE_SCTP -DWEBRTC_ARCH_ARM64 -DWEBRTC_HAS_NEON -DWEBRTC_APM_DEBUG_DUMP=0 -DWEBRTC_LIBRARY_IMPL -DWEBRTC_NON_STATIC_TRACE_EVENT_HANDLERS=1 -DWEBRTC_POSIX -DWEBRTC_LINUX -DWEBRTC_ANDROID -DABSL_ALLOCATOR_NOTHROW=1 -I../.. -Igen -I../../third_party/abseil-cpp -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -funwind-tables -fPIC -fcolor-diagnostics -fmerge-all-constants -fcrash-diagnostics-dir=../../tools/clang/crashreports -Xclang -mllvm -Xclang -instcombine-lower-dbg-declare=0 -fcomplete-member-pointers -ffunction-sections -fno-short-enums --target=aarch64-linux-android -isystem../../third_party/android_ndk/sysroot/usr/include/aarch64-linux-android -D__ANDROID_API__=21 -mno-outline -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -Xclang -fdebug-compilation-dir -Xclang . -no-canonical-prefixes -Wall -Werror -Wextra -Wimplicit-fallthrough -Wthread-safety -Wextra-semi -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-unneeded-internal-declaration -Wno-undefined-var-template -Wno-ignored-pragma-optimize -Oz -fno-ident -fdata-sections -ffunction-sections -fno-omit-frame-pointer -g1 -fdebug-info-for-profiling -fvisibility=hidden -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -Wexit-time-destructors -Wglobal-constructors -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wc++11-narrowing -Wimplicit-fallthrough -Wthread-safety -Winconsistent-missing-override -Wundef -Wunused-lambda-capture -Wno-shorten-64-to-32 -std=c++14 -fno-exceptions -fno-rtti -nostdinc++ -isystem../../buildtools/third_party/libc++/trunk/include -isystem../../buildtools/third_party/libc++abi/trunk/include --sysroot=../../third_party/android_ndk/sysroot -isystem../../third_party/android_ndk/sources/android/support/include -fvisibility-inlines-hidden -Wnon-virtual-dtor -Woverloaded-virtual -c ../../modules/audio_mixer/audio_mixer_impl.cc -o obj/modules/audio_mixer/audio_mixer_impl/audio_mixer_impl.o

DELTAS

These flags were in the v72 command line build, and not in the master build:
-DV8_DEPRECATION_WARNINGS
-DFIELDTRIAL_TESTING_ENABLED
-DCR_CLANG_REVISION=\"346388-1\"
-DUSE_BUILTIN_SW_CODECS
-no-canonical-prefixes
-Wno-null-pointer-arithmetic
-Xclang -load
-Xclang ../../third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.so
-Xclang -add-plugin
-Xclang find-bad-constructs
-Xclang -plugin-arg-find-bad-constructs
-Xclang enforce-in-thirdparty-webkit
-Xclang -plugin-arg-find-bad-constructs
-Xclang check-enum-max-value
-Xclang -plugin-arg-find-bad-constructs
-Xclang check-ipc
-isystem../../third_party/android_ndk/sources/cxx-stl/llvm-libc++/include
-isystem../../third_party/android_ndk/sources/cxx-stl/llvm-libc++abi/include 

These were in master build, and not v72:
-DCR_CLANG_REVISION=\"357692-1\"
-D_LIBCPP_ABI_UNSTABLE
-D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
-D_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS
-D_LIBCPP_ENABLE_NODISCARD
-DCR_LIBCXX_REVISION=358423
-fcrash-diagnostics-dir=../../tools/clang/crashreports
-fcomplete-member-pointers
-mno-outline
-Xclang -fdebug-compilation-dir
-Xclang . -no-canonical-prefixes
-Wextra-semi
-fdata-sections
-isystem../../buildtools/third_party/libc++/trunk/include
-isystem../../buildtools/third_party/libc++abi/trunk/include 

Immediately suspicious were the last two lines.  Those include files are not coming from the NDK, as in v72.

When I enter out/release-arm64, I can copy the build line and build a single object file.  When I replace the -isystem flags in the master build command with those from v72, the build does work.  And the resulting object file (audio_mixer_impl.o) does indeed have the desired STL namespace (std::__ndk1).  I use this to check:

 nm -C obj/modules/audio_mixer/audio_mixer_impl/audio_mixer_impl.o

I just have to figure out now how to get the build flags setup correctly with the BUILD.gn and .gni files.  And of course, see if the resulting libwebrtc.a works with the Android NDK.

Tops luo

unread,
Apr 19, 2019, 6:11:53 AM4/19/19
to discuss-webrtc
Tks,it seems to be a 'cflags_cc' parameter setting problem, but I don't know how to set it.

在 2019年4月18日星期四 UTC+8下午11:37:21,kyle.rob...@gmail.com写道:

Peng YU

unread,
May 30, 2019, 2:32:11 AM5/30/19
to discuss-webrtc
I have exact same problem, anyone can supply a solution to switch the namespace?

gu ablert

unread,
May 30, 2019, 2:49:42 AM5/30/19
to discuss-webrtc
I've met this same issue.  Really have no idea to resolve it. 

I tried to hard code the namespace in "buildtools/third_party/libc++/trunk/include/__config" from "__" to "__ndk". It can resolve the compile issue, but it crashes when calling JNI APIs.

在 2019年5月30日星期四 UTC+8下午2:32:11,Peng YU写道:

Albert Gu

unread,
Jul 23, 2019, 5:05:09 AM7/23/19
to discuss-webrtc
I've figured out a solution for this issue. Hope it can help you guys.

You just need to update the following 2 files:
src/build/config/android/BUILD.gn
src/build/config/c++/c++.gni

The updated files are attached. Enjoy it!
c++.gni
BUILD.gn
Message has been deleted
Message has been deleted

Piasy Xu

unread,
Sep 11, 2019, 4:27:30 AM9/11/19
to discuss-webrtc
The solution Albert Gu gives doesn't work for me on arm build, but woks on arm64 build.

I figure out a simpler solution.

At first, this error is caused by the using of in-tree libc++, so disable using in-tree libc++ should fix it, which could be achieved by editing `src/build/config/c++/c++.gni`, change this assignment of `use_custom_libcxx` in the `declare_args` block, remove the `|| is_android` from it.

But by doing so, the compile would fail with error: 

In file included from ../../third_party/android_tools_mac/ndk/sources/android/support/include/math.h:32:

../../third_party/llvm-build/Release+Asserts/bin/../include/c++/v1/math.h:1330:93: error: no member named 'log2f' in the global namespace

inline _LIBCPP_INLINE_VISIBILITY float       log2(float __lcpp_x) _NOEXCEPT       {return ::log2f(__lcpp_x);}


To resolve this compile error, we need edit `src/build/config/android/BUILD.gn`, in the `config("runtime_library")` block, it need to be something like below:

config("runtime_library") {
  # NOTE: The libc++ header include paths below are specified in cflags_cc
  # rather than include_dirs because they need to come after include_dirs.
  # Think of them like system headers, but don't use '-isystem' because the
  # arm-linux-androideabi-4.4.3 toolchain (circa Gingerbread) will exhibit
  # strange errors. The include ordering here is important; change with
  # caution.
  cflags_cc = []
  if (!use_custom_libcxx) {
    if (android_ndk_major_version >= 13) {
      libcxx_include_path =
          rebase_path("$android_libcpp_root/include", root_build_dir)
      libcxxabi_include_path = rebase_path(
              "$android_ndk_root/sources/cxx-stl/llvm-libc++abi/include",
              root_build_dir)
    } else {
      libcxx_include_path =
          rebase_path("$android_libcpp_root/libcxx/include", root_build_dir)
      libcxxabi_include_path = rebase_path(
              "$android_ndk_root/sources/cxx-stl/llvm-libc++abi/libcxxabi/include",
              root_build_dir)
    }
    cflags_cc += [
      "-nostdinc++",
      "-isystem" + libcxx_include_path,
      "-isystem" + libcxxabi_include_path,
    ]
  }
  cflags_cc += [ "-isystem" + rebase_path(
                     "$android_ndk_root/sources/android/support/include",
                     root_build_dir) ]

  defines = [
    "__GNU_SOURCE=1",  # Necessary for clone().
    "CHROMIUM_CXX_TWEAK_INLINES",  # Saves binary size.
  ]
  ldflags = [ "-nostdlib" ]
  lib_dirs = [ android_libcpp_lib_dir ]

  libs = []
  if (!use_custom_libcxx) {
    # The libc++ runtime library (must come first).
    # ASan needs to dynamically link to libc++ even in static builds so
    # that it can interpose operator new.
    if (is_component_build || is_asan) {
      libs += [ "c++_shared" ]
    } else {
      libs += [ "c++_static" ]
    }
    libs += [ "c++abi" ]
  }
  libs += [ "android_support" ]

...
}



在 2019年7月23日星期二 UTC+8下午5:05:09,Albert Gu写道:

Björn St

unread,
Sep 18, 2019, 2:48:50 AM9/18/19
to discuss-webrtc
Is there any update on this blocking issue? I also have my own c++ project where I link to libwebrtc.a.

It has worked previously but after trying to update to M76 and now M78 I get the same linking error as described.

Is it supposed to be like this?

If I want to link against the libwebrtc.a what is the correct solution, trying to get Webrtc to build the namespace with “__ndk1” or getting my project to use “__1”?

Please assist me!

Albert Gu

unread,
Sep 18, 2019, 3:09:34 AM9/18/19
to discuss-webrtc
Hi Björn,

Did you get chance to try the solution I posted above.  If I remember correct, this issue was introduced in m73 and I fixed this issue in upgrading WebRTC to m74.

Regards,
Albert Gu

Björn St

unread,
Sep 18, 2019, 3:43:52 AM9/18/19
to discuss-webrtc
Hi Albert

Thank you for your response and for posting your solution earlier.

I did try it on M76, by replacing the files with your files. But I got that a lot of variables where missing, I added them manually in the Build.gn file but in the end the "gn gen" couldn't run without errors.

But I will give it a second go, trying to see what your fix where compared to the original files for M74 and see if I can apply it for M78.

Still I would like to know if there is any official solution or statement from the Webrtc-team about how to use the libwebrtc.a with Android, after it breaking in M74.

Best Regard
Björn

Albert Gu

unread,
Sep 18, 2019, 4:23:30 AM9/18/19
to discuss-webrtc
Hi Björn,

To be honest, I didn't try my solution on m76.

>> But I will give it a second go, trying to see what your fix where compared to the original files for M74 and see if I can apply it for M78.

This sounds good. And if you figure out a new solution/patch you can share it here as well.

>> Still I would like to know if there is any official solution or statement from the Webrtc-team about how to use the libwebrtc.a with Android, after it breaking in M74.

Unfortunately, I have found any official statement regarding the solution.  And I don't think Google would like us to consume the C++ APIs directly, especially the lower level ones. Because you'll have to expose them by yourself by configuring relevant files.

-
Best Regards,
Albert Gu



From: discuss...@googlegroups.com <discuss...@googlegroups.com> on behalf of Björn St <bj...@ingate.com>
Sent: Wednesday, September 18, 2019 3:43 PM
To: discuss-webrtc <discuss...@googlegroups.com>
Subject: [discuss-webrtc] Re: Android libc++ namespace change__1 in m74
 
--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/o-zDdrq09yk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/ee9ddddd-a5dd-4825-8a15-b4af37c74115%40googlegroups.com.

Albert Gu

unread,
Sep 18, 2019, 4:27:49 AM9/18/19
to discuss-webrtc
Sorry, there was a typo. Unfortunately, I have NOT found any official statement regarding the solution.


On Wednesday, September 18, 2019 at 4:23:30 PM UTC+8, Albert Gu wrote:
Hi Björn,

To be honest, I didn't try my solution on m76.

>> But I will give it a second go, trying to see what your fix where compared to the original files for M74 and see if I can apply it for M78.

This sounds good. And if you figure out a new solution/patch you can share it here as well.

>> Still I would like to know if there is any official solution or statement from the Webrtc-team about how to use the libwebrtc.a with Android, after it breaking in M74.

Unfortunately, I have found any official statement regarding the solution.  And I don't think Google would like us to consume the C++ APIs directly, especially the lower level ones. Because you'll have to expose them by yourself by configuring relevant files.

-
Best Regards,
Albert Gu




Sent: Wednesday, September 18, 2019 3:43 PM
To: discuss-webrtc <discuss-webrtc@googlegroups.com>

Subject: [discuss-webrtc] Re: Android libc++ namespace change__1 in m74
Hi Albert

Thank you for your response and for posting your solution earlier.

I did try it on M76, by replacing the files with your files. But I got that a lot of variables where missing, I added them manually in the Build.gn file but in the end the "gn gen" couldn't run without errors.

But I will give it a second go, trying to see what your fix where compared to the original files for M74 and see if I can apply it for M78.

Still I would like to know if there is any official solution or statement from the Webrtc-team about how to use the libwebrtc.a with Android, after it breaking in M74.

Best Regard
Björn


Den onsdag 18 september 2019 kl. 09:09:34 UTC+2 skrev Albert Gu:
Hi Björn,

Did you get chance to try the solution I posted above.  If I remember correct, this issue was introduced in m73 and I fixed this issue in upgrading WebRTC to m74.

Regards,
Albert Gu

On Wednesday, September 18, 2019 at 2:48:50 PM UTC+8, Björn St wrote:
Is there any update on this blocking issue? I also have my own c++ project where I link to libwebrtc.a.

It has worked previously but after trying to update to M76 and now M78 I get the same linking error as described.

Is it supposed to be like this?

If I want to link against the libwebrtc.a what is the correct solution, trying to get Webrtc to build the namespace with “__ndk1” or getting my project to use “__1”?

Please assist me!

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/o-zDdrq09yk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

Crossle Song

unread,
May 6, 2020, 9:04:52 AM5/6/20
to discuss-webrtc
Any solution for the latest webrtc m83?


On Tuesday, March 26, 2019 at 5:51:47 PM UTC+8, Bozhidar Varbanov wrote:

Crossle Song

unread,
May 6, 2020, 11:20:19 AM5/6/20
to discuss-webrtc
 on m83 link libwebrtc.a  error undefined reference to `std::__1::__libcpp_debug_function'

Björn St

unread,
Jul 3, 2020, 10:11:15 AM7/3/20
to discuss-webrtc
It works for me to build a fatlib (libwebrtc.a) om M83 and link separately when having  use_custom_libcxx=false'

gn gen out/1 --args='target_os="android" target_cpu="arm" is_debug=true rtc_include_tests=false is_component_build=false use_rtti=true use_custom_libcxx=false'

Alex Vella

unread,
Apr 18, 2021, 4:31:02 AM4/18/21
to discuss-webrtc
Not sure if this will be of use, but I recently needed to change the namespace __ndk1 to __1 to link to a newer libc++.
I was using clang-11 and found that the namespace is set within the file "include/c++/v1/__config.h". It is defined as _LIBCPP_ABI_NAMESPACE and I easily just added -D_LIBCPP_ABI_NAMESPACE=__1  to my CFLAGS to override the old __ndk1 namespace.

Yaowen Guo

unread,
May 11, 2021, 4:04:42 AM5/11/21
to discuss-webrtc
Thanks
I use use_custom_libcxx=false  to build M79. all std::__1 bacome to atd::__ndk1. then libwebrtc.a can't be linked to android lib.

Yaowen Guo

unread,
May 11, 2021, 4:04:46 AM5/11/21
to discuss-webrtc
It work for me! I use use_custom_libcxx=false to build M79. all std::__1 become to std::__ndk1. And then it can be linked into android lib.
I use this:
gn gen out/arm64 --args='target_os="android" target_cpu="arm64" use_custom_libcxx=false'
ninja -C out/arm64/ webrtc

this static is  out/arm64/obj/libwebrtc.a

On Friday, April 12, 2019 at 7:20:23 PM UTC+8 kyle.robe...@gmail.com wrote:
Reply all
Reply to author
Forward
0 new messages