Created attachment 162848 [details] Shell script for compiling test-snippet The one-line c++ main function #include <string> template < typename T > int f( T ); int main() { return f( &std::string::c_str ); } should have only one unresolved reference. The clang-compilers available on FreeBSD 10.2 does not instantiate the STL member function. Gcc installed from the ports collections seems to do it correctly. A script compiling the source code shown above is attached. The result is, when trying gcc and different versions of clang compilers: FreeBSD gcc version 5.2.0 (FreeBSD Ports Collection) undefined reference to `int f<char const* ... FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 undefined reference to `std::__1::basic_st ... undefined reference to `int f<char const* ... clang version 3.6.2 (tags/RELEASE_362/final) undefined reference to `std::__1::basic_st ... undefined reference to `int f<char const* ... clang version 3.8.0 undefined reference to `std::__1::basic_st ... undefined reference to `int f<char const* ... This behavior was not experienced when llvm/clang was installed from the source code on a Linux computer ( CentOS 6.2, clang installed as described on the web page https://github.com/rsmmr/install-clang ): Linux gcc version 5.2.0 (GCC) undefined reference to `int f<char const* ... clang version 3.4.1 undefined reference to `int f<char const* ...
Given this appears to be an issue both with clang++ in base and ports, CC both base and ports maintainers of clang. We should create two new issues (one for base, one for ports) and have this issue depend on them, so that they can be tracked/resolved independently and for MFC, MFH purposes.
I am unsure what the actual issue is. What seems to be the problem with having one or two unresolved references? Can you explain this further?
(In reply to Dimitry Andric from comment #2) Forgive me if i didn't grok the issue correctly, but it appears the title of the issue summaries the issue: "does not resolve reference to STL member function" That implies to me that it *should* If that is indeed the case (requires confirmation/validation), what is the impact?
Note also that taking the address of C++ standard library functions is undefined behavior. This program is therefore invalid.
(In reply to Kubilay Kocak from comment #3) > Forgive me if i didn't grok the issue correctly, but it appears the title of > the issue summaries the issue: > > "does not resolve reference to STL member function" > > That implies to me that it *should* Why do you think so? I think the submitter of the bug should explain. I have already explained in comment 4 that taking the address of std::string::c_str is undefined behavior. So there is no "correct" way of handling this. > If that is indeed the case (requires confirmation/validation), what is the > impact? The impact is nil. You should simply not do this. :)
Note 1: for an upstream discussion, see: https://llvm.org/bugs/show_bug.cgi?id=24127 and its duplicate: https://llvm.org/bugs/show_bug.cgi?id=24638 Note 2: the reason that the submitter does not see this on Linux, is that he is using libstdc++ there, which does not define c_str() as a forceinline function.
Switch to more precise resolution
(In reply to Dimitry Andric from comment #6) Thank you for your comments. The unresolved reference problem seems not to be a FreeBSD issue, but shouldn't clang be portable? clang 3.4.1 on Linux does not report the member function as unresolved, using -stdlib=libc++ or -stdlib=libstdc++ does not matter.(In reply to Dimitry Andric from comment #6)
'Fixed' is used for resolutions that resulted in a change (committed)
(In reply to egilb from comment #8) > Thank you for your comments. The unresolved reference problem > seems not to be a FreeBSD issue, but shouldn't clang be portable? Clang is portable, your code is not. > clang 3.4.1 on Linux does not report the member function as unresolved, > using -stdlib=libc++ or -stdlib=libstdc++ does not matter. This would depend entirely on which version of libc++ you are using. IIRC at some point the implementation of std::string::c_str() was made into an inline function, and from that point onward, you cannot take its address anymore.
(In reply to Dimitry Andric from comment #10) Thanks again! I have no problem accepting the source code being non-portable, but I still find it strange that clang behaves differently on two platforms. Compiler flag -stdlib=libc++ adds the decoration __attribute__ ((__visibility__("hidden"), __always_inline__)) to std::string::c_str(), but still no unresolved function when using clang/Linux. Does clang silently link in some gnu library on Linux, or is the behavior due to some configure-options used when installing the compiler?