Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
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
Message-ID: <41812C6A.8060204@cwilson.fastmail.fm>
Date: Thu, 28 Oct 2004 13:29:14 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 MultiZilla/1.6.4.0b
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1
References: <90459864DAD67D43BDD3D517DEFC2F7D029F21 AT axon DOT Axentia DOT local>
In-Reply-To: <90459864DAD67D43BDD3D517DEFC2F7D029F21@axon.Axentia.local>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Peter Ekberg wrote:
> BTW, this is the command that generates the wrapper script
> when it shouldn't:
> /bin/sh ../libtool --mode=link --tag=CC gcc  -g -O2 -D_REENTRANT
> -D_THREAD_SAFE -DDEBUG -g -Wall -Wpointer-arith -Wsign-compare
> -Wstrict-prototypes -Wswitch -Wmissing-prototypes -Wreturn-type -Wshadow
> -o xsendbut.exe  xsendbut.o -L/usr/X11R6/lib -lX11
> 
> I should perhaps note that xsendbut resides in a directory
> where other executables are built that do indeed depend on
> uninstalled libtool libs, if that is at all relevant?

I don't know.  I don't THINK so, but...

> On the off chance that you (or someone else) want to get
> first hand experience of the problem, try libgii from cvs
> available from:
> 
> cvs -d:pserver:anonymous AT cvs DOT sf DOT net:/cvsroot/ggi login 
> cvs -z3 -d:pserver:anonymous AT cvs DOT sf DOT net:/cvsroot/ggi co ggi-core/libgii
> cd ggi-core/libgii
> ./autogen.sh
> ./configure
> make
> make install
> 
> xsendbut is in the demos subdir.

Unfortunately my travel schedule won't allow me to look into this.  It 
smells like there is a real problem in libtool somewhere, but darned if 
I know what it is.

It seems like a design decision was made, that IF in a given project 
there are ANY libtool libs, then libtool will "know" about it by having 
build_libtool_libs set to "yes".  And thus, every executable is 
*assumed* to be linked against those libs, and will therefore have a 
wrapper and be linked against those shared libs.

Except in your case, you have ONE executable that is NOT linked against 
any shared libs...and the wrapper-check fails.

Maybe the right answer here is to change the check so that instead of

           # Check the variables that should have been set.
           test -z "$notinst_deplibs" && \
             func_fatal_error "invalid libtool wrapper script \`$wrapper'"

it checks for some other magic instead (which would need to be added to 
the "make a wrapper" code)

           # Check the variables that should have been set.
           test -z "$generated_by_libtool_version" && \
             func_fatal_error "invalid libtool wrapper script \`$wrapper'"

where the "make a wrapper" code ensures that the following assignment 
appears in the wrapper

ORIG> if test "$libtool_install_magic" = "%%%MAGIC variable%%%"; then
ORIG>  # install mode needs the following variables:
ORIG>  notinst_deplibs=....
NEW >  generated_by_libtool_version=$macro_version
ORIG> else


Our check wouldn't care about the actual VALUE of 
$generated_by_libtool_version -- only that it was, in fact, set to 
SOMETHING.


Can't flesh this out anymore right now, but you get the idea...

--
Chuck


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