delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2003/09/24/17:09:55

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/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
Date: Wed, 24 Sep 2003 23:15:24 +0200
From: "Gerrit P. Haase" <gp AT familiehaase DOT de>
Reply-To: "Gerrit @ cygwin" <cygwin AT cygwin DOT com>
Organization: Esse keine toten Tiere
X-Priority: 3 (Normal)
Message-ID: <1751980256598.20030924231524@familiehaase.de>
To: cygwin AT cygwin DOT com
Subject: Re: libtool with expat, xmlwf/xmlwf target problems again
In-Reply-To: <511929959364.20030924091707@familiehaase.de>
References: <511929959364 DOT 20030924091707 AT familiehaase DOT de>
MIME-Version: 1.0

Hallo Charles,

> Do you remember our talk about libtool problems when the targetname is
> xmlwf/xmlwf and when the target name is also the executable name,
> here: http://www.cygwin.com/ml/cygwin/2003-04/msg01283.html

[...]

> Do you have an idea what I can do to get around this?

I found a workaround now.  This patch includes also my usual change
which make the whole wrapper useless.  I needed it to builkd glib/gtk+
because they use libtool to create executables which are used to
generate code during the build, this didn't worked because the wrapper
doesn't produce the code and it also doesn't execute the real
executable.  This seems to be still the problem, so I just link the
real executable and get also the other problem killed with this,
libtool doesn't rebuild the executables all the time.

The first part is the more interesting, with this I can use targets
like xmlwf/xmlwf in the Makefiles and it will also work for 'normal'
targets in recursive builds since `dirname xmlwf` will return the
current path '.' where `dirname xmlwf/xmlwf` returns 'xmlwf'.

Would you be so kind to approve and test this patch so it can be
included in the real libtool distribution.  Should be no act since it
will only affect cygwin/mingw builds.  Though not tested, it should
work on mingw in the same way.

Without the second part of the patch, e.g. also make check in expat
fails since the new executable is called to run the tests.

So, for me it would work without generating the wrapper at all, but
I guess the great wrapper plan prevents such a change;-)

$ diff -udb ltmain.sh~ ltmain.sh
--- ltmain.sh~  2003-08-18 07:36:11.001000000 +0200
+++ ltmain.sh   2003-09-24 22:55:58.852886400 +0200
@@ -4481,8 +4481,10 @@
        esac
        case $host in
          *cygwin* | *mingw* )
-           cwrappersource=`$echo ${objdir}/lt-${output}.c`
-           cwrapper=`$echo ${output}.exe`
+           output_name=`basename $output`
+           output_path=`dirname $output`
+           cwrappersource=`$echo ${output_path}/${objdir}/lt-${output_name}.c`
+           cwrapper=`$echo ${output_path}/${output_name}.exe`
            $rm $cwrappersource $cwrapper
            trap "$rm $cwrappersource $cwrapper; exit 1" 1 2 15
 
@@ -4813,7 +4815,7 @@
          # are only useful if you want to execute the "real" binary.
          # Since the "real" binary is built for $host, then this
          # wrapper might as well be built for $host, too.
-         $run $LTCC -s -o $cwrapper $cwrappersource
+         $run ln ${output_path}/${objdir}/${output_name}.exe ${cwrapper}
          ;;
        esac
        $rm $output

# END OF PATCH

Gerrit
-- 
=^..^=


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019