On 2018-10-01, Stuart Henderson <s...@spacehopper.org> wrote: > This is explicitly linking libstdc++, which breaks aarch64 but is also > wrong on other clang architectures.
Explicitly linking with -lstdc++ is the biggest remaining single cause that breaks ports on aarch64. From my list (last updated at n2k18): devel/ode stdc++ not found graphics/shotwell stdc++ not found japanese/mecab stdc++ not found multimedia/mediainfo stdc++ not found net/castget stdc++ not found productivity/aqbanking stdc++ not found security/softhsm stdc++ not found sysutils/sleuthkit stdc++ not found textproc/link-grammar stdc++ not found x11/nx/opennx stdc++ not found So far I have refrained from attacking this problem because I'm uncertain how to solve it and whether there's a generic solution or if this needs to be done case by case. The general advice is that linking together C and C++ code should use c++(1). However, I think at least some of these ports attempt to build a library from C++ code than can be used in a C project without having to know the library's C++ internals. Saying that everything that uses such a library needs to link with c++(1) is not practical. Do we need a linker command line version of LIBCXX? -- Christian "naddy" Weisgerber na...@mips.inka.de
