Williams, Gerald S (Jerry) wrote:
Coatimundi wrote: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.I think you need to use the -P option: $ ar t foobar.lib release\foo.obj release\bar.obj $ ar xv foobar.lib 'release\foo.obj' no entry release\foo.obj in archive $ ar xvP foobar.lib 'release\foo.obj' x - release\foo.obj gsw
Thank you for bringing this up. I forgot to mention (a sure sign that my multitasking scaling is rolling over) that I also tried the P option. While this usually works, I found cases where it did not. Interestingly, these cases corresponded to libs compiled with debugging information, which are precisely the libs for which 'ar t' returns some (about 25%) but not all of the member names. I know the expected members are there, because (1) 'ar x' (with no member specified) does in fact extract all of the members and (2) I can link against them. Very strange to my simple mind.
I see nothing wrong with the source for 'ar' so I suspect that there is something not quite right about my lib (which was built with MS's LIB.EXE) with debugging info. Since I see nothing wrong with the source and I am short on time, I am going to chalk this up to an unidentified mistake on my part, unless I see it again and have time to build bintools myself and step through the code in debug.
The good news is I have not seen any problem with non-debug-info libs, which is sufficient for my purposes.
Thanks for your good suggestion. And thanks to the Cygwin team for porting an incredibly useful set of tools!
-- 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/
