[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: libhugetlbfs - easy access to huge pages of memory


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057





------- Additional Comments From jwilson at redhat.com  2006-06-21 14:27 EST -------
Okay, everything compiles on x86_64, but the package blows up. First, the
ldscripts directory isn't getting set to what the %files section expects. I'd
recommend possibly the following Makefile change:

--- libhugetlbfs-20060621.orig/Makefile 2006-06-21 11:00:26.000000000 -0400
+++ libhugetlbfs-20060621/Makefile      2006-06-21 14:27:05.000000000 -0400
@@ -20,16 +20,19 @@
 ELF64 = elf64ppc
 LIB32 = lib
 LIB64 = lib64
+BASELIB = $(LIB64)
 else
 ifeq ($(ARCH),ppc)
 CC32 = gcc
 ELF32 = elf32ppclinux
 LIB32 = lib
+BASELIB = $(LIB32)
 else
 ifeq ($(ARCH),i386)
 CC32 = gcc
 ELF32 = elf_i386
 LIB32 = lib
+BASELIB = $(LIB32)
 else
 ifeq ($(ARCH),x86_64)
 CC32 = gcc -m32
@@ -38,6 +41,7 @@
 ELF64 = elf_x86_64
 LIB32 = lib
 LIB64 = lib64
+BASELIB = $(LIB64)
 endif
 endif
 endif
@@ -52,7 +56,7 @@

 LIBDIR32 = $(DESTDIR)$(PREFIX)/$(LIB32)
 LIBDIR64 = $(DESTDIR)$(PREFIX)/$(LIB64)
-LDSCRIPTDIR = $(DESTDIR)$(PREFIX)/$(LIB32)/ldscripts
+LDSCRIPTDIR = $(DESTDIR)$(PREFIX)/$(BASELIB)/ldscripts
 BINDIR = $(DESTDIR)$(PREFIX)/bin
 DOCDIR = $(DESTDIR)$(PREFIX)/share/doc/libhugetlbfs

This change puts ldscripts where x86_64 expects them, but all the 32-bit
components are still getting built and installed where rpm isn't expecting them:

RPM build errors:
    Installed (but unpackaged) file(s) found:
   /usr/lib/libhugetlbfs.a
   /usr/lib/libhugetlbfs.so
   /usr/lib/libhugetlbfs/tests/obj32/alloc-instantiate-race
   /usr/lib/libhugetlbfs/tests/obj32/chunk-overcommit
   /usr/lib/libhugetlbfs/tests/obj32/dummy
   /usr/lib/libhugetlbfs/tests/obj32/empty_mounts
   /usr/lib/libhugetlbfs/tests/obj32/find_path
   /usr/lib/libhugetlbfs/tests/obj32/gethugepagesize
   /usr/lib/libhugetlbfs/tests/obj32/icache-hygeine
   /usr/lib/libhugetlbfs/tests/obj32/linkhuge
   /usr/lib/libhugetlbfs/tests/obj32/linkhuge_nofd
   /usr/lib/libhugetlbfs/tests/obj32/linkshare
   /usr/lib/libhugetlbfs/tests/obj32/malloc
   /usr/lib/libhugetlbfs/tests/obj32/malloc_manysmall
   /usr/lib/libhugetlbfs/tests/obj32/meminfo_nohuge
   /usr/lib/libhugetlbfs/tests/obj32/mlock
   /usr/lib/libhugetlbfs/tests/obj32/mmap-cow
   /usr/lib/libhugetlbfs/tests/obj32/mmap-gettest
   /usr/lib/libhugetlbfs/tests/obj32/mprotect
   /usr/lib/libhugetlbfs/tests/obj32/private
   /usr/lib/libhugetlbfs/tests/obj32/ptrace-write-hugepage
   /usr/lib/libhugetlbfs/tests/obj32/readback
   /usr/lib/libhugetlbfs/tests/obj32/shared
   /usr/lib/libhugetlbfs/tests/obj32/shm-fork
   /usr/lib/libhugetlbfs/tests/obj32/shm-getraw
   /usr/lib/libhugetlbfs/tests/obj32/shm-gettest
   /usr/lib/libhugetlbfs/tests/obj32/slbpacaflush
   /usr/lib/libhugetlbfs/tests/obj32/test_root
   /usr/lib/libhugetlbfs/tests/obj32/truncate
   /usr/lib/libhugetlbfs/tests/obj32/unlinked_fd
   /usr/lib/libhugetlbfs/tests/obj32/xB.linkhuge
   /usr/lib/libhugetlbfs/tests/obj32/xB.linkhuge_nofd
   /usr/lib/libhugetlbfs/tests/obj32/xB.linkshare
   /usr/lib/libhugetlbfs/tests/obj32/xBDT.linkhuge
   /usr/lib/libhugetlbfs/tests/obj32/xBDT.linkhuge_nofd
   /usr/lib/libhugetlbfs/tests/obj32/xBDT.linkshare
   /usr/lib/libhugetlbfs/tests/obj32/zero_filesize_segment
   /usr/lib/libhugetlbfs/tests/run_tests.sh

It looks like what we'd really like to do for Fedora Extras is have only the
64-bit pieces built for the x86_64 package, and the 32-bit pieces built in the
i386 package, but then make both available in the x86_64 tree, so what do you
think about another Makefile target that builds only the platform's native
binaries? We could kludge around it by using %exclude statements in the spec
file as well, but a rh-install target seems cleaner.

-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.