Nish,
After getting libhugetlbfs 2.14 on SUT, which is RH 6.3 on ia64, still no luck.
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
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
Julius
-----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
