On Sun, 2011-09-25 at 19:20 +0100, Dave Korn wrote: > On 25/09/2011 18:41, jojelino wrote: > > > The problem is from pango/opentype/libharfbuzz.la > > It has .cc source and recognized as needed c++ source file although it > > is c source. and cc source is compiled with --tag=CXX > > we should teach libtool cc is c source file. > > Or upstream should add an explicit --tag=CC, or rename the file extension. > Good catch, that certainly ties in with what that link I found was saying.
The .cc file is a C++ source file. > Hmm, there are two harfbuzzes, one old, one new; one has .cc files, the > other .cpp files. It appears that they both do actually use C++ features, but > perhaps in a limited way; as long as they don't throw exceptions or use RTTI > or any of the standard C++ library functions, they could not need linking > against libstdc at all. In that case maybe upstream's solution would be to > add "-fno-exceptions -fno-rtti" to the CXXFLAGS and "--tag=CC" to the LDFLAGS. > Don't know which code base the distro package is based on though; let's wait > and see what Yaakov has to say. I believe this is the old harfbuzz, and while it uses C++ language features (and hence automake compiles and links it with CXX), libpangoft2-1.0 (the library in which the embedded harfbuzz is used) shows a runtime dep on libgcc1 but not libstdc++6. That being said, normally -lstdc++ would work since $sys_lib_search_path_spec normally includes gcc's libdir. I'm guessing the problem here is that you're encountering this within gcc itself, which uses a customized libtool. You'll need to check the in-tree libtool in question and if the path to the in-tree libstdc++.la is not in $sys_lib_search_path_spec, then see that it is added. (Now that I think about it, nothing else in gcc links against the target libstdc++.) Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
