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@redhat.com 2006-06-21 10:20 EST ------- Build attempts on FC5/x86_64 work if smp_mflags are disabled, though the resulting build fails to package:
RPM build errors: File not found by glob: /build/tmp/libhugetlbfs-20060619-1-root-jwilson/usr/lib64/*.so File not found by glob: /build/tmp/libhugetlbfs-20060619-1-root-jwilson/usr/lib64/ldscripts/* File not found by glob: /build/tmp/libhugetlbfs-20060619-1-root-jwilson/usr/lib64/*.a File not found: /build/tmp/libhugetlbfs-20060619-1-root-jwilson/usr/lib64/libhugetlbfs/tests File not found by glob: /build/tmp/libhugetlbfs-20060619-1-root-jwilson/usr/lib64/libhugetlbfs/tests/*
Looks like the bits were actually installed into /usr/lib/ instead of /usr/lib64/. The Makefile has:
ifeq ($(ARCH),x86_64) CC32 = gcc -m32 CC64 = gcc -m64 ELF32 = elf_i386 ELF64 = elf_x86_64 LIB32 = lib32 LIB64 = lib endif
For Fedora, that should be LIB32=lib and LIB64=lib64. After that change, less complaints, but the LDSCRIPTDIR is still hard-coded with lib instead of picking up lib or lib64.
You should have the diffs I emailed last night that contain my workarounds to get a package built on FC5/x86_64, though discussion is just getting started on how to handle the mixed 64-bit and 32-bit nature of this package on 64-bit platforms... (see email I just sent to fedora-extras-list).