cc -O2 -pipe -Wall -I../../include -g -Wall -I../../../../include -Wall -Wl,-O1 -Wl,-z,now sgetmask01.c -L../../../../lib -lltp -o sgetmask01 sgetmask01.c: In function 'main': sgetmask01.c:142: error: '__NR_ssetmask' undeclared (first use in this function) sgetmask01.c:142: error: (Each undeclared identifier is reported only once sgetmask01.c:142: error: for each function it appears in.) make[4]: *** [sgetmask01] Error 1 make[4]: Leaving directory `/var/tmp/portage/app-benchmarks/ltp-20090531/work/ltp-full-20090531/testcases/kernel/syscalls/sgetmask' make[3]: *** [all] Error 2 make[3]: Leaving directory `/var/tmp/portage/app-benchmarks/ltp-20090531/work/ltp-full-20090531/testcases/kernel/syscalls' make[2]: *** [all] Error 2 make[2]: Leaving directory `/var/tmp/portage/app-benchmarks/ltp-20090531/work/ltp-full-20090531/testcases/kernel' make[1]: *** [all] Error 2 make[1]: Leaving directory `/var/tmp/portage/app-benchmarks/ltp-20090531/work/ltp-full-20090531/testcases' make: *** [all] Error 2 * * ERROR: app-benchmarks/ltp-20090531 failed. Looks like an incomplete / missing header.
the 20091031 snapshot has lots of changes in the configuration, needs some massaging.
Ping? Maybe update to the 2010 January version?
1. The January 2010 release is a good start, but make sure that the patch(es) are included which fix the clean regression as I noted in a reply to the release email before committing that version to portage. I asked Rishi to respin the tarball so other folks won't run into the clean target regression. I've attached the relevant email correspondence for future reference. Also, this masked warning is really irrelevant now, as a lot has changed since the October Makefile restructuring: !!! All ebuilds that could satisfy "app-benchmarks/ltp" have been masked. !!! One of the following masked packages is required to complete your request: - app-benchmarks/ltp-20090131 (masked by: package.mask, ~amd64 keyword) /usr/portage/profiles/package.mask: # Robin H. Johnson <robbat2@gentoo.org> (11 Mar 2006) # Work-in-progress to clean this up # TODO # - properly fix lazy bindings # - fix read-only stuff # - seperate data files from binaries # - fix crappy state of runnable only in source tree. # - provide log output to /var/log somewhere intelligently
Rishi, Could we respin the release tarball so that other folks don't stumble across this issue? The problem was worked around on the 2nd with this commit <http://ltp.cvs.sourceforge.net/viewvc/ltp/ltp/Makefile?revision=1.63&view=markup>, and it was solved with a series of additional commits on the 3rd. Thanks, -Garrett On Mon, Feb 15, 2010 at 10:24 PM, Scott Collins <scollins@promptu.com> wrote: > Hi Garret, > My name is Scott Collins and I am relatively new to ltp, but have been > building the ltp into a rpm for the past year or so. > Today I downloaded ltp-full-20100131 sources and now a lot of my file system > is gone. Thankyou backups ;-) > I googled around and noticed this post, but couldn't reply to it directly so > I will email you directly. > http://www.mail-archive.com/ltp-list@lists.sourceforge.net/msg09429.html > > It points to this really nasty line of code > > rm -f -Rf "/" > > and I have found the same code in my build output. > > [...] > make -C "lib" \ > -f "/home/pcl/BUILD/ltp-full-20100131/lib/Makefile" clean > make[2]: Entering directory `/home/pcl/BUILD/ltp-full-20100131/lib' > rm -f -f libltp.a *.o *.pyc > make[2]: Leaving directory `/home/pcl/BUILD/ltp-full-20100131/lib' > make -C include -f "/home/pcl/BUILD/ltp-full-20100131/include/Makefile" > clean > make[2]: Entering directory `/home/pcl/BUILD/ltp-full-20100131/include' > rm -f -f *.o *.pyc > make[2]: Leaving directory `/home/pcl/BUILD/ltp-full-20100131/include' > rm -f -Rf "/" > rm: cannot remove `//selinux/avc/cache_stats': Operation not permitted > rm: cannot remove `//selinux/avc/hash_stats': Operation not permitted > rm: cannot remove `//selinux/avc/cache_threshold': Operation not permitted > rm: cannot remove `//selinux/null': Operation not permitted > rm: cannot remove directory `//selinux/booleans': Operation not permitted > rm: cannot remove `//selinux/compat_net': Operation not permitted > rm: cannot remove `//selinux/checkreqprot': Operation not permitted > rm: cannot remove `//selinux/member': Operation not permitted > rm: cannot remove `//selinux/disable': Operation not permitted > rm: cannot remove `//selinux/mls': Operation not permitted > rm: cannot remove `//selinux/commit_pending_bools': Operation not permitted > rm: cannot remove `//selinux/policyvers': Operation not permitted > rm: cannot remove `//selinux/user': Operation not permitted > rm: cannot remove `//selinux/relabel': Operation not permitted > rm: cannot remove `//selinux/create': Operation not permitted > rm: cannot remove `//selinux/access': Operation not permitted > rm: cannot remove `//selinux/context': Operation not permitted > rm: cannot remove `//selinux/enforce': Operation not permitted > rm: cannot remove `//selinux/load': Operation not permitted > > I have traced it down to the top level makefile. > [ltp-full-20100131]$ grep -r RM * |grep Make|grep -v NORMAL_INSTALL|grep -v > NORMAL_UNINSTALL|grep Rf > Makefile: $(RM) -Rf "$(INSTALL_DIR)" > > Which leads me to the code in the Makefile. This, to me, indicates that the > INSTALL_DIR has been set to '/' > # Just in case configure hasn't been run yet, let's not overambitiously > remove > # the $(INSTALL_DIR). > .PHONY: clean_install_dir > clean_install_dir:: > $(RM) -Rf "$(INSTALL_DIR)" > > Is this a known issue? Is there something that I should have to do avoid > this? > > I checked the readme files and didnt notice that I have to set the > INSTALL_DIR to anything. Scott, I'm sorry to hear that happened :(.. that's happened to me before (under different circumstances), so I understand your pain.. Someone else reported that issue shortly after the tarball was released and I quickly fixed it, but unfortunately it was a bit too late to make it into the January release (<http://www.mail-archive.com/ltp-list@lists.sourceforge.net/msg09427.html>)... I did however reply to the general audience like so in the release email (<http://www.mail-archive.com/ltp-list@lists.sourceforge.net/msg09430.html>) with details on how to work around this issue, which functioned until I fixed the issue on the 3rd... HTH :\... -Garrett
+ 01 Mar 2010; Patrick Lauer <patrick@gentoo.org> +ltp-20100131.ebuild: + Bump, fixes #272660
