Bug 127691
Summary: | boost libraries are in /usr/lib instead of /usr/lib64 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dag Wieers <dag> |
Component: | boost | Assignee: | Benjamin Kosnik <bkoz> |
Status: | CLOSED NEXTRELEASE | QA Contact: | |
Severity: | low | Docs Contact: | |
Priority: | medium | ||
Version: | 2 | CC: | mnewsome |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-03-16 23:14:31 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Dag Wieers
2004-07-12 16:50:27 UTC
This should be fixed with the -9 version of the package, in FC3. The boost rpm now uses _libdir, so this should be correct. Can you please confirm? best, benjamin Dag, I've updated boost to the 1.32.0 release. Can you confirm that these packages (should be pushed out soon) http://people.redhat.com/bkoz/boost-1.32.0/ Have fixed this issue? thanks, benjamin I made a quick rebuild on x86_64 and it seems ok. [root@lisse src]# rpm -qpl /tmp/x86_64/boost-1.32.0-1.x86_64.rpm /usr/lib64/libboost_date_time.so.1.32.0 /usr/lib64/libboost_filesystem.so.1.32.0 /usr/lib64/libboost_prg_exec_monitor.so.1.32.0 /usr/lib64/libboost_program_options.so.1.32.0 /usr/lib64/libboost_python.so.1.32.0 /usr/lib64/libboost_regex.so.1.32.0 /usr/lib64/libboost_signals.so.1.32.0 /usr/lib64/libboost_test_exec_monitor.so.1.32.0 /usr/lib64/libboost_thread.so.1.32.0 /usr/lib64/libboost_unit_test_framework.so.1.32.0 What worries me, is that the .so files are missing from the -devel package. I'm not sure if this is the intended behaviour, rpm silently ignores symlinks, so you may have forgotten them. If they don't exist, either you'll have unowned files in _libdir, or people cannot dynamically link to them at compile time. Dag, I understand your .so comment now. Fixing... |