Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 511628 - app-emulation/emul-linux-x86* should include libsdl2
Summary: app-emulation/emul-linux-x86* should include libsdl2
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: AMD64 Linux
: Normal enhancement (vote)
Assignee: Multilib team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-27 15:48 UTC by Roman S.
Modified: 2015-03-31 20:31 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
FS-UAE ebuild I currently use (fs-uae-2.5.5.ebuild,586 bytes, text/plain)
2014-05-27 16:57 UTC, Roman S.
Details
Adapted SDL 2.0 ebuild (libsdl2-2.0.3.ebuild,5.38 KB, text/plain)
2014-05-28 19:02 UTC, Roman S.
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roman S. 2014-05-27 15:48:46 UTC
I would like to ask for the inclusion of the SDL 2.0 (libsdl2) in the emul-linux-x86-sdl compatibility package (at least in ~amd64).

Reason: the FS-UAE emulator (http://fs-uae.net) - this is the best Amiga emulator for Linux and it's recent development releases require SDL 2.0 (1.x is no longer supported). The emulator is compatible with x86-64, but with one important exception: there is no JIT, which gives a great speedup, very useful if you want to play with the AmigaOS and its applications. The JIT is available only in the x86-32 builds, and I'm afraid it won't be 64-bit compatible anytime soon (there is no skilled developer willing to adapt it).
Comment 1 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-05-27 16:19:07 UTC
(CC-ing libsdl2 maintainer for opinion)

Seeing that uae and e-uae lack maintainer, I don't think fs-uae would enter Gentoo soon. While I don't mind adding the extra libraries, I'm not sure if we want to expand emul-linux-x86 on stuff that's not used by in-tree packages.

Would you be maybe interested in trying the ABI_X86=32 multilib? All SDL2 packages are multilib-capable so that would solve the immediate issue for you.
Comment 2 Roman S. 2014-05-27 16:57:13 UTC
Created attachment 377718 [details]
FS-UAE ebuild I currently use
Comment 3 Roman S. 2014-05-27 16:58:39 UTC
Regarding the 'multilib' - the Wiki (http://wiki.gentoo.org/wiki/Multilib/gx86-multilib) says: "Warning: This page describes an experimental feature in Gentoo, which may change significantly or be removed entirely in the future". I keep my system mostly stable (with few exceptions), so I definitely do not want to try anything like this.

Both UAE and E-UAE (which was a fork of UAE) are dead projects - in fact I'm surprised they are still in Portage. Currently maintained forks are WinUAE (Windows-only), PUAE and FS-UAE, all lacking x86-64 JIT.

The FS-UAE already has ebuilds in several overlays, so there is a chance it will enter Gentoo. I use a custom one (attached).
Comment 4 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-05-27 17:04:48 UTC
Well, you mentioned '~amd64' in the first post, so I assumed you are not using stable :). Multilib generally works on stable, though it's a bit PITA to set up since you need to unmask a lot of USE flags and some ~amd64 packages.
Comment 5 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-05-27 17:07:20 UTC
And honestly, I'd prefer if we added emul-linux-x86-sdl2 rather than rebuilding -sdl set.
Comment 6 Roman S. 2014-05-27 17:20:21 UTC
I keep the core packages stable - this is my main OS, so I prefer to avoid breakages which might be hard to fix. But I have no problems unmasking emulators, non-core libraries, web browsers, binary graphic card drivers, etc.

Adding emul-linux-x86-sdl2 would also be OK.
Comment 7 Mr. Bones. (RETIRED) gentoo-dev 2014-05-27 17:44:41 UTC
emul-linux-x86-sdl2 is definitely the right thing as opposed to adding libsdl2 to emul-linux-x86-sdl.  libsdl2 is a completely separate library (at least as far as upstream is concerned), not "just" a new version of libsdl.
Comment 8 Julian Ospald 2014-05-27 20:28:30 UTC
what for?

libsdl2 has multilib support, adding another set of emul-crap will complicate everything
Comment 9 Mr. Bones. (RETIRED) gentoo-dev 2014-05-28 02:15:04 UTC
"as opposed to adding libsdl2 to emul-linux-x86-sdl" is the important part.
Comment 10 Matthew Ogilvie 2014-05-28 05:54:19 UTC
If you are willing to tweak your own libsdl2 ebuild, it might be moderately easy to fix its dependencies so that you can install libsdl2 alongside (emul-linux with amd_x86_32 disabled), but enable amd_x86_32 for just libsdl2.

1. Customize libsdl2 ebuild dependencies:
    - SIMPLISTIC:
       - Start with a multilib-enabled version like libsdl2-2.0.3.ebuild.
       - Replace its RDEPEND and DEPEND settings with the non-multilib
         settings (for example, from libsdl2-2.0.2.ebuild).
       - Add appropriate emul-linux packages to RDEPEND. (emul-linux-x86-xlibs,
         at least).
    - BETTER: Update it to use "||" dependencies, similar to the
      wine ebuild, so it can work with or without emul-linux.  If
      you do this, post the ebuild and with luck it might be included
      in the tree.  This would be better than new or expanded
      emul-linux packages.

Then to use it:

2. Add "media-libs/libsdl2 amd_x86_32" to /etc/package.use

3. Fix your fs-uae ebuild DEPEND to read something like:

DEPEND=">=media-libs/libsdl2-2.0.0[joystick,opengl,X]
        amd64? ( media-libs/libsdl2[amd_x86_32] )
        media-libs/openal
        virtual/opengl
        media-libs/libpng
        dev-libs/glib:2
        sys-libs/zlib
        media-libs/freetype:2"

4. Make sure your fs-uae ebuild defaults to a 32-bit configuration even on a 64-bit system.

I don't think amd_x86_32 is masked for libsdl2, and none of the emul-linux packages try to supply libsdl2.  So you should NOT need to unmask amd_x86_32, fight the "everything potentially supplied by emul-linux needs the same amd_x86_32 setting" dependency hell, nor do anything else described in this linked writeup for running a mostly-stable system without any emul-linux packages: http://forums.gentoo.org/viewtopic-p-7509542.html?sid=c5b44664c998872c1c014477e22c3048#7509542 (although this might actually be the best solution if you don't want to modify the ebuild dependencies).

Also note that despite the scary warning in the referenced wiki page, I fully hope/expect that multilib is the way of the future, and once the conversion of the remaining packages is complete, emul-linux should be removed completely.  A lot of work has been put in already, and based on conversion rate I've been seeing, this could fairly easily be done less than a year from now.
Comment 11 Roman S. 2014-05-28 19:00:38 UTC
I went a BETTER way :) I have managed to adapt the libsdl2 ebuild, I will attach it in a moment,

I was also able to create a working 32-bit FS-UAE compilation using it (I still have some troubles to create a 32-bit forced FS-UAE ebuild using multilib-minimal eclass, but this is another story).
Comment 12 Roman S. 2014-05-28 19:02:57 UTC
Created attachment 377790 [details]
Adapted SDL 2.0 ebuild

Adapted SDL 2.0 ebuild, it allows 32-bit compilation on amd64 using emul-linux-x86-*
Comment 13 Matthew Ogilvie 2014-05-30 07:25:18 UTC
Regarding the SDL2 ebuild, I'm not a gentoo dev, so I'm not sure how important this is, but:

One possible criticism of your 2014-05-28 version of the SDL2 ebuild is that it will break dependencies for all the more obscure multilib abi's, such as the "x32" abi, or the various mips abi's (when/if mips is ever added to KEYWORDS).  Perhaps wine wasn't the best example to follow?

-----
Brainstorm of a possibly better solution:

Define a new variable similar to MULTILIB_USEDEP, but with abi_x86_32 explicitly removed (but all others kept).
   * See multilib-build.eclass for how it was defined in the first place.
   * Some clever parameter expansion logic might be able to do this without too much code, although it may be a little tricky. See "Parameter Expansion" in "man bash", especially "Remove matching suffix pattern" and "Pattern substitution".

Then use the new variable with all the atoms in NATIVE_[R]DEPEND, similar to how the original ebuild used MULTILIB_USEDEP.  NATIVE_[R]DEPEND can then be used directly (without conditions like "!amd64?"), and since it then probably only needs to be referenced once, it could probably just be directly inlined (eliminate the NATIVE_* variables).  The abi_x86_32 depenendencies (which can be supplied by emul-linux) can then be specified separately, like you've already done.

[It will be nice when emul-linux is finally removed, and such contortions will be unnecessary.]

------
More generally (eclass utility?):

Specializing dependencies for specific ABI's (especially abi_x86_32 and the emul-linux option) while using defaults for all others might be a common enough desire that it would be beneficial for an eclass (new or existing) to provide some help with it?

Perhaps a utility function that can robustly filter out specified ABI's from MULTILIB_USEDEP, or maybe something similar to MULTILIB_COMPAT (but inverted and outputs to a different variable instead of IUSE/MULTILIB_USEDEP).  

Incidentally, no ebuilds actually seem to set MULTILIB_COMPAT.  I expect pre-built libraries are just examining use flags directly to decide what binary packages to unpack and install, and not using multilib-build.eclass at all...
Comment 14 Roman S. 2014-06-14 19:17:07 UTC
If the emul-linux is really on its way to be removed, then I think adapting this ebuild further might be a waste of time... especially if this would have to be so tricky,
Comment 15 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-03-31 20:31:58 UTC
Lastrited!