[LLVMbugs] [Bug 6713] New: autotools are not honoring LIBDIR settings
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Fri Mar 26 10:52:33 PDT 2010
http://llvm.org/bugs/show_bug.cgi?id=6713
Summary: autotools are not honoring LIBDIR settings
Product: clang
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P
Component: Static Analyzer
AssignedTo: kremenek at apple.com
ReportedBy: herrold at owlriver.com
CC: llvmbugs at cs.uiuc.edu
Red Hat multilib distinguishes /usr/lib/ and /usr/lib64
Putting questions on their design choices to one side (there are arguments for
this which are sensible) ;) ) I end up having to add manual entries for
packaging what LIBDIR should posution correctly automatically
...
Processing files: clang-debuginfo-0.0.20100326.cvs-1orc
Provides: libCIndex.so.debug()(64bit) libEnhancedDisassembly.so.debug()(64bit)
libLLVMHello.so.debug()(64bit) libLTO.so.debug()(64bit)
libprofile_rt.so.debug()(64bit)
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Checking for unpackaged file(s): /usr/lib/rpm/check-files
/var/tmp/clang-0.0.20100326.cvs.root
error: Installed (but unpackaged) file(s) found:
/usr/lib/clang/1.5/include/emmintrin.h
/usr/lib/clang/1.5/include/float.h
/usr/lib/clang/1.5/include/iso646.h
/usr/lib/clang/1.5/include/limits.h
/usr/lib/clang/1.5/include/mm_malloc.h
/usr/lib/clang/1.5/include/mmintrin.h
/usr/lib/clang/1.5/include/nmmintrin.h
/usr/lib/clang/1.5/include/pmmintrin.h
/usr/lib/clang/1.5/include/smmintrin.h
/usr/lib/clang/1.5/include/stdarg.h
/usr/lib/clang/1.5/include/stdbool.h
/usr/lib/clang/1.5/include/stddef.h
/usr/lib/clang/1.5/include/stdint.h
/usr/lib/clang/1.5/include/tgmath.h
/usr/lib/clang/1.5/include/tmmintrin.h
/usr/lib/clang/1.5/include/varargs.h
/usr/lib/clang/1.5/include/xmmintrin.h
RPM build errors:
File not found:
/var/tmp/clang-0.0.20100326.cvs.root/usr/lib/clang/1.1/include
Installed (but unpackaged) file(s) found:
/usr/lib/clang/1.5/include/emmintrin.h
/usr/lib/clang/1.5/include/float.h
/usr/lib/clang/1.5/include/iso646.h
/usr/lib/clang/1.5/include/limits.h
/usr/lib/clang/1.5/include/mm_malloc.h
/usr/lib/clang/1.5/include/mmintrin.h
/usr/lib/clang/1.5/include/nmmintrin.h
/usr/lib/clang/1.5/include/pmmintrin.h
/usr/lib/clang/1.5/include/smmintrin.h
/usr/lib/clang/1.5/include/stdarg.h
/usr/lib/clang/1.5/include/stdbool.h
/usr/lib/clang/1.5/include/stddef.h
/usr/lib/clang/1.5/include/stdint.h
/usr/lib/clang/1.5/include/tgmath.h
/usr/lib/clang/1.5/include/tmmintrin.h
/usr/lib/clang/1.5/include/varargs.h
/usr/lib/clang/1.5/include/xmmintrin.h
============================
when called thus:
CFLAGS="-g0 -O2 -pipe" ./configure \
--prefix=%{prefix} \
--libexecdir=%{_bindir} \
--libdir=%{_libdir} \
...
make DESTDIR=%{buildroot} \
prefix=%{_prefix} \
libdir=%{_libdir}
...
make DESTDIR=%{buildroot} install \
prefix=%{_prefix} \
libdir=%{_libdir}
and in my buildsystem, %{_libdir} expands (there is an inheritance chain) to:
[herrold at centos-5 clang]$ rpm --showrc | grep ": _libdir"
-14: _libdir %{_exec_prefix}/%{_lib}
[herrold at centos-5 clang]$ rpm --showrc | grep ": _exec_prefix"
-14: _exec_prefix %{_prefix}
[herrold at centos-5 clang]$ rpm --showrc | grep ": _prefix"
-14: _prefix /usr
[herrold at centos-5 clang]$
[herrold at centos-5 clang]$ uname -a
Linux centos-5.first.lan 2.6.18-164.11.1.el5xen #1 SMP Wed Jan 20 08:06:04 EST
2010 x86_64 x86_64 x86_64 GNU/Linux
[herrold at centos-5 clang]$
not critical, but the appearance of /1.5/ along side the already crufty /1.1/
caused an unnecessary lost 3 hr build cycle for me ;(
where I had to add the hardcoded (and wrong, to autotool's view of what should
have been a value the system could have figured out if the expansion had been
followed)
...
# /usr/lib/clang/1.1/include/emmintrin.h
# %{_libdir}/clang/1.1/include/
# here: does not follow RH's opinions on multi-lib
/usr/lib/clang/1.1/include/
/usr/lib/clang/1.5/include/
...
-- Russ herrold
Thanks
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the llvm-bugs
mailing list