On Sun 16 Mar 2014 04:50:33 Greg Turner wrote:
> cmake-multilib.eclass, for example, breaks in mind-warpingly subtle and
> confusing ways on USE="abi_x86_{32,64}" multilib hosts with
> i686-pc-linux-gnu crossdev installed (when combined with some other issues
> in that eclass, this results in correct qawarns about ignored ldflags on
> devel profiles -- an ugly work-around is in my overlay, but I'm not happy
> with it, so it's been languishing in my rainy-day todo queue. I'd be
> thrilled to see a solution to the underlying problem, so I don't feel
> compelled to salvage the ugly parts).
cmake is completely broken when it comes to library searching and multilib and
cross-compiling. it will happily look in hardcoded / paths to test for the
existence of files as well as directly execute `pkg-config`. it's a great
example of people saying "autotools is crap, so let's invent our own kind of
crap and ignore lessons learned". this isn't the fault of cmake eclasses, but
it'd be nice if we could someone standardize the hacks in there so we don't
have to duplicate across ebuilds.
just look at how cmake internally utilizes CMAKE_FIND_ROOT_PATH. or grep
"pkg-config" in /usr/share/cmake/. or look at find_library usage in cmake
macros. it's fundamentally screwed up right now :(.
> As for how to fix it, if foo-bar-baz-quux crossdev targets are at
> ${EROOT}/usr/foo-bar-baz-quux, putting wrappers in
> ${EROOT}/usr/foo-bar-baz-quux/cross-wrappers, or something like that, seems
> perfectly reasonable... heck, pure speculation, but it might even
> noticeably speed up day-to-day $PATH searching on systems with lots of
> crossdev targets installed.
if they're in $PATH, then the exact location is irrelevant. they need not be
in /usr/bin to cause a problem. if they're not in $PATH, then you're breaking
the cross-compilers and that is unacceptable.
putting CHOST things in /usr/CTARGET is incorrect. /usr/CHOST/CTARGET/ is for
hosting helper programs specific to CTARGET that run on CHOST.
-mike
signature.asc
Description: This is a digitally signed message part.
