Created attachment 344296 [details] The proposed ebuild supporting multilib ABIs. media-libs/libogg should have multilib ABI support so that it can be removed from app-emulation/emul-linux-x86-soundlibs in the future versions. I'm attaching a proposed ebuild supporting multilib ABIs through autotools-multilib eclass. A necessary block on emul-linux-x86-soundlibs is added to avoid file collisions. I had to patch source for the patch to honour the --docdir option. I'm attaching it too. The headers had to be wrapped with the new and shiny MULTILIB_WRAPPED_HEADERS. I have tested the ebuild and it is working fine for me.
Created attachment 344298 [details, diff] The patch to honour docdir.
do we _really_ need the docdir patch ? (imho it should be a separate bug and the patch sent upstream) also: MULTILIB_WRAPPED_HEADERS=( /usr/include/ogg/os_types.h /usr/include/ogg/config_types.h /usr/include/ogg/ogg.h ) it seems only ogg/config_types.h will change, why do we need the others ?
(In reply to comment #2) > do we _really_ need the docdir patch ? > (imho it should be a separate bug and the patch sent upstream) If we are not patching it the documentation would go into the wrong directory, but that is maybe not a very big problem. I just think it is a little sad if this ebuild enters the tree and the documentation directory is wrong. Don't you? There is a similar (but very old) patch already sent upstream. Please see [1]. I've attached the patch to the old ticket and update the ticket a little. > also: > > > MULTILIB_WRAPPED_HEADERS=( > /usr/include/ogg/os_types.h > /usr/include/ogg/config_types.h > /usr/include/ogg/ogg.h > ) > > it seems only ogg/config_types.h will change, why do we need the others ? Oh, yes, you're right. I didn't see that I'm uploading a new version of the ebuild. It seems like it it works without wrapping the others. Thank you! [1] https://trac.xiph.org/ticket/1758
Created attachment 344352 [details] A new draft of the proposed ebuild supporting multilib. Here is a version with the other headers removed from the wrapped headers.
Please open a separate bug wrt docdir. Don't mix two different issues into one.
Created attachment 347024 [details, diff] Diff to multilib-minimal
Created attachment 347026 [details, diff] Diff to autotools-multilib
Created attachment 347028 [details] Ebuild using multilib-minimal
Created attachment 347030 [details] Ebuild using autotools-multilib
Now, ssuominen is away and left aballier & radhermit in charge. I'd appreciate your opinion on which of the patches should be applied. The multilib-minimal patch is mostly about adding. I had to replace 'default' with explicit 'emake install' since the default tried to install ${DOCS[@]} from build-dir and that failed terribly. Seems to be a bit of mis-design in the eclass (bug 468092). The autotools-multilib patch is mostly about removing. The static-libs handling is done in autotools in a consistent way, so the eclass handles it itself. Similarly .la removal. Hmm, I should've added AUTOTOOLS_PRUNE_LIBTOOL_FILES=all to be 100% equivalent.
(In reply to comment #10) > The autotools-multilib patch is mostly about removing. The static-libs > handling is done in autotools in a consistent way, so the eclass handles it > itself. Similarly .la removal. Hmm, I should've added > AUTOTOOLS_PRUNE_LIBTOOL_FILES=all to be 100% equivalent. To be fair, I prefer the ebuild for autotools-multilib than the one for multilib-minimal, however, I'd rather see it with AUTOTOOLS_PRUNE_LIBTOOL_FILES=nothanks (such an option should exist...) and keep the much simpler and faster find call. Or add an option to prune_libtool_files to just do that find call. When we know we won't need the .la files, we shouldn't even install them at all in $D, the find -delete call is the poor man's solution, prune_libtool_files is trying to be clever on files that shouldn't even be there...
(In reply to comment #11) > (In reply to comment #10) > > The autotools-multilib patch is mostly about removing. The static-libs > > handling is done in autotools in a consistent way, so the eclass handles it > > itself. Similarly .la removal. Hmm, I should've added > > AUTOTOOLS_PRUNE_LIBTOOL_FILES=all to be 100% equivalent. > > To be fair, I prefer the ebuild for autotools-multilib than the one for > multilib-minimal, however, I'd rather see it with > AUTOTOOLS_PRUNE_LIBTOOL_FILES=nothanks (such an option should exist...) and > keep the much simpler and faster find call. Or add an option to > prune_libtool_files to just do that find call. > > When we know we won't need the .la files, we shouldn't even install them at > all in $D, the find -delete call is the poor man's solution, > prune_libtool_files is trying to be clever on files that shouldn't even be > there... The '--all' variant is mostly a verbose version of the 'find' call. It doesn't do any conditionals but $1 == all before removing the files.
Created attachment 347038 [details] Final version using autotools-multilib This one's with proper pruning and keywords dropped to ~arch. Is it ok to commit it with a revbump?
(In reply to comment #5) > Please open a separate bug wrt docdir. Don't mix two different issues into > one. OK. The bug is reported as #468184.
(In reply to comment #13) > Created attachment 347038 [details] > Final version using autotools-multilib > > This one's with proper pruning and keywords dropped to ~arch. Is it ok to > commit it with a revbump? in portage (temporarily in package.mask, feel free to take charge of unmasking it when ready.)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=261a921cc8f554cf80ba5b054a885b96a0ad77a9 commit 261a921cc8f554cf80ba5b054a885b96a0ad77a9 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-05-28 15:37:01 +0000 Commit: David Seifert <soap@gentoo.org> CommitDate: 2021-05-28 15:37:01 +0000 media-libs/libogg: fix libdir in installed M4 macro Most consumers seem to work around this fine nowdays, but we should still fix the macro. See: https://gitlab.xiph.org/xiph/ogg/-/issues/1917 Bug: https://bugs.gentoo.org/464486 Bug: https://bugs.gentoo.org/499978 Signed-off-by: Sam James <sam@gentoo.org> Signed-off-by: David Seifert <soap@gentoo.org> media-libs/libogg/files/libogg-1.3.4-libdir-m4.patch | 13 +++++++++++++ .../libogg/{libogg-1.3.4.ebuild => libogg-1.3.4-r1.ebuild} | 5 +++++ 2 files changed, 18 insertions(+)
