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
Message-ID:	<3E9A19C8.6070403@ece.gatech.edu>
Date:	Sun, 13 Apr 2003 22:15:36 -0400
From:	Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent:	Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language:	en-us, en
MIME-Version:	1.0
To:	"Gerrit P. Haase" <gp AT familiehaase DOT de>
CC:	cygwin AT cygwin DOT com
Subject:	Re: libtool-devel problem with building 'dummy' exe
References:	<1348756941 DOT 20030413234111 AT familiehaase DOT de>
In-Reply-To:	<1348756941.20030413234111@familiehaase.de>

Sigh..  one more time, using cygwin@ instead of gmane...

Gerrit P. Haase wrote:

 > /expat/expat-1.95.6/.obj/libtool: cannot create 
.libs/lt-xmlwf/xmlwf.c: directory nonexistent

I've never seen this before: libtool trying to create a .c file in a 
subdirectory of the .libs dir.  Now, this .c file is autogenerated; it's 
the source code that is used to build the "binary wrapper" -- which 
simply calls the shell-script wrapper that libtool has used for ages to 
set the environment properly before running an uninstalled executable.

The binary wrapper is necessary to fool make into not rebuilding the 
"real" executable over and over and over. Eventually, all of the 
functionality of the shell-script wrapper can be folded into the binary 
wrapper instead, and the shell-script wrapper can be eliminated -- but 
not yet.

So, in *every* case I have seen, the source code for the wrapper is 
dumped into
   .libs/[lt-]<executable-name>.c  and NOT
   .libs/<some subdir>/[lt-]<executable-name>.c

I suspect something wacky in the Makefile.am for expat...

 > I guess libtool-devel tries to make the 'dummy' executable here,


not exactly; the dummy executable goes into the parent of .libs; that's 
the whole point (how else could 'make' be fooled into not rebuilding?). 
   It appears that libtool is trying to place the *source code* for the 
dummy executable there.

 > but fails because the directory or s.th. else is missing.  I used
 > it already without problems when building in the sourcetree, but
 > when using your famous packaging script it fails.

When building within the source tree, where did xmlwf.c get created? in 
.libs, or in .libs/lt-xmlwf/ ?

 > Do I need to take care of the needed directories from the script or
 > should libtool do this in every case?


Hard to say until we know WHY libtool is using subdirectories of .lib. 
As I said, I have never seen that behavior before; it isn't a design 
behavior.

--Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -