| Summary: | libgio-2.0.so: undefined reference to `deflateSetHeader@ZLIB_1.2.2' (causing dbus-glib not to emerge) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jeffrey Ratcliffe <Jeffrey.Ratcliffe> |
| Component: | [OLD] Library | Assignee: | Gentoo Prefix <prefix> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build log
ltmain.sh libtool |
||
|
Description
Jeffrey Ratcliffe
2013-01-15 07:35:36 UTC
Can you attach the full build log, please? Created attachment 335888 [details]
build log
It's looking for 1.2.2 symbols, while it should be 1.2.5 (what we install), so I fear it's finding some zlib from the host provided system. Confirmed exactly the same bug on my Prefix RHEL5.5 This is rather strange. I can compile it on a another box with almost the same environment (not sure what's different, RHEL 5.6) I have some clue, could you please paste the contents of libtool in ${S}? And do you have ${EPREFIX}/usr/lib64 dir? what's inside that?
Created attachment 341286 [details]
ltmain.sh
S didn't have a libtool, attaching ltmain.sh instead.
Created attachment 341288 [details]
libtool
Attaching libtool from -build directory.
$ ls ${EPREFIX}/usr/lib64/
gcj-4.6.3-12 security
(In reply to comment #8) > Created attachment 341288 [details] > libtool > > Attaching libtool from -build directory. # Compile-time system search path for libraries. sys_lib_search_path_spec="/caehome/ra28145/rhel5-amd64-linux/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3 /caehome/ra28145/rhel5-amd64-linux/usr/x86_64-pc-linux-gnu/lib /caehome/ra28145/rhel5-amd64-linux/usr/lib64 /lib64 /usr/lib64 " The problem is here. If you look at the directories closely, there is no /caehome/ra28145/rhel5-amd64-linux/usr/lib entry, where all the libraries locate. > $ ls ${EPREFIX}/usr/lib64/ > gcj-4.6.3-12 security This is a bug, Prefix instance should never have usr/lib64 installed, even on amd64. Try the following workaround (merge lib64 to lib manually): $ mv ${EPREFIX}/usr/lib64/* ${EPREFIX}/usr/lib/ $ rmdir ${EPREFIX}/usr/lib64 $ ln -s ${EPREFIX}/usr/lib{,64} The rest of Prefix team may have insights on how usr/lib64 gets here. That allowed dev-libs/dbus-glib-0.100-r2 to emerge, thanks. Why should prefix instances never have usr/lib64 installed, even on amd64? Why is this OK on non-prefix instances? Should this bug therefore be retitled "prefix installs gcj-4.6.3-12 & security to lib64, rather than lib"? (In reply to comment #11) > That allowed dev-libs/dbus-glib-0.100-r2 to emerge, thanks. > > Why should prefix instances never have usr/lib64 installed, even on amd64? Gentoo Prefix started out like this and don't want to change. And the recent Debian's multiarch shows that lib64 is only an artifact. > Why is this OK on non-prefix instances? The developer of non-prefix wanted to obay LSB/FHS/amd64 ABI spec/whatever, and has a habbit of that already. > Should this bug therefore be retitled "prefix installs gcj-4.6.3-12 & > security to lib64, rather than lib"? The lib64 vs lib things has annoyed Prefix a lot before. There is no true policy saying we should use lib in Prefix for amd64. only the profile said so: $ grep LIB $EPREFIX/usr/portage/profiles/prefix/linux/amd64/make.defaults SYMLINK_LIB="" LIBDIR_amd64="lib" It is rather a historical remains than a reasoned choice. closing per comment #11 |
