On Mon, 2009-04-13 at 07:09 +0800, CAI Qian wrote: > From: CAI Qian <[email protected]> > Subject: Re: [LTP] Help Need for Ar01 Test Case > Date: Thu, 02 Apr 2009 10:46:37 +0800 (CST) > > > From: CAI Qian <[email protected]> > > Subject: Re: [LTP] Help Need for Ar01 Test Case > > Date: Wed, 18 Mar 2009 13:11:22 +0800 (CST) > > > >>>> So, it was working before when it was originally written that "ar -s" > >>>> can restore the file size to that before the strip run? Do you mean it > >>>> might be a "ar" regression bug? > >>> yep :). > >>> > >> > >> It also seems that "ranlib" is unable to regenerate the index as well. I > >> am filling a bug to see what developers think. > >> > >> Ranlib and "ar -s" Can Not Regenerate Index Last > >> https://bugzilla.redhat.com/show_bug.cgi?id=490797 > >> > > > > Robbie, looks like your tests are invalid according to the reply in the > > above BZ, > > > > This is the correct behaviour. Once you have stripped all of the > > symbols out of the files in the archive (using the "strip lib.a" > > command) it is no longer possible to regenerate the symbol index. > > Basically there are no symbols left in the archive, so it is not > > possible to create an index based on them. > > > > He also suggested that to use "string --strip-unneeded" instead, so it > > is possible to regenerate the symbol index later on. However, it is not > > clearly to me how to use that to fix your test cases. For example, > > > > $ ar cr lib.a file1.o > > $ ls -l lib.a > > -rw-rw-r-- 1 caiqian caiqian 1018 2009-04-02 10:42 lib.a > > $ nm -s lib.a > > > > Archive index: > > main in file1.o > > > > file1.o: > > 00000000 T main > > U puts > > > > $ strip --strip-unneeded lib.a > > $ ls -l lib.a > > -rw-rw-r-- 1 caiqian caiqian 994 2009-04-02 10:42 lib.a > > $ nm -s lib.a > > > > Archive index: > > main in file1.o > > > > file1.o: > > 00000000 T main > > U puts > > > > $ ar -s lib.a > > $ ls -l lib.a > > -rw-rw-r-- 1 caiqian caiqian 994 2009-04-02 10:43 lib.a > > $ nm -s lib.a > > > > Archive index: > > main in file1.o > > > > file1.o: > > 00000000 T main > > U puts > > > > > > As you can see from the above, it is not obvious to me "ar -s" makes any > > difference. > > > > It turns out that -s option does not has any effect for binutils ar, > which makes related test cases invalid in ar01 test. Nick Clifton > replied in the above bug report, > > > it is not obvious to me "ar -s" makes any different > > It doesn't. :-) > > It does make a difference on some versions of the ar program, notably > those on some Unix and Solaris systems. These versions of ar do not > automatically added a symbol index when the archive is created. But > the binutils ar automatically adds a symbol index when an archive is > created. So the -s option is supported mainly for backwards > compatibility with these other versions of ar. > > Since there is no way to test "-s", can we disable the above 2 test > cases written many years' ago to prevent false failures? >
Sure. Send the isolation patch :-) Regards-- Subrata > CAI Qian > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > High Quality Requirements in a Collaborative Environment. > Download a free trial of Rational Requirements Composer Now! > http://p.sf.net/sfu/www-ibm-com > _______________________________________________ > Ltp-list mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ltp-list ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
