This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]