Mail Archives: cygwin/2008/09/25/16:18:46
Charles Wilson wrote on 15 April 2008 00:07:
> Yaakov (Cygwin Ports) wrote:
>> Charles Wilson wrote:
>>> Changes sine libtool2.2-2.2.2-1
>>> =================================
>>> o changed base package name from 'libtool2.2' to 'libtool'
>>> o Added patches from Yaakov Selkowitz
>>> http://cygwin.com/ml/cygwin/2008-04/msg00378.html
>>
>> Do you know why I'm getting this:
>>
>> *** Warning: linker path does not have real file for library -lwinmm.
<g> I do!
> I think that libtool hasn't been told that LDFLAGS should include
> -L/usr/lib/w32api.
Nope, because as we know that's always in the default search path. It's
nowt t'do wi' t'PATH setting.
>> *** I have the capability to make that library automatically link in when
>> *** you link to this library. But I can only do this if you have a
>> *** shared version of the library, which you do not appear to have
>> *** because I did check the linker path looking for a file starting
>> *** with libwinmm but no candidates were found. (...for file magic test)
>>
>> Is it the /usr/lib/w32api location that libtool is having a hard time
>> with, the .a extension, or something else?
>
> No, it's not a file type or identification problem; libtool can't find
> libwinmm.a at all.
Yep, that's correct. You ever-so-nearly had it here:
> FWIW:
>
> $ ./func_win32_libid.sh /usr/lib/w32api/libwinmm.a
> x86 archive import
>
> So that's ok. (func_win32_libid.sh is just func_win32_libid() from
> libtool-2.2.2-2, with the OBJDUMP/NM/etc variables set.
Spot the missing gap in the logic?
1. This works.
2. This is just func_win32_libid with some variables set.
3. Therefore func_win32_libid works.
Given that we know the conclusion is wrong, there must be a problem with the
antecedents. #1 can't be wrong, we saw it with our own eyes. So it must be
#2.
Yep, you've got it. The problem is that OBJDUMP is not set to anything, and
so the regexes all fail pretty hard. And the reason that OBJDUMP is not set
to anything is due to this very common idiom in GNU projects that exercise
recursive makes:
# Work around what appears to be a GNU make bug handling MAKEFLAGS
# values defined in terms of make variables, as is the case for CC and
# friends when we are called from the top level Makefile.
AM_MAKEFLAGS = \
"AR_FLAGS=$(AR_FLAGS)" \
"CC_FOR_BUILD=$(CC_FOR_BUILD)" \
"CFLAGS=$(CFLAGS)" \
"CXXFLAGS=$(CXXFLAGS)" \
"CFLAGS_FOR_BUILD=$(CFLAGS_FOR_BUILD)" \
"CFLAGS_FOR_TARGET=$(CFLAGS_FOR_TARGET)" \
"INSTALL=$(INSTALL)" \
... snip ... actual list may vary per instance ...
"prefix=$(prefix)" \
"includedir=$(includedir)" \
"AR=$(AR)" \
"AS=$(AS)" \
"CC=$(CC)" \
"CXX=$(CXX)" \
"LD=$(LD)" \
"LIBCFLAGS=$(LIBCFLAGS)" \
"NM=$(NM)" \
"PICFLAG=$(PICFLAG)" \
"RANLIB=$(RANLIB)" \
"DESTDIR=$(DESTDIR)"
Notice anything missing? :-) The answer is simple enough: add a couple of
lines that read:
"OBJDUMP=$(OBJDUMP)" \
"OBJDUMP_FOR_TARGET=$(OBJDUMP_FOR_TARGET)" \
somewhere in there (I put them after NM myself but it's of no functional
relevance) in the Makefile.am, regenerate the Makefile.in, and you're away.
Chuck, it's not a libtool bug, but there might be something worth doing
upstream: since this happens a lot in GNU software, it might be a courtesy to
replace the reference to $OBJDUMP in func_win32_libid with something else
roughly along the lines of "${OBJDUMP:-echo 'Objdump not defined'; false}"
(which won't work as-is owing to the output redirections in place, but YKWIM:
something that emits an error and fails/bails).
cheers,
DaveK
--
Can't think of a witty .sigline today....
--
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 -