This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]