Re: Does 'ar' work with native MS Windows libs?

[Coatimundi <coatimundi at cox dot net>]

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/