media-libs/gst-plugins-x fails to compile with error "make: *** No rule to make target `//usr/lib64/libgstvideo-0.10.la', needed by `libgstximagesink.la'. Stop." Attempting other gst-plugins atoms also fail similarly, except st-plugins-base. I've attempted 0.10.23 and 0.10.24 with the same results. Compiling from vanilla source works, however.
Created attachment 215772 [details] media-libs/gst-plugins-x-0.10.25 build.log
Created attachment 215774 [details] emerge --info =media-plugins/gst-plugins-x-0.10.25
emerge -pqv =media-plugins/gst-plugins-x-0.10.25 [ebuild N ] media-plugins/gst-plugins-x-0.10.25 USE="-lib32"
Created attachment 215776 [details] make.conf
I'm slightly confused. (1) I don't find any package by that name in the tree (2) lib32 useflag - is that from the multilib overlay?
/usr/lib/libgstvideo-0.10.so belongs to media-libs/gst-plugins-base the problem is probably caused by gentoo scheme of building gstreamer plunins. IIRC, la files are removed during install (which is a good thing, IMHO). This simply needs a little (trivial) patch for relevant Makefile.am, so it links with system copy of the lib, instead of looking for la files.
lib32 is multilib, but I'm not using it with this package. And it should be media-plugins, so I've corrected it, sorry for the confusion.
This also affects several other gst-plugins- packages, cdparanoia, alsa, gnomevfs, vorbis, ogg of the top of my head.
I was able to get these packages to install by hacking the Makefile that's breaking it, since its pointing directly as "//usr/lib64", I changed it to "$(top_builddir)/gst-libs/gst/" like vanilla source, edited configure to not clobber this makefile, did a make in the directories it depended on, then after ocnfirming that running make in sys/ximage now worked, using ebuild to compile then merge succeeded, similar hacks worked for the other nonworking packages.
What you should have done was editing relevant Makefile.am, changing entries referring to la files of libraries installed by a different package to '-l<libname>', followed by eautomake (or a full eautoreconf) - IIRC, most of these plugins do the later anyway.
By 'editing' I meant 'patching', of course.
Created attachment 220883 [details] patch to gst-plugins Here is a patch to fix the Makefiles, don't know if correct though. You will need to edit the ebuilds to for a few plugins. add src_unpack() { unpack ${A} cd "${S}" epatch "${FILESDIR}/gst-plugins-base-0.10.25-la.patch" } Here is a list of the ebuilds that need to be modified Alsa Ogg Vorbis X XVideo
Created attachment 220895 [details] gst-plugins-base-fix-la.patch Please ignore chibi-wing's patch. This one gets slightly closer to the heart of the problem and utilizes pkg-config to avoid having paths directly to libtool files. This appears to be enough to fix all gst plugins using the gst-plugins-base.eclass (hopefully). This is useful for portage-multilib and also for people who don't like the _useless class_ of libtool archive files (not all are useless ;-) ).
So this issue would at least affect all split plugins that make use of a helper library. Adjusting the bug summary a bit. This is low priority for me, as I don't believe multilib project should be just outright removing .la files like that. The last patch looks neat though at first glance though, but I might have some reservations about direct pkg-config calls in a Makefile.
(In reply to comment #14) > This is low priority for me, as I don't believe multilib project should be just > outright removing .la files like that. True. Though, IMO, removing .la files when a package provides pkg-config files is good because .la and .pc files perform the same function in the case of normal libraries. > The last patch looks neat though at > first glance though, but I might have some reservations about direct pkg-config > calls in a Makefile. The calls to pkg-config are expanded before bash calls invokes sed. Just add an ``echo '' before the sed command to get an idea of what it's doing ;-). I would like to note that the whole sed expression thing started out as a hack to build the plugins separately from the rest of the gst package. Thus, the hack might as well go all the way and recognize that gst ships with pkg-config and intends plugins to use the pkg-config files. But this is a hack and I'm assuming that upstream doesn't want to include support for this sort of thing in their buildsystem.
*** Bug 340535 has been marked as a duplicate of this bug. ***
(In reply to comment #14) > So this issue would at least affect all split plugins that make use of a helper > library. Adjusting the bug summary a bit. > This is low priority for me, as I don't believe multilib project should be just > outright removing .la files like that. The last patch looks neat though at > first glance though, but I might have some reservations about direct pkg-config > calls in a Makefile. Here's a slightly different implementation, not using pkgconfig: http://bugs.gentoo.org/attachment.cgi?id=250285 Also, for the embedded team this is useful as libtool is very broken in cross-environments. It creates library archives with /usr/lib paths instead of the correct cross-compile paths /usr/$chost/usr/lib.
(In reply to comment #17) > Here's a slightly different implementation, not using pkgconfig: > > http://bugs.gentoo.org/attachment.cgi?id=250285 This worked for me.
Created attachment 254215 [details, diff] gst-plugins-base-eclass-2.patch It seems that for some plugins (media-plugins/gst-plugins-vorbis for example), Makefile.in contains @GST_MAJORMINOR@ instead of $(GST_MAJORMINOR). This patch fix those too. I changed the multiple line for "{"/"}" vs "("/")" into "[{(]"/"[})]" because it started to be complicated, but feel free to do it another way.
I used binki's patch after I had switched to multilib-overlay, and that fixed my problems emerging gst-plugins-*.
After applying the patch by Damien Thébault I finally got gst-plugins to compile successfully.
Created attachment 289163 [details, diff] gst-plugins-base-fix-la.patch fixed for cdparanoia plugin Fixes a bug in binki's patch with the wildcard pattern used to match libgstcdda la file. configure: *** Orc acceleration enabled. * Building external plugin cdparanoia ... make -j9 make: *** No rule to make target `../../gst-libs/gst/cdda/libgstcdda-0.10.la', needed by `libgstcdparanoia.la'. Stop. make: *** Waiting for unfinished jobs.... CC libgstcdparanoia_la-gstcdparanoiasrc.lo
Could you guys give a shot at this again, new eclasses should be more friendly to this use case.
I didn't have this issue again, so it is probably now fine.
(In reply to comment #23) > Could you guys give a shot at this again, new eclasses should be more > friendly to this use case. Since you call prune_libtool_modules() and have modified the Makefiles to no longer reference the .la files but instead use pkg-config, and because I cannot reproduce this problem after testing the very small sample of gst-plugins-{base,x{,video}} ebuilds, I think this bug is quite fixed and that we can even remove the workaround for gst-plugins from the multilib fork of portage itself.
Thanks, marking as fixed then.
