| Summary: | x11-drivers/xf86-video-i810 linked bind NOW instead LAZY | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Gordon Malm (RETIRED) <gengor> |
| Component: | Current packages | Assignee: | Rémi Cardona (RETIRED) <remi> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | x11 |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
x11-drivers-xf86-video-i810-2.1.1-now.log
x11-drivers-xf86-video-i810-2.1.1-lazy.log |
||
|
Description
Gordon Malm (RETIRED)
2008-05-09 18:52:32 UTC
(In reply to comment #0) > http://archives.gentoo.org/gentoo-hardened/msg_06f2f741ab3e8fa7bbcb88fb85baa3ec.xml > http://archives.gentoo.org/gentoo-hardened/msg_1a0c7ecb930a7de89d95498941537c80.xml > http://archives.gentoo.org/gentoo-hardened/msg_2134167156515b0016553e300cc213d9.xml To be honest, I don't know the semantics of ELF libraries well enough to have a faint idea about : 1) what the overall objective is 2) what the problem is (specific to Xorg and i810) 3) what should be fixed Thanks We could always append-ldflags -Wl,-z,lazy/filter-ldflags -Wl,-z,now. However, I'm pretty sure this is supposed to be taken care of in an eclass (though I have not checked yet). I think someone on irc said they were having the same problem with another driver so the problem could be more widespread if it is in fact an eclass issue. We're in the same boat - my understanding of ELF headers, layout, etc. is only general/higher-level as read elsewhere/explained by others maintaining a low-level understanding. There's some more info regarding dlopen() issues here: http://www.gentoo.org/proj/en/hardened/hardenedxorg.xml x-modular.eclass should be taking care of this during x-modular_src_unpack() by calling x-modular_specs_check(). Gordon, could you provide a full build log? That'd be a big help. Thanks Created attachment 152985 [details]
x11-drivers-xf86-video-i810-2.1.1-now.log
Build log for:
FEATURES="-distcc" MAKEOPTS="-j3" emerge -1 xf86-video-i810:
XXXXXXX ~ # scanelf -a /usr/lib/xorg/modules/drivers/i810_drv.so
TYPE PAX PERM ENDIAN STK/REL/PTL TEXTREL RPATH BIND FILE
ET_DYN ---xe- 0755 LE RW- R-- RW- - - NOW /usr/lib/xorg/modules/drivers/i810_drv.so
Created attachment 152989 [details]
x11-drivers-xf86-video-i810-2.1.1-lazy.log
Build log for:
FEATURES="-distcc" MAKEOPTS="-j3" LDFLAGS="-Wl,-O1 -Wl,-z,lazy" emerge -1 xf86-video-i810:
XXXXXXX ~ # scanelf -a /usr/lib/xorg/modules/drivers/i810_drv.so
TYPE PAX PERM ENDIAN STK/REL/PTL TEXTREL RPATH BIND FILE
ET_DYN ---xe- 0755 LE RW- R-- RW- - - LAZY /usr/lib/xorg/modules/drivers/i810_drv.so
Could you try with 2.3.0? scanelf on my amd64 system shows that it's been linked as lazy. Thanks Finally took some time to look at the eclasses & ebuilds. The eclass is fine the problem is in the xf86-video-i810-2.1.1.ebuild. The ebuild overrides the eclass' x-modular_src_unpack() redefinition of src_unpack() with its own and only calls x-modular_unpack_source within. Adding x-modular_specs_check will fix the problem and should also be called any time this is done in one of the xf86 driver ebuilds.
Excerpt from xf86-video-i810-2.1.1 ebuild:
src_unpack() {
x-modular_unpack_source
epatch "${FILESDIR}/${PN}-2.1.1-fix_build_without_dri.patch"
}
As to the overall issue, I don't understand and can't explain it nearly as well as pageexec in the ML postings I linked. But it basically boils down to @ attempted driver load Xorg's loader is trying to resolve all symbols in the i810_drv.so (linked bind NOW). In this case it is trying to resolve EXA module/sub-module functions, which don't exist, even though they will never be used. When linked bind LAZY, the symbols are resolved as needed at runtime, rather than during attempted loading of the shared object. So if there exists an undefined symbol - its not a problem unless you actually try to use the fuction.
(In reply to comment #8) > Could you try with 2.3.0? scanelf on my amd64 system shows that it's been > linked as lazy. > > Thanks > Which is the correct/expected result as the 2.3.0 ebuild doesn't override src_unpack(). :) (In reply to comment #9) > Finally took some time to look at the eclasses & ebuilds. The eclass is fine > the problem is in the xf86-video-i810-2.1.1.ebuild. The ebuild overrides the > eclass' x-modular_src_unpack() redefinition of src_unpack() with its own and > only calls x-modular_unpack_source within. Adding x-modular_specs_check will > fix the problem and should also be called any time this is done in one of the > xf86 driver ebuilds. > > Excerpt from xf86-video-i810-2.1.1 ebuild: > src_unpack() { > x-modular_unpack_source > epatch "${FILESDIR}/${PN}-2.1.1-fix_build_without_dri.patch" > } Hmm, it should just do PATCHES="${FILESDIR}/${PN}-2.1.1-fix_build_without_dri.patch" and skip the src_unpack. I've dropped the silly src_unpack from portage. Everything should be fine now. Thanks |