On 2012-10-07 06:04, Gary V. Vaughan wrote:
> Hi Peter,
>
> On 7 Oct 2012, at 06:53, Peter Rosin <p...@lysator.liu.se> wrote:
>> How is the below function supposed to work
>> when $file_magic_cmd is '$OBJDUMP -f' and not 'func_win32_libid'?
>
> I have no idea :(
>
>> objdump doesn't output "import" for me, at least not for any
>> import lib I have given it. Chunk?
>>
>> # func_win32_import_lib_p ARG
>> # True if ARG is an import lib, as indicated by $file_magic_cmd
>> func_win32_import_lib_p ()
>> {
>> $debug_cmd
>>
>> case `eval $file_magic_cmd \"\$1\" 2>/dev/null | $SED -e 10q` in
>> *import*) : ;;
>> *) false ;;
>> esac
>> }
>
> Does '$OBJDUMP -f' output anything that can be used to distinguish an
> import library?
Don't think so.
> If so, add that to the *import* leg of the case statement above. If not,
"objdump -f" output from normal static lib:
--------------8<---------------
In archive ../msvc/tests/testsuite.dir/035/.libs/hello.lib:
libhello_la-foo.obj: file format pe-i386
architecture: i386, flags 0x0000003d:
HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x00000000
libhello_la-hello.obj: file format pe-i386
architecture: i386, flags 0x0000003d:
HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x00000000
--------------8<---------------
And from an import lib:
--------------8<---------------
In archive ../msvc/tests/testsuite.dir/034/.libs/hello.dll.lib:
hello-2.dll: file format pe-i386
architecture: i386, flags 0x0000003d:
HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x00000000
hello-2.dll: file format pe-i386
architecture: i386, flags 0x0000003d:
HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x00000000
hello-2.dll: file format pe-i386
architecture: i386, flags 0x0000003d:
HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x00000000
hello-2.dll: file format pei-i386
architecture: i386, flags 0x00000018:
HAS_DEBUG, HAS_SYMS
start address 0x00000000
hello-2.dll: file format pei-i386
architecture: i386, flags 0x00000018:
HAS_DEBUG, HAS_SYMS
start address 0x00000000
hello-2.dll: file format pei-i386
architecture: i386, flags 0x00000018:
HAS_DEBUG, HAS_SYMS
start address 0x00000000
--------------8<---------------
I don't imagine any of the differences to be really useful. I don't
know though... pe-i386 vs. pei-i386 looks promising, but I don't
possess enough PE-COFF-fuu to tell for sure. I think it would
have been used previously if it really did work?
> then file_magic_cmd should not be set to '$OBJDUMP -f' for at least that
> particular combination of MSVC/objdump/mingw that you are using:
I don't think this is particular to my specific objdump, as it
is the one from GNU binutils, and I believe this problem with
func_win32_import_lib_p to be generic to all known objdumps out
there. I don't think this has ever worked as intended.
>> mingw* | pw32*)
>> # Base MSYS/MinGW do not provide the 'file' command needed by
>> # func_win32_libid shell function, so use a weaker test based on 'objdump',
>> # unless we find 'file', for example because we are cross-compiling.
>> # func_win32_libid assumes BSD nm, so disallow it if using MS dumpbin.
>> if ( test "$lt_cv_nm_interface" = "BSD nm" && file / ) >/dev/null 2>&1; then
>> lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL'
>> lt_cv_file_magic_cmd='func_win32_libid'
>> else
>> # Keep this pattern in sync with the one in func_win32_libid.
>> lt_cv_deplibs_check_method='file_magic file format
>> (pei*-i386(.*architecture: i386)?|pe-arm-wince|pe-x86-64)'
>> lt_cv_file_magic_cmd='$OBJDUMP -f'
>
> lt_cv_file_magic_cmd='func_win32_libid'
>
> ??
func_win32_libid requires file(1) to be present (wasn't always the
case on MSYS) and that "$NM -f posix -A <file>" is useful (obviously
not the case when NM="dumpbin -symbols").
I suppose one way forward is to flesh out func_win32_libid to also
handle $lt_cv_nm_interface = "MS dumpbin" and then rely on file to
be present. That would make MSVC work on modern but not legacy
MSYS, which does not seem like much of an issue. But that would not
solve matters for wince and old MSYS lacking file(1), and any solution
for those would perhaps be a solution for NM="dumpbin -symbols" as
well, and piggybacking like that is always nice.
Cheers,
Peter
_______________________________________________
https://lists.gnu.org/mailman/listinfo/libtool
