Hello. I have successfully built uchardet in my cross environment (build is amd64, host is arm). Now I'm trying to link to it. # cat test.c int main() { return 0; } # arm-unknown-linux-gnueabi-gcc test.c -luchardet /usr/libexec/gcc/arm-unknown-linux-gnueabi/ld: warning: libstdc++.so.6, needed by /usr/arm-unknown-linux-gnueabi/usr/lib/libuchardet.so, not found (try using -rpath or -rpath-link) /usr/arm-unknown-linux-gnueabi/usr/lib/libuchardet.so: undefined reference to `__gxx_personality_v0@CXXABI_1.3' /usr/arm-unknown-linux-gnueabi/usr/lib/libuchardet.so: undefined reference to `vtable for __cxxabiv1::__si_class_type_info@CXXABI_1.3' /usr/arm-unknown-linux-gnueabi/usr/lib/libuchardet.so: undefined reference to `__cxa_pure_virtual@CXXABI_1.3' /usr/arm-unknown-linux-gnueabi/usr/lib/libuchardet.so: undefined reference to `vtable for __cxxabiv1::__class_type_info@CXXABI_1.3' /usr/arm-unknown-linux-gnueabi/usr/lib/libuchardet.so: undefined reference to `operator new(unsigned int)@GLIBCXX_3.4' /usr/arm-unknown-linux-gnueabi/usr/lib/libuchardet.so: undefined reference to `__cxa_end_cleanup@CXXABI_1.3' /usr/arm-unknown-linux-gnueabi/usr/lib/libuchardet.so: undefined reference to `operator delete(void*)@GLIBCXX_3.4' collect2: error: ld returned 1 exit status # arm-unknown-linux-gnueabi-gcc test.c -luchardet -lstdc++ # As you can see without adding -lstdc++ I cannot link to uchardet. This problem affects real applications (e.g. mpv), which rely on linker flags provided by uchardet.pc. But uchardet.pc provides only -luchardet, while -lstdc++ is listed under Libs.private. Is there a sane way to deal with this problem? Thank you. P.S. gcc test.c -luchardet on native system works just fine.
If I am not mistaken, if you have a sane building environment, it should link with only the non-private dependencies (i.e. what is visible in the headers) on the command line. Of course, you still need to have the private dependencies available on your build environment (hence a "sane" environment) but they don't need to be explicitly named in the link command line. The "private" part of the pkg-config is only meant to be used when you build statically (as far as I recall) because then you obviously to link with the full chain of dependencies. So my first assumption is that there is a problem in your cross-build environment and you should check your various path variables (maybe LD_LIBRARY_PATH?). Now I am saying all this from memory of how this all is supposed to work and how all these binaries are meant to fit into each other. Maybe I missed something. And if so, patches welcome.
I need to investigate further whether this is a Gentoo bug after all. Thanks!
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/uchardet/uchardet/issues/1.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.