Bogus dependencies in libtool .la files for libgtk2.0-devel-2.20.1-1, libpango1.0-devel-1.28.1-1

Yaakov (Cygwin/X)
Tue Sep 27 01:55:00 GMT 2011

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/
> > 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 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++.)


Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list