1) x86 DLL (and EXE)
2) x86 archive static
3) x86 archive import
4) other
Do NOT try to combine 2) and 3) -- which is what all of your suggestions
in this email would do.
[1]
What about extending the 'file' tool, which supports already 1, (2 combined with
3) and 4 ?
You have written (and I have checked this too) that 'file's execution time is
independend from the object file size, so this would speedup this detecion.
Now that's an idea, but we'd need to get it into the "real" file
distribution -- otherwise, cross-compile builds won't work.I've taken a look into the file source and have seen the only thing I don't know
is how to define a rule for a string with a variable fileoffset, because
'_dll_iname' is, as far as i can see, one of major identifier of import
libraries.
Yep. Believe it or not, I *did* look at this idea early on -- and you've
hit on the reason I didn't pursue it.For an example how to add support with fixed file offset
/usr/lib/libintl.dll.a):
$ diff -ubB archive.orig archive
--- MagDir/archive.orig 2003-02-10 09:01:41.000000000 +0100
+++ MagDir/archive 2003-02-10 09:00:36.000000000 +0100
@@ -79,6 +79,8 @@
>0 beshort 3 - shared library module
>0 beshort 4 - debug break-pointed module
>0 beshort 5 - absolute code program module
+>866 string _dll_iname import library
+
0 string \<ar> System V Release 1 ar archive
0 string =<ar> archive
#
Sure -- but as you say, that only works for fixed offsets. Now,
**most** import libs will need only the fixed offset, especially if you
hunt for _dll_iname instead of " I " in $NM's output as I was doing.
This is a very good idea.