Williams, Gerald S (Jerry) wrote:
You've probably already ruled this out, but if you do see it
again, you might want to verify that you're not mixing path
separators (LIB.EXE will use either). I believe you must use
only backslash-style separators if you want to interoperate
with ar.
gsw
Ironically, I just put a hardcopy of ar.c in the shredder. As I
recall... take a look at function normalize(). We see that '/' does
enjoy special status. Or, more precisely, the rightmost '/' has special
status. This will make sense if you have the code open. And we also
see that '\' has special status *if* HAVE_DOS_BASED_FILESYSTEM (or
something like that) is #defined. The code is clearly trying to handle
everything.
For what it's worth, I think my problem was different. All of the
members were of the form <path>\<name>.obj where <path> was either
Release or Debug; and <name> was whatever. For the Release\ form I have
never seen a problem. For the Debug\ form, some members were not
reported by 'ar t' even though 'ar x' got them all. Oddly enough, 'ar
tv' identifes all the members -- including the 'T' section -- but just
gets the name wrong at the top, printing just Debug\ instead of, e.g.
Debug\foo.obj.
After all this discussion and looking at the code I am reasonaly
convinced that the problem I saw lay in the structure of my debugging
libs built with LIB.EXE and was in no way a problem with 'ar.' So with
that, I will bow out of this thread which probably no longer belongs on
gmane.os.cygwin.
Thanks to everyone, including those who took the time to make private
suggestions.
--
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/
