This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.


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:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]