| Summary: | media-libs/gstreamer: multilib | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Austin English (RETIRED) <wizardedit> |
| Component: | Current packages | Assignee: | GStreamer package maintainers <gstreamer> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | multilib+disabled |
| Priority: | Normal | Keywords: | NeedPatch |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 454644, 484248, 496374, 498010 | ||
|
Description
Austin English (RETIRED)
2013-12-02 22:43:03 UTC
There would be more than one problem with this: 1. wine still uses gstreamer 0.10 (well, so is the mozilla family, but that's not really in favor of either) 2. gstreamer herd has but a few devs on it 3. the real problem is not gstreamer itself, but its plugins (with deps) 4. it's kind of moot till http://bugs.winehq.org/show_bug.cgi?id=30557 is fixed Alternatively, could wine upstream consider working towards making 32bit wine work with 64bit libs on 64bits arch ? After all, it's not as if 64bit Windows is quite the same as 64bit Linux (in LLP64 vs LP64 context). (this is more of a question - I don't really know if it would be technically possible to implement this) I'd say the good thing with plugins is that you don't need to convert them all :). Once gstreamer itself is 32-bit capable, we may migrate remaining plugins as necessary or along with dependent libraries. Anyway, we're around to help and when we'll find some time, we'll prepare a patch for the ebuild. (In reply to Rafał Mużyło from comment #1) > There would be more than one problem with this: > 1. wine still uses gstreamer 0.10 (well, so is the mozilla family, but > that's not really in favor of either) > 2. gstreamer herd has but a few devs on it > 3. the real problem is not gstreamer itself, but its plugins (with deps) > 4. it's kind of moot till http://bugs.winehq.org/show_bug.cgi?id=30557 is > fixed Yeah, this particular package isn't as important (marking as minor). Most of the important dependencies are already done, the only big ones left for wine are libxml2 (bug 480404) and libxslt (bug 480402). > Alternatively, could wine upstream consider working towards making 32bit > wine work with 64bit libs on 64bits arch ? After all, it's not as if 64bit > Windows is quite the same as 64bit Linux (in LLP64 vs LP64 context). (this > is more of a question - I don't really know if it would be technically > possible to implement this) It's not, 32-bit wine dynamically uses the 32-bit native libraries. (In reply to austinenglish@gmail.com from comment #3) > > Alternatively, could wine upstream consider working towards making 32bit > > wine work with 64bit libs on 64bits arch ? After all, it's not as if 64bit > > Windows is quite the same as 64bit Linux (in LLP64 vs LP64 context). (this > > is more of a question - I don't really know if it would be technically > > possible to implement this) > > It's not, 32-bit wine dynamically uses the 32-bit native libraries. Don't quite know why, but this sounds like an answer to a different question than the one I've asked. AFAIU, 64bit wine uses 64bit libs (correct me, if I'm wrong here). My question was "is there a technical problem (aside of time needed to rewrite portions on the loader and redoing the checks to the code that were done during writing 64bit wine in the other direction) preventing 32bit wine from being used on top of 64bit libraries ?". Or more exactly "would such a rewrite be impossible due to technical reasons or simply involving too much work for upstream to bother (at this time) ?". Note, I'm not asking about the current state, just long-term options. (In reply to Rafał Mużyło from comment #4) > (In reply to austinenglish@gmail.com from comment #3) > > > Alternatively, could wine upstream consider working towards making 32bit > > > wine work with 64bit libs on 64bits arch ? After all, it's not as if 64bit > > > Windows is quite the same as 64bit Linux (in LLP64 vs LP64 context). (this > > > is more of a question - I don't really know if it would be technically > > > possible to implement this) > > > > It's not, 32-bit wine dynamically uses the 32-bit native libraries. > > Don't quite know why, but this sounds like an answer to a different question > than the one I've asked. > AFAIU, 64bit wine uses 64bit libs (correct me, if I'm wrong here). My > question was "is there a technical problem (aside of time needed to rewrite > portions on the loader and redoing the checks to the code that were done > during writing 64bit wine in the other direction) preventing 32bit wine from > being used on top of 64bit libraries ?". Or more exactly "would such a > rewrite be impossible due to technical reasons or simply involving too much > work for upstream to bother (at this time) ?". > > Note, I'm not asking about the current state, just long-term options. 64-bit Wine (/usr/bin/wine64) can *only* run 64-bit Windows executables. In order to run a 32-bit executable, you must use 32-bit Wine (/usr/bin/wine). When built together (in the manner that the current wine ebuild does), each version will call the other if the wrong type of executable is passed. The 32-bit Wine in /usr/bin/wine is a 32-bit ELF executable, which needs 32-bit libs for everything, and runs under the Linux kernel's 32-bit executable support (different syscalls, etc.). (In reply to Rafał Mużyło from comment #4) > (In reply to austinenglish@gmail.com from comment #3) > > > Alternatively, could wine upstream consider working towards making 32bit > > > wine work with 64bit libs on 64bits arch ? After all, it's not as if 64bit > > > Windows is quite the same as 64bit Linux (in LLP64 vs LP64 context). (this > > > is more of a question - I don't really know if it would be technically > > > possible to implement this) > > > > It's not, 32-bit wine dynamically uses the 32-bit native libraries. > > Don't quite know why, but this sounds like an answer to a different question > than the one I've asked. > AFAIU, 64bit wine uses 64bit libs (correct me, if I'm wrong here). My > question was "is there a technical problem (aside of time needed to rewrite > portions on the loader and redoing the checks to the code that were done > during writing 64bit wine in the other direction) preventing 32bit wine from > being used on top of 64bit libraries ?". Or more exactly "would such a > rewrite be impossible due to technical reasons or simply involving too much > work for upstream to bother (at this time) ?". Well, I'm not the best specialist in the area but I think it's possible. However, it'd require wine to run some kind of 64-bit translating daemon that would do the library calls for wine and return the results. Also, I don't know if it's possible to have shared memory between 64-bit and 32-bit process. So while it sounds possible, I'd say it: * requires a lot of work since you practically need to wrap all libraries, * would make wine slower, * and if it's not possible to share memory between the processes, it will make it even more slower and resource-hungry (since you'd have to copy all the memory back and forth). I wouldn't say it's nowhere close to wanted to play with this. What I've meant was that as 64bit Windows is significantly different from 64bit Linux, where would lie the difficulty of turning 32bit wine on 64bit arches into a 64bit executable. (In reply to Michał Górny from comment #2) > Anyway, we're around to help and when we'll find some time, we'll prepare a > patch for the ebuild. poke poke :) But gor any actual good use, we need at the very least multilib also: media-libs/gst-plugins-base media-libs/gst-plugins-good media-libs/gst-plugins-bad media-libs/gst-plugins-ugly media-plugins/gst-plugins-libav media-plugins/gst-plugins-pulse ... but I'd expect media-plugins all to be handled in one swoop with some eclass changes. Also not interested in doing any of this to 0.10 - which means for it to be useful for wine use cases, it needs to start using 1.x (if it already isn't) and the referenced >=glib-2.32 issue fixed. (In reply to Mart Raudsepp from comment #8) > But gor any actual good use, we need at the very least multilib also: > > media-libs/gst-plugins-base > media-libs/gst-plugins-good > media-libs/gst-plugins-bad > media-libs/gst-plugins-ugly > media-plugins/gst-plugins-libav > media-plugins/gst-plugins-pulse > ... but I'd expect media-plugins all to be handled in one swoop with some > eclass changes. > As long as the dependencies are ready, it should be quite simple, but... > Also not interested in doing any of this to 0.10 - which means for it to be > useful for wine use cases, it needs to start using 1.x (if it already isn't) > and the referenced >=glib-2.32 issue fixed. LOL : upstream #31836 (opened 2012-09-30 08:07 CDT) and the already mentioned #30557 (opened on 2012-04-30 11:14 CDT - this one at least has a patch, though a bit invasive one). I've looked a bit at winegstreamer code, but it's quite a bit above my small gstreamer understanding, as a port would involve quite a bit of shifting code from callback functions to new queries. I've got a quick stab of these in the FireBurn overlay I'm actively working with gst team on this, and I'd dare say it should be done before the next week. (In reply to Michał Górny from comment #11) > I'm actively working with gst team on this, and I'd dare say it should be > done before the next week. A full complement of multilib gstreamer ebuilds has been in my overlay for ages. Some of them are out of date but I'm fixing that up now. I used autotools-multilib. Although my versions are not trivially portable to upstream, the truly "novel" aspects of my multilibutization are not many and may be instructive to upstream multilibutizers. I'll try to summarize them below: First, gtk-doc is universally all fucked up for multilib. Normally I have a gtk-doc eclass to fix this up but it doesn't work for gstreamer. So for gstreamer, I do the equivalent "manually," in a patch in filesdir. The patch is wide and probably won't fit nicely here so, here's a link (two actually, one for each slot): http://git.overlays.gentoo.org/gitweb/?p=user/gmt.git;a=blob_plain;f=media-libs/gstreamer/files/gstreamer-0.10.36-OOT-gtkdoc-install-hack.patch;hb=HEAD http://git.overlays.gentoo.org/gitweb/?p=user/gmt.git;a=blob_plain;f=media-libs/gstreamer/files/gstreamer-0.10.36-OOT-gtkdoc-install-hack.patch;hb=HEAD Additionally, I supply --disable-maintainer-mode and --disable-gtk-doc configure arguments. I can't remember the reason, for sure, but this likely was related. This also requires autoreconf. Second, I do the following during src_prepare: # Patch ugly configure sed hack (by means of ugly sed configure hack), # to (hopefully) work when building OOT (untested on win32) sed -e '/^sed \\$/imkdir -p win32/common' \ -e 's|^\([[:space:]]*\)\(config.h.in >win32/common/config.h-new\)|\1${srcdir}/\2|' \ -i configure{.ac,} || die configure OOT sed patch failed hope that didn't get chopped up -- if so you can see it i.e., here: http://git.overlays.gentoo.org/gitweb/?p=user/gmt.git;a=blob;f=media-libs/gstreamer/gstreamer-1.2.3-r1.ebuild;h=478411fac0a6077fef358c618d9a9c862fb62346;hb=HEAD#l35 IIRC the same sed hack worked in both slots. That may not be particularly important or even a multilib issue at all -- I think I mostly found the build to be aesthetically displeasing without that patch. Thirdly, as of 1.2.4 I started seeing gmsgfmt build errors. I suspect they are not multilib related but then again I didn't see anyone else with the same problem anywhere on the interweb. I had to apply this patch for that: diff -urpN gstreamer-1.2.4.orig/po/hr.po gstreamer-1.2.4/po/hr.po --- gstreamer-1.2.4.orig/po/hr.po 2014-06-06 12:34:04.508442631 -0700 +++ gstreamer-1.2.4/po/hr.po 2014-06-06 12:35:55.665338919 -0700 @@ -10,7 +10,7 @@ msgstr "" "PO-Revision-Date: 2012-05-25 16:47+0200\n" "Last-Translator: Tomislav Krznar <tomislav.krznar@gmail.com>\n" "Language-Team: Croatian <lokalizacija@linux.hr>\n" -"Language: \n" +"Language: hr\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" diff -urpN gstreamer-1.2.4.orig/po/nb.po gstreamer-1.2.4/po/nb.po --- gstreamer-1.2.4.orig/po/nb.po 2014-06-06 12:39:29.677202264 -0700 +++ gstreamer-1.2.4/po/nb.po 2014-06-06 12:40:24.619652212 -0700 @@ -10,7 +10,7 @@ msgstr "" "PO-Revision-Date: 2010-10-24 21:36+0200\n" "Last-Translator: Kjartan Maraas <kmaraas@gnome.org>\n" "Language-Team: Norwegian Bokmaal <i18n-nb@lister.ping.uio.no>\n" -"Language: \n" +"Language: nb\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" Unfortunately, gstreamer requires dev-libs/gobject-introspection with the introspection use-flag. That is a very hard thing to multilibutize. I have it working but had to resort to some truly questionable hacks, perhaps they are the worst thing in my overlay. So upstream probably should just use $(multilib_native_use_enable introspection). The only way to really fix gobject-introspection, imo, is to split g-ir-scanner into a separate, non-multilib ebuild, and strip it out of the dev-libs/gobject-introspection autotools build scripts entirely. For gstreamer itself, that's all there was to it. I'll document the eclass level changes I implemented in a subsequent comment, for the moment I'm out of time... (In reply to Greg Turner from comment #12) > First, gtk-doc is universally all fucked up for multilib. Normally I have a > gtk-doc eclass to fix this up but it doesn't work for gstreamer. So for > gstreamer, I do the equivalent "manually," in a patch in filesdir. The > patch is wide and probably won't fit nicely here so, here's a link (two > actually, one for each slot): > > http://git.overlays.gentoo.org/gitweb/?p=user/gmt.git;a=blob_plain;f=media- > libs/gstreamer/files/gstreamer-0.10.36-OOT-gtkdoc-install-hack.patch;hb=HEAD > > http://git.overlays.gentoo.org/gitweb/?p=user/gmt.git;a=blob_plain;f=media- > libs/gstreamer/files/gstreamer-0.10.36-OOT-gtkdoc-install-hack.patch;hb=HEAD second should read: http://git.overlays.gentoo.org/gitweb/?p=user/gmt.git;a=blob_plain;f=media-libs/gstreamer/files/gstreamer-1.2.0-OOT-gtkdoc-install-hack.patch;hb=HEAD On the eclass side of things I implemented two mutually exclusive mechanisms. I doubt the way I did things is optimal, but it did make for very easy porting of most of the media-plugins/gst-plugins-* ebuilds. The gory details are available in my overlay; my classes rely on my overlay's hooks eclass, which I don't plan to upstream, so I won't bother documenting how all the pieces fit together.
There are a couple of noteworthy things, however.
First, as in gstreamer, I apply the same OOT patches for configure's win32/common/config.h creation during src_prepare:
cd "${S}" || die # sometimes this does something!
einfo "Patching configure for OOT build"
# Patch ugly configure sed hack (by means of ugly sed configure hack),
# to (hopefully) work when building OOT (untested on win32)
sed -e '/^sed \\$/imkdir -p win32/common' \
-e 's|^\([[:space:]]*\)\(config.h.in >win32/common/config.h-new\)|\1${srcdir}/\2|' \
-i configure{.ac,} || die configure OOT sed patch failed
Secondly, some ugly manipulations are required to make gtk-doc work right.
This is the same problem we solved for media-libs/gstreamer. Roughly the same solution is employed, but here I used a slightly fancier eclass-code-based implementation. The code is too wide to paste, so I'll link it (the part that starts with "# patch Makefile.{ac,in} for pass-through..."): http://git.overlays.gentoo.org/gitweb/?p=user/gmt.git;a=blob;f=eclass/gst-plugins-multilib.eclass;h=cfbad61233950b9b8dcb811aca4ee8d506470c0d;hb=HEAD#l336
Finally, a number of changes were required to get the old gst-plugins10_system_link tricks working in multilib. The gory details are in my overlay but I'm not sure I'd want to see anything resembling my implementation upstream. To be honest, I have trouble understanding my own code, there -- never a good sign for the maintainability of an implementation :). That stated, the implementation there has worked like a charm for quite some time.
If I were to redo it from scratch I'd integrate multilib support right into the upstream ebuilds -- I think my decision to avoid doing so ultimately drove most of the complications in my code that I don't like.
(In reply to Greg Turner from comment #14) > If I were to redo it from scratch I'd integrate multilib support right into > the upstream ebuilds Of course I meant 'upstream eclasses' :) hth. (In reply to Greg Turner from comment #13) > (In reply to Greg Turner from comment #12) > > First, gtk-doc is universally all fucked up for multilib. Normally I have a > > gtk-doc eclass to fix this up but it doesn't work for gstreamer. So for > > gstreamer, I do the equivalent "manually," in a patch in filesdir. The > > patch is wide and probably won't fit nicely here so, here's a link (two > > actually, one for each slot): > > > > http://git.overlays.gentoo.org/gitweb/?p=user/gmt.git;a=blob_plain;f=media- > > libs/gstreamer/files/gstreamer-0.10.36-OOT-gtkdoc-install-hack.patch;hb=HEAD > > > > http://git.overlays.gentoo.org/gitweb/?p=user/gmt.git;a=blob_plain;f=media- > > libs/gstreamer/files/gstreamer-0.10.36-OOT-gtkdoc-install-hack.patch;hb=HEAD > > second should read: > > http://git.overlays.gentoo.org/gitweb/?p=user/gmt.git;a=blob_plain;f=media- > libs/gstreamer/files/gstreamer-1.2.0-OOT-gtkdoc-install-hack.patch;hb=HEAD These patches are obviously wrong - see bug 492544 for a semi-working hack and the discussion. Something better should be implemented upstream though (and I mean gtk-doc upstream). That configure sed seems to make sense. po files thing is likely gettext 0.19. introspection should probably be disabled, just like other bindings are. As for pkg-config, the change in pkgconfig-0.28-r1 might simplify your hack. I still hold that wine should be ported to gstreamer 1.0 first, even though my own efforts at that have failed. AFAICT, that code needs to be rewritten to use appsrc/appsink, otherwise a custom GstAllocator will need to be implemented and that's not really documented (as gstreamer plugins do that in their base classes, so even the code is written by those in the know for those in the know - kinda like much of the wine code, now that I think about it). After all, firefox 30 (to be released on Tuesday) will support gstreamer 1.0 (even if upstream build won't enable that for awhile - but that's just mozilla upstream for you). I'm sorry but I wasn't around for a few days. My work is available for a few days already at: https://bitbucket.org/mgorny/gx86-working-tree/branch/gst-multilib-r2 It's much simpler than that, and I think I've solved most of the issues. We have working hack for gtk-doc, and the win32 issue I simply ignored since we don't support win32 anyway, and the issue should be fixed upstream. Not all plugins are converted since some of them still have non-multilib deps. I plan to convert the remaining deps and therefore plugins over time. The -gstplugins emul-linux compat pulls only gst-plugins-meta, so missing plugins are not a direct issue. I just need a confirmation that I can commit it for testing. And everything is committed p.masked now. If anyone wants to unmask it, beware -- leio is going to apply patches to those packages before they're unmasked. Anyway, have fun! |
