Following up my own post...
Coatimundi wrote:
The thing I noticed first was that 'ar vt libfoo.a' did not always list
all of the member names. Some were present, some were missing. (Linking
with the lib unambiguously confirms that they're all there. The total
number of routines is about 20 in this small lib.) So far I have seen
this effect only with libs compiled with debugging information. I have
not noticed this problem with libs compiled without debugging info.
This observation is anecdotal but enough to make me wonder.
So I decided to extract a single object from the (non-debug-info)
libfoo.a with both Cygwin's ar and Microsoft's LIB.EXE. The resulting
objects differed in byte-count, which I took (perhaps wrongly) as a
strong clue that I was headed in the wrong direction.
I found a workaround. The 'ar' which ships with Cygwin works great on
Microsoft libs, as long as the members of the archive are simple
filenames without paths. So my workaround is to compile objects into
the Visual Studio project directory (not .\Debug or .\Release) before
LIB.EXE runs. After LIB, I delete *.obj from the project directory.
This forces LIB to write simple names into the archive.
If paths are included in the archive (which is typical for libs created
by Visual Studio), then ar may in some cases claim that members
(displayed with 'ar t') do not exist when doing "ar x lib.a {object}"
either by path/name.obj or just name.obj.
A quick review of the source (binutils-20060817) shows that 'ar' is
clearly intended to handle this peculiarity of the Microsoft libs (See
the normalize() function.) I'm not going to try any quick mods. But if
more people experience this problem, perhaps one of them will find this
post and be more motivated than me!
Cheers!
--
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/
