Re: use $EXEEXT consistently in new testsuite
Ping. Roumen Petrov wrote: [SNIP] Now my environment is with Fortran and Java tools. Tests 21 and 22 - ok. For test 23 - one more $EXEEXT. Please see attached file "libtool-origin-20081127.diff" [SNIP] Roumen diff --git a/tests/convenience.at b/tests/convenience.at index 995c8ff..c689811 100644 --- a/tests/convenience.at +++ b/tests/convenience.at @@ -263,7 +263,7 @@ EOF # libgcj.spec or unable to find it. Skip this test for them. if test $i -eq 1; then AT_CHECK([$GCJ $GCJFLAGS -c foo1.java || exit 77], [], [ignore], [ignore]) -AT_CHECK([$GCJ $GCJFLAGS --main=foo1 -o foo1 foo1.java A1.java || exit 77],[],[ignore],[ignore]) +AT_CHECK([$GCJ $GCJFLAGS --main=foo1 -o foo1$EXEEXT foo1.java A1.java || exit 77],[],[ignore],[ignore]) AT_CHECK([./foo1$EXEEXT || exit 77],[],[ignore],[ignore]) rm -f foo1.o foo1.obj foo1$EXEEXT fi
Re: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89.
Roumen Petrov wrote: > Charles Wilson wrote: > [SNIP] >> This patch attempts to correct the issues raised in this thread: >> "msys/mingw warnings about string length and putenv absence with gcc >> -Wall -ansi" >> http://lists.gnu.org/archive/html/bug-libtool/2008-12/msg00038.html >> > [SNIP] > Patch fail for trunk(origin): > 10 out of 11 hunks FAILED -- saving rejects to file > libltdl/config/ltmain.m4sh.rej I'm confused. I just did a 'git pull' on master, and my master was up-to-date. Then I did a 'git rebase master' on my branch, and it said 'Current branch cygwin-c89-fix is up to date.' So then I tried to apply the patch to my master (dry-run): patch -p1 --dry-run < ../0010--cygwin-mingw-Fix-compile-warnings-when-std-c89.patch patching file libltdl/config/ltmain.m4sh and it worked fine. Maybe the patch got mangled in the mail. I'll send it privately to you as an attachment. -- Chuck
Re: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89.
Charles Wilson wrote: [SNIP] This patch attempts to correct the issues raised in this thread: "msys/mingw warnings about string length and putenv absence with gcc -Wall -ansi" http://lists.gnu.org/archive/html/bug-libtool/2008-12/msg00038.html [SNIP] Patch fail for trunk(origin): $ patch -p1 --dry-run < .../Fix\ compile\ warnings... patching file libltdl/config/ltmain.m4sh Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] y Hunk #1 FAILED at 5. Hunk #2 FAILED at 2309. Hunk #3 FAILED at 2406. Hunk #4 FAILED at 2526. Hunk #5 FAILED at 2717. Hunk #6 succeeded at 2725 with fuzz 2 (offset -10 lines). Hunk #7 FAILED at 2769. Hunk #8 FAILED at 2821. Hunk #9 FAILED at 2855. Hunk #10 FAILED at 2952. Hunk #11 FAILED at 3712. 10 out of 11 hunks FAILED -- saving rejects to file libltdl/config/ltmain.m4sh.rej Roumen
Re: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89.
Charles Wilson wrote: Now I get completely new working cross-environment: git show correctly modified files, patch work too :) . [SNIP] No regressions on msys/mingw from the last time I ran the testsuite on that platform (2.2.5a). IOW: Old testsuite results: [SNIP] No regression on unix/mingw too. New testsuite results: ERROR: 77 tests were run, 6 failed (3 expected failures). 4 tests were skipped. 65: compiling softlinked libltdl FAILED (recursive.at:71) 66: compiling copied libltdl FAILED (recursive.at:91) 67: installable libltdlFAILED (recursive.at:113) 80: Run tests with low max_cmd_len (ctrl-C'ed, so not incl. in tally) The results: 17: preserve duplicate convenience deps expected failure 29: static linking flags for programs skipped 32: sys_lib_search_path skipped 35: static library contains static library expected failure 74: build tree relpaths expected failure 80: Run tests with low max_cmd_len(CANCELED) For 32: My new build environment is with incorrect path to libz :(. For 23: Java convenience archives is ok as my build env. contain one $EXEEXT more. OK to push? Fine with me. Roumen
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2
Charles Wilson wrote:
> Peter Rosin wrote:
>> I'm primarily trying to determine what impact this has on my
>> MSVC branch...
Ran some experiments on the libraries shipped with the Windows SDK. The
attached script worked ok on most of them. After eliminating the static
libraries and the import libraries to '*.dll' and '*.DLL' (241
"successes" in all), I'm left with the following 13 odd ducks:
These are correct, but are a reminder that import libraries exist for
objects other than those named foo.dll. So that's 5 more successes:
KSProxy.Lib :x86 archive import FOR ksproxy.ax
bthprops.lib :x86 archive import FOR bthprops.cpl
irprops.lib :x86 archive import FOR irprops.cpl
NetSh.Lib :x86 archive import FOR NETSH.EXE
WinSpool.Lib :x86 archive import FOR WINSPOOL.DRV
These are the true failures:
For the following 6 libraries, it is the LAST archive member with a
.idata$6 section, not the first one, that specifies the DLL.
GdiPlus.lib :x86 archive import FOR u.GdiplusStartup
MSTask.Lib :x86 archive import FOR .._setnetscheduleaccountinformat...@12
WS2_32.Lib :x86 archive import FOR ..inet_pton
ksuser.lib :x86 archive import FOR ..KsCreateTopologyNode
shell32.lib :x86 archive import FOR =.WOWShellExecute
windowscodecs.lib :x86 archive import FOR q.WICSetEncoderFormat_Proxy
This one imports symbols from multiple DLLs. One of them happens to be
in the last archive member, but...
Vfw32.Lib :x86 archive import FOR -.StretchDIB
I have no idea what this one is. objdump can't grok it:
MAPI.Lib :MAPI.Lib: Microsoft Visual C library
$ objdump -f MAPI.Lib
objdump: MAPI.Lib: File format not recognized
So that's 246 PASS, 8 FAIL.
But I wonder if these 8 failures are just pathological cases, and the
code embodied in the attached script is "good enough" -- assuming an
msvc-configured libtool is allowed to use "file", "objdump", "nm", etc.
"Doctor, func_dll_from_imp fails for library shell32.lib, so I can't
dlpreopen it"..."Ok, don't do that then."
NOTE:
I had to change the grep expression:
*ar\ archive*) # could be an import, or static
if objdump -f "$1" | sed -e '10q' 2>/dev/null |
grep -E 'file format pei?-i386(.*architecture: i386)?' >/dev/null
; then
from ...pe-i386(... to ...pei?-i386(... so that some of the import
libraries were recognized as such. I'm not sure what the distinction
between pe-i386 and pei-i386 is, or what the implications of this
particular change would be.
FWIW, I think this sed script is safer than the other one, even at the
cost of an extra fork. Keeping the contents of each archive member on a
separate line, rather than merging them all together, just seems better.
--
Chuck
#!/bin/sh
DLLNAME_SECTION=.idata\$6
# mostly the same as libtool's function of the same name,
# except that it stores the result in an explicitly-accessible
# *_result variable. Still echos, tho. Also, the grep -E
# expression is slightly different: pe-i386 -> pei?-i386
func_win32_libid ()
{
func_win32_libid_result=unknown
win32_fileres=`file -L "$1" 2>/dev/null`
case $win32_fileres in
*ar\ archive\ import\ library*) # definitely import
func_win32_libid_result="x86 archive import"
;;
*ar\ archive*) # could be an import, or static
if objdump -f "$1" | sed -e '10q' 2>/dev/null |
grep -E 'file format pei?-i386(.*architecture: i386)?' >/dev/null ; then
win32_nmres=`eval nm -f posix -A "$1" 2>/dev/null |
sed -n -e '
1,100{
/ I /{
s,.*,import,
p
q
}
}'`
case $win32_nmres in
import*) func_win32_libid_result="x86 archive import" ;;
*) func_win32_libid_result="x86 archive static";;
esac
fi
;;
*DLL*)
func_win32_libid_result="x86 DLL"
;;
*executable*) # but shell scripts are "executable" too...
case $win32_fileres in
*MS\ Windows\ PE\ Intel*)
func_win32_libid_result="x86 DLL"
;;
esac
;;
esac
echo "$func_win32_libid_result"
}
# same as libtool's, from master
func_win32_import_lib_p ()
{
case `func_win32_libid "$1" 2>/dev/null | sed -e 10q` in
*import*) : ;;
*) false ;;
esac
}
# Odd. For some reason I can't capture this directly in
# backticks. So, use a level of indirection:
func_dll_for_imp_core ()
{
objdump -s --section "$DLLNAME_SECTION" "$1" 2>/dev/null |
sed '/^Contents of section '"$DLLNAME_SECTION"':/{
# Place marker at beginning of archive member dllname section
s/.*/MARK/
p
d
}
# These lines can sometimes be longer than 43 characters, but
# are always uninteresting
/:[ \t]*file format pe[i]\{,1\}-i386$/d
/^In archive [^:]*:/d
# Ensure marker is printed
/^MARK/p
# Remove all lines with less than 43 characters
/^.\{43\}/!d
# From remoaining lines, remove first 43 characters
s/^.\{43\}//' |
sed -n '
# Join marker and all
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2
Charles Wilson wrote:
> Charles Wilson wrote:
>> Peter Rosin wrote:
>>> I'm primarily trying to determine what impact this has on my
>>> MSVC branch...
>
> Ran some experiments on the libraries shipped with the Windows SDK. The
> attached script worked ok on most of them. After eliminating the static
> libraries and the import libraries to '*.dll' and '*.DLL' (241
> "successes" in all), I'm left with the following 13 odd ducks:
>
> These are correct, but are a reminder that import libraries exist for
> objects other than those named foo.dll. So that's 5 more successes:
>
> KSProxy.Lib :x86 archive import FOR ksproxy.ax
> bthprops.lib :x86 archive import FOR bthprops.cpl
> irprops.lib :x86 archive import FOR irprops.cpl
> NetSh.Lib :x86 archive import FOR NETSH.EXE
> WinSpool.Lib :x86 archive import FOR WINSPOOL.DRV
>
> These are the true failures:
>
> For the following 6 libraries, it is the LAST archive member with a
> .idata$6 section, not the first one, that specifies the DLL.
>
> GdiPlus.lib :x86 archive import FOR u.GdiplusStartup
> MSTask.Lib :x86 archive import FOR .._setnetscheduleaccountinformat...@12
> WS2_32.Lib :x86 archive import FOR ..inet_pton
> ksuser.lib :x86 archive import FOR ..KsCreateTopologyNode
> shell32.lib :x86 archive import FOR =.WOWShellExecute
> windowscodecs.lib :x86 archive import FOR q.WICSetEncoderFormat_Proxy
>
> This one imports symbols from multiple DLLs. One of them happens to be
> in the last archive member, but...
>
> Vfw32.Lib :x86 archive import FOR -.StretchDIB
>
> I have no idea what this one is. objdump can't grok it:
>
> MAPI.Lib :MAPI.Lib: Microsoft Visual C library
> $ objdump -f MAPI.Lib
> objdump: MAPI.Lib: File format not recognized
>
> So that's 246 PASS, 8 FAIL.
So, I've prepared a patch for dlltool which adds an '--identify-ms'
flag, which modifies the behavior of the '--identify ' option.
It searches for .idata$6 instead of .idata$7, AND attempts to
disambiguate between "the one that specifies the DLL name" and "all the
other ones that list the symbols" by inspecting the flags.
In almost all cases, "the one that specifies the DLL name" has the flag
value 0x0123
SEC_ALLOC | SEC_LOAD | SEC_DATA | SEC_HAS_CONTENTS
The "other ones" have flag values 0x00204103
SEC_ALLOC | SEC_LOAD | SEC_HAS_CONTENTS | SEC_IN_MEMORY | SEC_KEEP
This version of dlltool was able to operate on all of the import
libraries in the Windows SDK, except for:
MAPI.Lib: MAPI.Lib: Microsoft Visual C library
=== again, because bfd has no idea how to parse this one
Vfw32.Lib: Import library `Vfw32.Lib' specifies two or more dlls:
`MSVFW32.dll' and `AVIFIL32.dll'
And the following:
WebPost.Lib: x86 archive import FOR WEBPOST.DLL
ddao35.lib: x86 archive import FOR ddao35.dll
ddao35d.lib: x86 archive import FOR ddao35d.dll
ddao35u.lib: x86 archive import FOR ddao35u.dll
ddao35ud.lib: x86 archive import FOR ddao35ud.dll
More on these, later.
Note that this dlltool /succeeded/ on
GdiPlus.lib
MSTask.Lib
WS2_32.Lib
ksuser.lib
shell32.lib
windowscodecs.lib
where the script in my previous post failed. Dlltool can handle the case
where "the one that specifies the DLL name" is not first.
The five new failures (where the script succeeded) are interesting. In
each case, the "rule" above ("the one" has flag value 0x0123, and
the others do not) was incorrect:
$ ~/dlltool.exe --identify WebPost.Lib --identify-ms
flags: 0x0123 datasize: 000c data: 'WEBPOST.DLL'
5745 4250 4f53 542e 444c 4c00 WEBPOST.DLL.
flags: 0x0123 datasize: 0010 data: ''
0400 5770 4269 6e64 546f 5369 7465 4100 ..WpBindToSiteA.
/home/cwilson/dlltool: Import library `WebPost.Lib' specifies two or
more dlls: `WEBPOST.DLL' and `'
The error message is a little confusing: `WEBPOST.DLL' and `'? The
"empty" name is because the data contains the unprintable character \004
followed by '\0'. Recall for symbols, the first two bytes are a
little-endian count. So this is symbol 0x0004. I *guess* I could check
that both offset 0 and offset 1 contain printable characters. But that's
still just a heuristic, because a really big DLL might have
"01my_symbol"
where the first two bytes are 0x30 0x31 ('01') representing symbol
number 0x3130 or 12352.
But this wierd case occurs only when the import library appears to NOT
follow the pattern most of them do. In fact, in these five import
libraries, ALL of the .idata$6 sections have flag 0x0123, not just
"the one" we want.
But, what are they? Do we care?
The ddao35 libraries are the Microsoft JET 3.5 DAO C++ libraries, for
DOS-Win16 (!). Microsoft shipped the Jet 4.0 libraries with WinME and
W2k, and recommends against using ones older than that. Do we care that
you won't be able to dlpreopen (or dlltool --identify) these ancient
import libraries?)
Webpost.Lib (--> webpost.dll)
