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

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

[Dave Korn]

    Hi list,

  Not sure if this counts as a packaging issue so I'm sending it here first.
The problem I'm having is that the above-mentioned libraries all have
libstdc++ ('-lstdc++' to be precise) listed as a dependent lib in the .la
files that are generated by libtool during compilation (and subsequently
installed into /usr/lib):

> /usr/lib/libgdk-x11-2.0.la:dependency_libs=' /usr/lib/libpangocairo-1.0.la
> -L/usr/lib /usr/lib/libpangoft2-1.0.la -lstdc++ /usr/lib/libpango-1.0.la
> /usr/lib/libXinerama.la /usr/lib/libXi.la /usr/lib/libXrandr.la
> /usr/lib/libXcursor.la /usr/lib/libXcomposite.la /usr/lib/libXext.la
> /usr/lib/libXdamage.la /usr/lib/libXfixes.la /usr/lib/libcairo.la
> /usr/lib/libpixman-1.la /usr/lib/libfontconfig.la /usr/lib/libexpat.la
> /usr/lib/libfreetype.la /usr/lib/libglitz.la -lpng12
> /usr/lib/libxcb-render-util.la /usr/lib/libXrender.la
> /usr/lib/libxcb-render.la /usr/lib/libX11.la /usr/lib/libxcb.la
> /usr/lib/libXau.la /usr/lib/libXdmcp.la /usr/lib/libgdk_pixbuf-2.0.la
> /usr/lib/libgio-2.0.la -lz /usr/lib/libgobject-2.0.la
> /usr/lib/libgmodule-2.0.la /usr/lib/libgthread-2.0.la
> /usr/lib/libglib-2.0.la /usr/lib/libpcre.la /usr/lib/libintl.la
> /usr/lib/libiconv.la'
> 
> /usr/lib/libpangocairo-1.0.la:dependency_libs=' -L/usr/lib
> /usr/lib/libcairo.la /usr/lib/libpixman-1.la /usr/lib/libglitz.la -lpng12
> /usr/lib/libxcb-render-util.la /usr/lib/libXrender.la
> /usr/lib/libxcb-render.la /usr/lib/libX11.la /usr/lib/libxcb.la
> /usr/lib/libXau.la /usr/lib/libXdmcp.la /usr/lib/libpangoft2-1.0.la
> /usr/lib/libgobject-2.0.la /usr/lib/libgthread-2.0.la
> /usr/lib/libgmodule-2.0.la /usr/lib/libglib-2.0.la /usr/lib/libintl.la
> /usr/lib/libiconv.la -lstdc++ /usr/lib/libpango-1.0.la
> /usr/lib/libgobject-2.0.la /usr/lib/libgthread-2.0.la
> /usr/lib/libgmodule-2.0.la /usr/lib/libglib-2.0.la /usr/lib/libpcre.la
> /usr/lib/libintl.la /usr/lib/libfontconfig.la /usr/lib/libexpat.la
> /usr/lib/libfreetype.la -lz /usr/lib/libiconv.la'
> 
> /usr/lib/libpangoft2-1.0.la:dependency_libs=' /usr/lib/libgobject-2.0.la
> -L/usr/lib /usr/lib/libgthread-2.0.la /usr/lib/libgmodule-2.0.la
> /usr/lib/libglib-2.0.la /usr/lib/libintl.la /usr/lib/libiconv.la -lstdc++
> /usr/lib/libpango-1.0.la /usr/lib/libgobject-2.0.la
> /usr/lib/libgthread-2.0.la /usr/lib/libgmodule-2.0.la
> /usr/lib/libglib-2.0.la /usr/lib/libpcre.la /usr/lib/libintl.la
> /usr/lib/libfontconfig.la /usr/lib/libexpat.la /usr/lib/libfreetype.la -lz
> /usr/lib/libiconv.la'

  None of the generated DLLs (or their dependencies) actually need libstdc, as
far as I can see they're all plain C:-

> $ cygcheck -v /usr/bin/cyg{gdk-x11-2.0,pangocairo-1.0,pangoft2-1.0}* | grep -i
> stdc
> 
> $

  These apparently bogus dependencies cause problems for automake however, and
specifically for me when trying to build libgtkpeer from gcj/libjava.  Because
libgtkpeer is built entirely from .c files, automake infers the language to be
C and so adds the "--tag=CC" option to the libtool invocation when attempting
to link libgtkpeer.la, but this causes an error, because libtool now can't
find the -lstdc++ dependency:

> libtool: link: rm -fr  .libs/libgtkpeer.a .libs/libgtkpeer.dll.a .libs/libgtkpeer.la .libs/libgtkpeer.lai
> 
> *** Warning: linker path does not have real file for library -lstdc++.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have
> *** because I did check the linker path looking for a file starting
> *** with libstdc++ and none of the candidates passed a file format test
> *** using a file magic. Last file checked: /usr/lib/libpng12.dll.a
> 
> *** Warning: libtool could not satisfy all declared inter-library
> *** dependencies of module libgtkpeer.  Therefore, libtool will create
> *** a static module, that should work as long as the dlopening
> *** application is linked with the -dlopen flag.
> libtool: link: /usr/i686-pc-cygwin/bin/ar rc .libs/libgtkpeer.a  gnu_java_awt_peer_gtk_CairoSurface.o 

  For the next gcc release I'm just going to add a note to the README that
you'll have to run

  sed -i -e 's/-lstdc++//' \
    /usr/lib/lib{gdk-x11-2.0,pangocairo-1.0,pangoft2-1.0}*.la

before you can compile it from source, and that it might be worth backing up
the .la files just in case this -lstdc++ actually is required somewhere, but
I'd be happier if this could either be fixed in the distro, or if someone
could tell me why these libs think they need to link against libstdc++?

    cheers,
      DaveK


--
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

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

[Dave Korn]

On 25/09/2011 15:51, Dave Korn wrote:

> I'd be happier if this could either be fixed in the distro, or if someone
> could tell me why these libs think they need to link against libstdc++?

  It seems I'm not the first to have run into this problem:

http://lists.freedesktop.org/archives/cairo/2009-August/017924.html

  It may be that some configure options to libpangocairo would enable Qt and
hence require libstdc, but the dependency gets added regardless of how it is
configured?

    cheers,
      DaveK


--
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

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

[jojelino]

On 2011-09-25 PM 11:51, Dave Korn wrote:
> before you can compile it from source, and that it might be worth backing up
> the .la files just in case this -lstdc++ actually is required somewhere, but
> I'd be happier if this could either be fixed in the distro, or if someone
> could tell me why these libs think they need to link against libstdc++?
>
>      cheers,
>        DaveK
>
>

lstdc++ is included in postdeps in libtool for some reason.

postdeps="-lstdc++ -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname 
-lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingwthrd 
-lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt"

this postdeps was introduced by
output_verbose_link_cmd='$CC -shared $CFLAGS -v conftest.$objext 2>&1 | 
$GREP -v "^Configured with:" | $GREP "\-L"'

but in config.status,
postdeps=''
postdeps_CXX='-lstdc++ -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname 
-lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingwthrd 
-lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt'
so it seems good.
therefore, this problem began from *executing libtool commands*.
the variable 'postdeps' is not tagged with "_CXX". resulting in 
wrong-generated libtool


--
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

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

[jojelino]

On 2011-09-25 PM 11:51, Dave Korn wrote:
> before you can compile it from source, and that it might be worth backing up
> the .la files just in case this -lstdc++ actually is required somewhere, but
> I'd be happier if this could either be fixed in the distro, or if someone
> could tell me why these libs think they need to link against libstdc++?
>
>      cheers,
>        DaveK
>
>

This problem comes from *executing libtool commands*
You can see in config.status of pango

$ cat config.status|grep postdeps
postdeps=''
postdeps_CXX='-lstdc++ -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname 
-lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingwthrd 
-lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt'

rm ./libtool
./config.status #we can see *executing libtool commands*. and libtool is 
auto-generated.
and now resulting libtool has ill-tagged postdeps variable

$ cat libtool|grep postdeps
postdeps=""
       # don't eliminate duplications in $postdeps and $predeps
       libs="$predeps $libs $compiler_lib_search_path $postdeps"
       # $postdeps and mark them as special (i.e., whose duplicates are
         for pre_post_dep in $predeps $postdeps; do
               case " $predeps $postdeps " in
         case " $predeps $postdeps $compiler_lib_search_path " in
                   case " $predeps $postdeps " in
                     case " $predeps $postdeps " in
                 case " $predeps $postdeps " in
                 case " $predeps $postdeps " in
             for i in $predeps $postdeps ; do
postdeps="-lstdc++ -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname 
-lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingwthrd 
-lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt"


Why we got postdeps instead of postdeps_CXX?

Regards.


--
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

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

[Dave Korn]

On 25/09/2011 16:42, jojelino wrote:

> lstdc++ is included in postdeps in libtool for some reason.
> 
> postdeps="-lstdc++ -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname
> -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingwthrd
> -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt"
> 
> this postdeps was introduced by
> output_verbose_link_cmd='$CC -shared $CFLAGS -v conftest.$objext 2>&1 |
> $GREP -v "^Configured with:" | $GREP "\-L"'
> 
> but in config.status,
> postdeps=''
> postdeps_CXX='-lstdc++ -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname
> -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingwthrd
> -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt'
> so it seems good.
> therefore, this problem began from *executing libtool commands*.
> the variable 'postdeps' is not tagged with "_CXX". resulting in
> wrong-generated libtool

  I think this is just libtool working normally; $postdeps is the current
dependencies for this particular invocation, and internally it's doing
something like "postdeps=${postdeps_${tag}}" so it's setting
postdeps=$postdeps_CXX in response to getting --tag=CXX on the command-line,
isn't it?  The underlying cause is more likely to be in the way that the
Makefile.am is setting the libtool control variables, which is probably an
issue for upstream.

  (And of course this doesn't show up on Linux, where the linker doesn't
complain about a dynamic library not being found because it can just leave
undefined reference in the final executable to be resolved by ld.so at
runtime.  But as soon as you try it on a PE rather than ELF platform...)

    cheers,
      DaveK

--
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

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

[Dave Korn]

[ Fixed dup in subject line! ]

On 25/09/2011 16:47, jojelino wrote:

> Why we got postdeps instead of postdeps_CXX?

  My answer to that crossed in the ether with this post, I'll just make one
further point explicit:

> This problem comes from *executing libtool commands*

  If a problem arises from executing libtool commands, that usually means that
something the user did in Makefile.am has tricked automake into generating
incorrect libtool commands in the first place, rather than that an actual
libtool bug has just appeared.  (Libtool bugs are possible of course, but user
errors in automake scripts are more common.)

    cheers,
      DaveK


--
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

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

[jojelino]

On 2011-09-26 AM 12:57, Dave Korn wrote:
>    I think this is just libtool working normally; $postdeps is the current
> dependencies for this particular invocation, and internally it's doing
> something like "postdeps=${postdeps_${tag}}" so it's setting
> postdeps=$postdeps_CXX in response to getting --tag=CXX on the command-line,
> isn't it?  The underlying cause is more likely to be in the way that the
> Makefile.am is setting the libtool control variables, which is probably an
> issue for upstream.

On 25/09/2011 16:42, jojelino wrote:
The latter mail has detail(former one was cancelled but i was already 
late). the auto-generated libtool doesn't seem to clobber postdeps for 
tag specified. then postdeps would be latter one which should have been 
postdeps_CXX.



--
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

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

[jojelino]

On 2011-09-26 AM 1:00, Dave Korn wrote:
>> This problem comes from *executing libtool commands*
>
>    If a problem arises from executing libtool commands, that usually means that
> something the user did in Makefile.am has tricked automake into generating
> incorrect libtool commands in the first place, rather than that an actual
> libtool bug has just appeared.  (Libtool bugs are possible of course, but user
> errors in automake scripts are more common.)
>
>      cheers,
>        DaveK
>
>

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.
Regards


--
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

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

[Dave Korn]

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.

  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.

    cheers,
      DaveK


--
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

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

[Yaakov (Cygwin/X)]

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

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

[Charles Wilson]

On 9/26/2011 3:03 PM, Yaakov (Cygwin/X) wrote:
> 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.

IMO, the real problem here is libtool's insistence on linking with ld,
rather than using the language driver to link.  This is what causes
libtool to try to determine the pre/post dep libraries and objects that
the driver would implicitly use, and to list them in .la files.

There's general support on the libtool list for modifying libtool
behavior, at least for CC=gcc and LD=gnu ld, to change this behavior so
that pre/post deps are no longer computed, and the language driver is
used to link.  That is a major behavioral change, and would require a
lot of review and platform testing.  So far nobody -- including me --
has had time to pursue it.

If somebody is looking for a project...

--
Chuck


--
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