X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_BG,TW_GT,TW_TK,TW_YG
X-Spam-Check-By:	sourceware.org
Message-ID:	<4E7F400F.8060004@gmail.com>
Date:	Sun, 25 Sep 2011 15:51:59 +0100
From:	Dave Korn <dave DOT korn DOT cygwin AT gmail DOT com>
User-Agent:	Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version:	1.0
To:	Cygwin Mailing List <cygwin AT cygwin DOT com>
Subject:	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
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

    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

- Raw text -