If you set up a test project (called skobblerGoogleMapTest) that has the following Podfile:
source 'https://github.com/CocoaPods/Specs.git'
platform :ios, :deployment_target => '6.0'
pod 'ScoutMaps-iOS-SDK'
pod 'GoogleMaps'
link_with ['skobblerGoogleMapTest']
You will get the following set of link errors:
duplicate symbol ___gl_noBeginData in:
/Users/tomhorn/dev/skobblerGoogleMapTest/Pods/GoogleMaps/Frameworks/GoogleMaps.framework/GoogleMaps(tess.o)
/Users/tomhorn/dev/skobblerGoogleMapTest/Pods/ScoutMaps-iOS-SDK/SKMaps.framework/SKMaps(tess.o)
duplicate symbol ___gl_noEdgeFlagData in:
/Users/tomhorn/dev/skobblerGoogleMapTest/Pods/GoogleMaps/Frameworks/GoogleMaps.framework/GoogleMaps(tess.o)
/Users/tomhorn/dev/skobblerGoogleMapTest/Pods/ScoutMaps-iOS-SDK/SKMaps.framework/SKMaps(tess.o)
duplicate symbol ___gl_noVertexData in:
/Users/tomhorn/dev/skobblerGoogleMapTest/Pods/GoogleMaps/Frameworks/GoogleMaps.framework/GoogleMaps(tess.o)
/Users/tomhorn/dev/skobblerGoogleMapTest/Pods/ScoutMaps-iOS-SDK/SKMaps.framework/SKMaps(tess.o)
duplicate symbol ___gl_noEndData in:
/Users/tomhorn/dev/skobblerGoogleMapTest/Pods/GoogleMaps/Frameworks/GoogleMaps.framework/GoogleMaps(tess.o)
/Users/tomhorn/dev/skobblerGoogleMapTest/Pods/ScoutMaps-iOS-SDK/SKMaps.framework/SKMaps(tess.o)
duplicate symbol ___gl_noErrorData in:
/Users/tomhorn/dev/skobblerGoogleMapTest/Pods/GoogleMaps/Frameworks/GoogleMaps.framework/GoogleMaps(tess.o)
/Users/tomhorn/dev/skobblerGoogleMapTest/Pods/ScoutMaps-iOS-SDK/SKMaps.framework/SKMaps(tess.o)
duplicate symbol ___gl_noCombineData in:
/Users/tomhorn/dev/skobblerGoogleMapTest/Pods/GoogleMaps/Frameworks/GoogleMaps.framework/GoogleMaps(tess.o)
/Users/tomhorn/dev/skobblerGoogleMapTest/Pods/ScoutMaps-iOS-SDK/SKMaps.framework/SKMaps(tess.o)
ld: 6 duplicate symbols for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
So it looks like both ScoutMaps and GoogleMaps are linking to a tess.c which defines these symbols (some kind of GL tessellator callback mechanism? O_o).
I imagine it would be possible for ScoutMaps (or GoogleMaps, though that is less likely ;) ) to define these callbacks with different names?
If someone from ScoutMaps sees this, that would be awesome.
Indeed, using an older version than 1.10.1 - June 2015 of Google Maps SDK will cause this issue. Try with the 1.10.0 version of Google Maps SDK.
Google stopped supporting iOS6, so this line:
platform :ios, :deployment_target => '6.0'
Results in older versions of the libraries being downloaded. Change it to:
platform :ios, :deployment_target => '7.0'
and everything works.
Related
I'm trying to get rust working on android. However, when I try to cross-compile to android I get the following linking error:
$ cargo build --target=arm-linux-androideabi
Compiling <project> v0.1.0 (<project>)
error: linking with `/opt/android-sdk/ndk/23.0.7599858/toolchains/llvm/prebuilt/linux-x86_64/bin/armv7a-linux-androideabi31-clang` failed: exit status: 1
(very long toolchain command from cargo)
ld: error: unable to find library -lgcc
clang-12: error: linker command failed with exit code 1 (use -v to see invocation)
I have installed the ndk and changed the linker in .cargo/config to the android clang linker. I also tried the standalone toolchains with the same result. The guide I used was the following: https://mozilla.github.io/firefox-browser-architecture/experiments/2017-09-21-rust-on-android.html
Cross-compilation does work when using crate-type = ["rlib"] instead of crate-type = ["cdylib"], but I need an .so file not an .rlib file.
In case it's relevant, i'm using Manjaro Linux.
UPDATE:
I found the following pull request: https://github.com/rust-lang/rust/pull/85806 After switching to ndk22 it worked. I havn't tried if the pull request fixes the issue (probably does).
Without switching to an older NDK version, I found using the workaround provided by ssrlive to work for me. Here's their comment:
Fixing build error for NDK 23 and above
find out all the 4 folders containing file libunwind.a, in my PC,
it's
C:\Users\Administrator\AppData\Local\Android\Sdk\ndk\23.1.7779620\toolchains\llvm\prebuilt\windows-x86_64\lib64\clang\12.0.8\lib\linux\x86_64\
and more. create 4 text files named libgcc.a in the same folders
with this contents
INPUT(-lunwind)
reference
link
In macOS, the paths are
~/Library/Android/sdk/ndk/24.0.8215888/toolchains/llvm/prebuilt/darwin-x86_64/lib64/clang/14.0.1/lib/linux/i386/libunwind.a
~/Library/Android/sdk/ndk/24.0.8215888/toolchains/llvm/prebuilt/darwin-x86_64/lib64/clang/14.0.1/lib/linux/arm/libunwind.a
~/Library/Android/sdk/ndk/24.0.8215888/toolchains/llvm/prebuilt/darwin-x86_64/lib64/clang/14.0.1/lib/linux/aarch64/libunwind.a
~/Library/Android/sdk/ndk/24.0.8215888/toolchains/llvm/prebuilt/darwin-x86_64/lib64/clang/14.0.1/lib/linux/x86_64/libunwind.a
In Linux, the paths are
~/Android/Sdk/ndk/24.0.8215888/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/14.0.1/lib/linux/i386/libunwind.a
~/Android/Sdk/ndk/24.0.8215888/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/14.0.1/lib/linux/aarch64/libunwind.a
~/Android/Sdk/ndk/24.0.8215888/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/14.0.1/lib/linux/x86_64/libunwind.a
~/Android/Sdk/ndk/24.0.8215888/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/14.0.1/lib/linux/arm/libunwind.a
In Windows, the paths are
~/AppData/Local/Android/Sdk/ndk/24.0.8215888/toolchains/llvm/prebuilt/windows-x86_64/lib64/clang/14.0.1/lib/linux/aarch64/libunwind.a
~/AppData/Local/Android/Sdk/ndk/24.0.8215888/toolchains/llvm/prebuilt/windows-x86_64/lib64/clang/14.0.1/lib/linux/arm/libunwind.a
~/AppData/Local/Android/Sdk/ndk/24.0.8215888/toolchains/llvm/prebuilt/windows-x86_64/lib64/clang/14.0.1/lib/linux/i386/libunwind.a
~/AppData/Local/Android/Sdk/ndk/24.0.8215888/toolchains/llvm/prebuilt/windows-x86_64/lib64/clang/14.0.1/lib/linux/x86_64/libunwind.a
create file command in Linux/macOS
cat << EOF > libgcc.a
INPUT(-lunwind)
EOF
This is of course extremely brittle and not the "right" solution, but the workaround works fine as of 2022-10-12 with ndk version 25.1.8937393.
while I am building glibc library using yocto project it is giving
error: missing attribute ((constructor)) support??
after adding the coverage flags:
TARGET_CFLAGS += "-fprofile-arcs -ftest-coverage"
TARGET_LDFLAGS += "-lgcov -fprofile-arcs -ftest-coverage"
still, I am getting an error for glibc.
Please find the link of config log file : https://drive.google.com/file/d/14tiQJ8JIFE_tDWt3H9tS8zBBQROcZDNa/view
It is not working even after adding the following line in conf/local.conf :
EXTRA_OECONF = "libc_cv_ctors_header=yes"
Even i tried this
EXTRA_OECONF_append = "libc_cv_ctors_header=yes"
please find the config log file generated during compilation : https://drive.google.com/open?id=1kxTu8pt7h_9ty55OywP9Ilmmp04T61Rr
So, How to resolve this error?
Log file error Point
poky-linux/gcc/i586-poky-linux/8.2.0/ld: /tmp/ccxetEc1.o: in function `_GLOBAL__sub_D_00100_1__start':
conftest.c:(.text.exit+0x40): undefined reference to `__gcov_exit'<br>
collect2: error: ld returned 1 exit status<br>
configure:5682: $? = 1<br>
configure:5702: error: missing __attribute__ ((constructor)) support??
You are trying to build glibc with -fprofile-arcs -ftest-coverage in CFLAGS. That will not work. The errors you see are a result of these incorrect compiler flags.
A profiling glibc requires fairly substantial changes throughout the library and needs to be created by building with --enable-profile (which is not the default).
I had this error while I tried to enable coverage on a C project using a C++ test harness (CppUTest). Build system was handled by CMake.
Compilers and gcov were aligned on the same version (gcc --version, g++ --version and gcov --version gave the same version) but it seems that my build system was generated with a gcc 5 (resulting to an additional included directory by the linker: usr/lib/gcc/x86_64-linux-gnu/5). I clean the build tree and generated it again thanks to CMake which fixed the error.
I am trying to make ZIMPL using MINGW64, but I get the following error:
myname#... MINGW64 ~/scipoptsuite-3.2.1/zimpl-3.3.3
$ make
-> generating library lib/libzimpl-3.3.3.mingw.x86_64.gnu.opt.a
-> linking bin/zimpl-3.3.3.mingw.x86_64.gnu.normal.opt
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible lib/libgmp.a when searching for -lgmp
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible lib\libgmp.a when searching for -lgmp
....
....
....
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lmsvcrt
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile:170: bin/zimpl-3.3.3.mingw.x86_64.gnu.normal.opt] Error 1
In the README of ZIMPL it says:
The most likely reason that you can't compile, is that gmp.h or zlib.h
are not in your include path (-I) or that libgmp.a oder libz.a are not
in your library path (-L).
But I have those files present in C:\msys64\mingw64\include and C:\msys64\mingw64\lib respectively. Isn't this the right location?
My questions:
- What does this error mean?
- What are the right locations for the files mentioned?
- How do I include these files to the right include and library path? Is it -I/mingw64/include and -L/mingw64/lib?
Thank you in advance.
One reason for these error messages might be that your GMP library is built for another architecture than you're trying to link to (32 bit vs 64 bit). Have a look at this question: skipping incompatible... / cannot find
You might also try using a different linker as suggested here: MinGW-W64 linker skipping incompatible files when searching for third-party static libraries
I think the paths you specified are already correct, it's just that the libs there don't work with your binary. If you can go without GMP, I suggest you try compiling ZIMPL with the option GMP=false.
I have a problem with a shared library (Linux) and a program that links against this library but does not find the symbols - although they are there. That's what I have:
A shared library "libetest.so" that is located in /usr/lib. When I do an
readelf -Ws /usr/lib/libetest.so.0
it gives (beside some others) this output:
54: 000052c0 905 FUNC LOCAL DEFAULT 11 ETEST_open_connection
Now I have an application that makes use of ETEST_open_connection(). When I build it with
gcc lib_test.cpp -DENV_LINUX -letest
it fails with a linker error
lib_test.cpp:(.text+0x32): undefined reference to `ETEST_open_connection'
As shown before the symbol is there! Any idea why this fails?
Please try:
gcc -DENV_LINUX -letest lib_test.cpp
This should be the correct argument order.
I am in the middle of integrating UA into my Phonegap/iOS application using the UA Phonegap plugin https://github.com/urbanairship/phonegap-ua-push.
Unfortunately, I can not get it to work. Even the sample project fails to build. The problem is a duplicate symbol during linking. Please note: i did not include any additional headers, libs, etc. I am just trying to build the iOS sample project.
The clashing symbol seems to be rooted in the ASI* (ASIHttpRequest, ASIAuthenticationDialog, etc) library, which has been integrated into UA. Surprisingly, the clashing happens between both UA libs (libUAirship-1.3.2.a and libUAirshipPush-1.3.2.a).
Linker output: ld: duplicate symbol _OBJC_METACLASS_$_UA_ASIAutorotatingViewController in /Users/b/Downloads/urbanairship-phonegap-ua-push-9b7a89b/ios-sample/Airship/libUAirshipPush-1.3.2.a(UA_ASIAuthenticationDialog.o) and /Users/b/Downloads/urbanairship-phonegap-ua-push-9b7a89b/ios-sample/Airship/libUAirship-1.3.2.a(UA_ASIAuthenticationDialog.o) for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
How can this happen?
This issue appeared for me when I add the flag "-ObjC" in my target settings at "Other Linker Flags".
Check it, i need the flag for an another library but if it's not your case...