Message-ID: <48044AEF.9010509@cwilson.fastmail.fm>
Date: Tue, 15 Apr 2008 02:27:59 -0400
From: Charles Wilson <cygwin@cwilson.fastmail.fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
References: <announce.48038853.7090707@cwilson.fastmail.fm> <4803AA47.70501@users.sourceforge.net> <4803E38F.9080708@cwilson.fastmail.fm> <48041592.1010400@users.sourceforge.net>
In-Reply-To: <48041592.1010400@users.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

Yaakov (Cygwin Ports) wrote:
> Charles Wilson wrote:
> | I think that libtool hasn't been told that LDFLAGS should include
> | -L/usr/lib/w32api.  I think this is something that should be passed on
> | the invocation line in your makefile -- maybe AM_LDFLAGS needs to be set?
> 
> As I'm sure you're aware, /usr/lib/w32api is in ld's default library
> path, so -L/usr/lib/w32api should never be necessary.

unless -nostdlib, right?  Which libtool uses. Besides, I don't know of a 
way to get ld to print its search path (which is why Brian grep'ed the 
binary) like gcc's -print-search-dirs. So libtool has no mechanism to 
obtain this info -- other than hardcoded variables like 
sys_lib_search_path_spec.

And libtool needs this info, obviously, because it does this 
'pre-screening' stuff on dependencies -- is it a static archive, is it 
this, is it that, etc -- so it has to know where to look.

But you're right: it IS hardcoded, so what ld or gcc thinks is immaterial.

 > Nor was it
> required with libtool-1.5; this is a regression, but I'm not sure what
> the cause is.
> 
> In /usr/bin/libtool, I see the following:
> 
> sys_lib_search_path_spec="/usr/lib /lib/w32api /lib /usr/local/lib"
>
> which is hard-coded for cygwin in _LT_SYS_DYNAMIC_LINKER (prev.
> AC_LIBTOOL_SYS_DYNAMIC_LINKER).  But with the libtool script in the
> package I'm trying to build, I find:
> 
> sys_lib_search_path_spec="/lib /usr/lib /usr/local/lib"

this is the default setting of sys_lib_search_path_spec, established at 
the beginning of _LT_SYS_DYNAMIC_LINKER.  However, as you point out, 
sys_lib_search_path_spec is a tagged variable...

I wonder if there is some interaction here between tag support/order of 
invocation of the tag declarators -- LT_LANG(lang) or AC_PROG_lang, 
compared to when LT_OUTPUT is called.

      Both of the following examples are therefore valid ways of adding
      C++ language support to Libtool.

           LT_INIT
           LT_LANG([C++])

           LT_INIT
           AC_PROG_CXX

> This didn't happen in another package, so I dug a bit further.  If I run
> ./config.lt in this particular package, then the correct
> $sys_lib_search_path_spec appears, but when I run './config.status
> libtool', then I get the latter.

Well, ordinarily you don't GET a config.lt file -- that is produced only 
when you use LT_OUTPUT.  The bug is:

      Also, when `LT_OUTPUT' is used, for backwards compatibility with
      Automake regeneration rules, `config.status' will call `config.lt'
      to regenerate `libtool', rather than generating the file itself.

So, 'config.status libtool' ought to delegate to config.lt in your case, 
which should, in a sane world, generate the same libtool script as 
calling config.lt directly.

Either your config.status is NOT delegating to config.lt, or...the 
world's gone MAD. (Or maybe config.status is mucking up the environment 
before calling config.lt...)

> Both packages use CC and CXX tags, and but the one that works correctly
> had warnings during autoreconf:
> 
> configure.ac:169: warning: LT_OUTPUT was called before LT_LANG
> /usr/share/aclocal/libtool.m4:775: LT_LANG is expanded from...
> configure.ac:169: the top level
> /usr/share/aclocal/libtool.m4:5282: _LT_PROG_CXX is expanded from...
> /usr/share/aclocal/libtool.m4:5305: _LT_LANG_CXX_CONFIG is expanded from...
> /usr/share/aclocal/libtool.m4:792: _LT_LANG is expanded from...
> autoreconf-2.61: configure.ac: tracing
> configure.ac:169: warning: LT_OUTPUT was called before LT_LANG
> aclocal.m4:790: LT_LANG is expanded from...
> configure.ac:169: the top level
> 
> where the package with the buggy libtool had no such warnings.

1) do both packages use LT_OUTPUT
2) does either package explicitly call AC_PROG_CXX/LT_LANG([C++])
3) if so, when? before LT_INIT, before LT_OUTPUT, or after?

Somehow, the buggy version is NOT initializing sys_lib_search_path_spec 
to the proper value for this arch+tag; instead, it's using the default 
value for all arch and all tags.

> Any ideas?

  -- Macro: LT_OUTPUT
      ...  You
      can add `LT_OUTPUT' to your `configure.ac' any time after
      `LT_INIT' and any `LT_LANG' calls; that done, `libtool' will be
      created by a specially generated `config.lt' file, and available
      for use in later tests.

Make sure LT_LANG calls (*and* AC_PROG_lang ?) appear after LT_INIT but 
before LT_OUTPUT ?

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