Gentoo 32bit Mesa Overlay

[rohcQaH]

By the way, I just noticed this:

configure: error: Package requirements (libdrm_radeon >= 2.4.31) were not met:

Requested 'libdrm_radeon >= 2.4.31' but version of libdrm_radeon is 2.4.27

My 32bit libdrm is a current -9999 from today. 2.4.27 is the version of the installed 64bit libdrm. Is it possible to fix those configure checks, or would that be outside the scope of your "hack"?

[FireBurn]

By the way, I just noticed this:

My 32bit libdrm is a current -9999 from today. 2.4.27 is the version of the installed 64bit libdrm. Is it possible to fix those configure checks, or would that be outside the scope of your "hack"?

Hmm I'm not sure about this - have you considered running the 64bit libdrm too?

I prefer to keep my kernels, libdrm's and mesa's in sync

[FireBurn]

I've updated the repo quite a bit since my last post here

I've added stripped version of the x86 comparability ebuilds so you no longer have to override the collision detection

There's also an llvm ebuild so all the features should just work

[darkbasic]

Please update your readme on github

[FireBurn]

Please update your readme on github

That's it now fixed

[FireBurn]

Hi

I've stopped using this website entirely now so if you've experiencing any problems please see the main thread on the Gentoo forums or use github

http://forums.gentoo.org/viewtopic-t...ighlight-.html

https://github.com/FireBurn/Overlay

Thanks

[amzee83]

YAH Mesa Overlay

[s_j_newbury]

What's wrong with the Gentoo multilib overlay? (https://github.com/sjnewbury/multilib-overlay/wiki)

I was the maintainer of the above "multilib-native.eclass" based multilib overlay, portage-multilib* (availably through layman; and actively maintained) evolved from it since it put too much burden on ebuild maintainers (and being out of the portage tree, that meant myself and a handful of other volunteers). As I attempted to cover every USE-flag possibility stemming from replacing the emul-linux binary packages it quickly snowballed into an unmaintainable fork of pretty much all of Gentoo! While multilib-native is opt-in, and requires all package maintainers to care about multilib support, portage-multilib is transparent and opt-out since some packages require special handing due to issues with asm or non-free distributed binaries, or even simply don't work or don't make sense on all available ABIs.

*Just recently there is a new attempt to bring multilib to the main portage tree, again using eclass' and function wrappers, unfortunately it's currently incompatible with portage-multilib. See: http://article.gmane.org/gmane.linux.gentoo.devel/83365