Announcement

Collapse
No announcement yet.

Gentoo 32bit Mesa Overlay

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • s_j_newbury
    replied
    Originally posted by RealNC View Post
    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

    Leave a comment:


  • amzee83
    replied
    YAH Mesa Overlay

    Leave a comment:


  • FireBurn
    replied
    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

    Leave a comment:


  • FireBurn
    replied
    Originally posted by darkbasic View Post
    Please update your readme on github
    That's it now fixed

    Leave a comment:


  • darkbasic
    replied
    Please update your readme on github

    Leave a comment:


  • FireBurn
    replied
    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

    Leave a comment:


  • FireBurn
    replied
    Originally posted by rohcQaH View Post
    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

    Leave a comment:


  • rohcQaH
    replied
    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"?

    Leave a comment:


  • FireBurn
    replied
    That's the mesa-32bit ebuild resynced with the x11 overlay

    Leave a comment:


  • FireBurn
    replied
    I have this in my make.conf

    Code:
    COLLISION_IGNORE="/usr/lib32 /lib32"
    I keep forgetting that's there

    Leave a comment:

Working...
X