One more piece of info: I could not find glibc-static in RH based repos and Nish found it here:
http://pkgs.org/centos-6-rhel-6/centos-rhel-x86_64/glibc-static-2.12-1.80.el6.x86_64.rpm.html Julius -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Gawlas, Julius Sent: Tuesday, October 16, 2012 10:25 AM To: Nishanth Aravamudan Cc: Andrew Hastings; [email protected] Subject: Re: [Autotest] libhugetlbfs tests Just FYI, Nish led me to successful run of latest libhugetlbfs (needed libpthread.a from glibc-static installed) and as suggested run $ make BUILDTYPE=NATIVEONLY $ make BUILDTYPE=NATIVEONLY check Should the libhugetlbfs test be adjusted to: - include latest libhugetlbfs - run make with BUILDTYPE=NATIVEONLY - require static libpthread.a Julius -----Original Message----- From: Nishanth Aravamudan [mailto:[email protected]] Sent: Tuesday, October 16, 2012 12:28 AM To: Gawlas, Julius Cc: [email protected]; Andrew Hastings Subject: Re: [Autotest] libhugetlbfs tests Hi Julius, On 16.10.2012 [05:32:13 +0000], Gawlas, Julius wrote: > Nish, > > After getting libhugetlbfs 2.14 on SUT, which is RH 6.3 on ia64, still > no luck. Interesting, I admittedly only check on amd64. > I must be really missing something: > > $ make BUILDTYPE=NATIVEONLY check > ... > LD64 (lib test) obj64/shmoverride_linked_static > /usr/bin/ld: cannot find -lpthread > collect2: ld returned 1 exit status > make[1]: *** [obj64/shmoverride_linked_static] Error 1 > make: *** [tests/all] Error 2 Well, this is a different error, at least. > this is on RH 6.3 server on 64 bit system > > $ uname -a > Linux mintbl04.cce.hp.com 2.6.32-279.el6.x86_64 #1 SMP Wed Jun 13 > 18:24:36 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux > > $ whereis libpthread > libpthread: /usr/lib64/libpthread.so Ah, but that's the dynamic libpthread! I think you need to also have a static compatible one for the build to succeed? passing V=3 to the `make` commands may help give more info too. Thanks, Nish > -----Original Message----- > From: Nishanth Aravamudan [mailto:[email protected]] > Sent: Monday, October 15, 2012 6:04 PM > To: Gawlas, Julius > Cc: [email protected]; Andrew Hastings > Subject: Re: [Autotest] libhugetlbfs tests > > On 16.10.2012 [00:57:01 +0000], Gawlas, Julius wrote: > > Nish, > > > > Nice way out. > > > > If "make BUILDTYPE=NATIVEONLY check" works then perhaps this is what > > autotest wrapper should do? I will test that with 2.14 in our setup > > and report back, probably tomorrow. > > I don't see why it wouldn't work. That support was added in 2006 or > 2007 > :) > > -Nish > > > Thanks for quick turnaround. > > > > Julius > > > > -----Original Message----- > > From: Nishanth Aravamudan [mailto:[email protected]] > > Sent: Monday, October 15, 2012 5:17 PM > > To: Gawlas, Julius > > Cc: [email protected]; Andrew Hastings > > Subject: Re: [Autotest] libhugetlbfs tests > > > > Hi Julius, > > > > On 15.10.2012 [23:21:37 +0000], Gawlas, Julius wrote: > > > Nish, > > > > > > (not knowing much about libhugetlbfs) > > > > > > FYI, previous version 2.0 was built in exactly the same way on the same > > > system and it just worked without 32 bit; the autotest wrapper file > > > actually does this: > > > > > > # make check might fail for 32 bit if the 32 bit compile earlier > > > # had failed. See if it passes for 64 bit in that case. > > > try: > > > utils.make('check') > > > except Exception: > > > utils.make('check OBJDIRS=obj64') > > > > > > and I could see in the log ion that SUT that 32 bit fails bc there > > > is no 32 bit and proceeds to 64 bit check; > > > > > > For 2.14 we get error as specified below so the behavior changed. > > > > Alright, now I see. Andrew (added to Cc), I think commit > > 319122ba1f31cf5804901ec078dab5491f9202be (tests: add support for > > static > > linking) breaks this model. Without 32-bit prereqs installed, > > OBJDIRS=obj64 (effectively specifying only building the 64-bit versions of > > tests) still results in an attempt to build the 32-bit static > > shmoverride_linked test. > > > > Confirmed that the following here prevents the build failure: > > > > diff --git a/tests/Makefile b/tests/Makefile index cb15767..c36e467 > > 100644 > > --- a/tests/Makefile > > +++ b/tests/Makefile > > @@ -82,7 +82,7 @@ endif > > # dlsym() / rtld_next(). > > ifdef CC32 > > #ALLTESTS += $(LIB_TESTS:%=obj32/%_static) > > $(STRESS_TESTS:%=obj32/%_static) -ALLTESTS += > > obj32/shmoverride_linked_static > > +#ALLTESTS += obj32/shmoverride_linked_static > > endif > > ifdef CC64 > > #ALLTESTS += $(LIB_TESTS:%=obj64/%_static) > > $(STRESS_TESTS:%=obj64/%_static) > > > > Maybe what should happen is that you need to test both that CC32 and that > > obj32 is in OBJDIRS? Similarly for the CC64 test, I suppose, for > > completeness? That is, the presence of a suitable compiler isn't > > necessarily an indicator. > > > > Ah! Julius, there is another option if libhugetlbfs stays the way it is: > > > > make BUILDTYPE=NATIVEONLY check > > > > That prevents the definition in the Makefile of the CC32 variable > > (basically, just says only build the 64-bit versions for 64-bit > > architectures, 32-bit for 32-bit architectures, afaict). > > > > Thanks, > > Nish > > > > > >I guess you can install those 32-bit prereqs to satisfy the build > > > > > > Indeed we could, but perhaps it is better (?) if it can be run on 64 bit > > > system w/o that as it was the case before. > > > > > > Thanks for looking into that. > > > > > > Julius > > > > > > > > > -----Original Message----- > > > From: Nishanth Aravamudan [mailto:[email protected]] > > > Sent: Monday, October 15, 2012 4:01 PM > > > To: Gawlas, Julius > > > Cc: [email protected] > > > Subject: Re: [Autotest] libhugetlbfs tests > > > > > > On 15.10.2012 [19:14:04 +0000], Gawlas, Julius wrote: > > > > We are running nightly tests suite that exercises new kernel and > > > > one of the tests is libhugetlbfs. We are plugging in into > > > > standard libhugetlbfs using libhugetlbfs-2.0.tar.gz. We have > > > > seen lately intermittent problems where the suite will just hang > > > > somewhere in the middle of > > > > > > > > $ make check OBJDIRS=obj64 > > > > ... > > > > linkhuge_rw > > > > > > > > (Note that we don't really know much about that test, we just > > > > picked it up as part of regression suite) > > > > > > > > After checking the libhugetlbfs site it turns out latest library > > > > is libhugetlbfs-2.14, so we picked it up and attempted to run > > > > tests based on that. But on 64 bits this fails as well: > > > > > > > > $ make check OBJDIRS=obj64 > > > > LD64 (lib test) obj64/huge_below_4GB_normal_above > > > > CC32 obj32/shmoverride_linked.o > > > > stderr: > > > > /usr/bin/ld: warning: zero_filesize_segment.ld contains output > > > > sections; did you forget -T? > > > > In file included from /usr/include/features.h:385, > > > > from /usr/include/sys/types.h:26, > > > > from shmoverride_linked.c:18: > > > > /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or > > > > directory > > > > make[1]: *** [obj32/shmoverride_linked.o] Error 1 > > > > make: *** [tests/all] Error 2 > > > > > > So this is a bit confusing, if you look at the output, you > > > specified you wanted the 64-bit binaries to be built and the > > > 32-bit binaries are being built as well. But your env doesn't > > > appear to have the 32-bit requirements. I guess you can install > > > those 32-bit prereqs to satisfy the build. I'm trying remember my > > > libhuge history, but I don't think the tests were ever meant to be > > > built only 64-bit. They could be built only 32-bit (I think), but > > > if you built 64-bit, 32-bit was also tested. I might be wrong, I > > > will try to look at the source a little later. > > > > > > > Mailing list archive for libhugetlbfs seems to be filled with spam. > > > > > > FWIW, yes, filled with spam and very idle, but I think technically still > > > active. No guarantees, although if you send a message there and I see it, > > > I will respond immediately so you'll know it got through. > > > > > > > Anybody can help or shed any light on this? Any help or pointers > > > > would be appreciated. Is that test bogus? > > > > > > > > Julius > > > > > > > > _______________________________________________ > > > > Autotest-kernel mailing list > > > > [email protected] > > > > https://www.redhat.com/mailman/listinfo/autotest-kernel > > > > > > > > > > _______________________________________________ Autotest-kernel mailing list [email protected] https://www.redhat.com/mailman/listinfo/autotest-kernel _______________________________________________ Autotest-kernel mailing list [email protected] https://www.redhat.com/mailman/listinfo/autotest-kernel
