I... have a patch against media-plugins/live that, IMO, cleans things up. It was only prepared for version 2009* (I didn't want to waste time on 2008.09.02). The following are a few things it addresses: 1. live's buildsystem calls ld directly (which breaks portage-multilib and is considered improper). Fixed by utilizing system-installed libtool. Result is dynamic libraries :-). This also gets rid of the double-building and double-unpacking code (i.e., the live-static and live-shared subdirectories of ${WORKDIR}). 2. Fixed an --as-needed compilation error, possibly fixing bug 247844. 3. Upgraded to EAPI="2" for cleaner ebuild. 4. DESCRIPTION is too long, shortened. Primary anticipated objections: 1. This uses libtool to do the hard work instead of whatever other methods are available. But yet it has provision for removing the libtool archive files and not building static libraries unless if the static-libs useflag is set and this method of linking may be slightly more portable (I don't know). 2. This will mess with the live ebuilds requiring the unstable->stable process to be followed again. Maybe it's enough if only the latest snapshot is updated with the to-be-attached patch.
Created attachment 223833 [details, diff] low-quality hackery
Created attachment 273005 [details, diff] live-2011.03.14.ebuild-portage-multilib.patch This is a better and less invasive change to the ebuild. It bumps it up to EAPI=4 and also avoids calling $(LD) directly allowing media-plugins/live to successfully compile under portage-multilib. It requires two additional patches which will be attached.
Created attachment 273007 [details, diff] live-2009.09.28-buildorder.patch This patch ensures that the libraries are built in an order such that inter-library dependencies are satisfied by the time each library is built. This allows the second patch to be useful (though still only applicable to the shared-object version of media-plugins/live).
Created attachment 273009 [details, diff] live-2009.06.02-libdeps.patch This patch ensures that each shared object has proper NEEDED entries for the other libraries it depends on. Because of the way it works, this patch may only be applied when building the shared-object versions of media-plugins/live (yet this does not count as a conditional patch since the shared-object version is unconditionally built). This is because in the static version of the library this patch would cause libliveMedia.a to have symbols already defined by libgroupsock.a and libBasicUsageEnvironment.a, causing the linker to complain about duplicate symbol definitions when trying to link an executable with -static -lliveMedia -lgroupsock -lBasicUsageEnvironment.
Created attachment 278829 [details, diff] live-2011.06.16.ebuild-multilib.patch Updated to be a less intrusive change to the original ebuild. Also updated to use files/config.gentoo-r1 and files/config.gentoo-so-r2 for the ./genMakefiles command to distinguish between existing and altered versions. These new editions of the ./genMakefiles scripts move injection of LDFLAGS from emake's commandline to the Makefiles themselves in a cleaner way. They'll be attached next.
Created attachment 278831 [details, diff] config.gentoo-r1.patch Applies to files/config.gentoo and produces files/config.gentoo-r1.
Created attachment 278833 [details, diff] config.gentoo-so-r2.patch Likewise, applies to files/config.gentoo-so-r1 and produces files/config.gentoo-so-r2.
Since the addition of default *FLAGS for amd64 on amd64, this now also breaks building media-plugins/live at least with multilib-portage, where the default flags for the target are added to the user flags, part of build.log: In file included from Locale.cpp:22:0: include/Locale.hh:52:44: Warnung: »typedef« wurde in dieser Deklaration ignoriert x86_64-pc-linux-gnu-ld -olibliveMedia.a -L. --as-needed --hash-style=gnu -m64 -r -Bstatic \ Media.o MediaSource.o FramedSource.o FramedFileSource.o FramedFilter.o ByteStreamFileSource.o ByteStreamMultiFileSource.o ByteStreamMemoryBufferSource.o BasicUDPSource.o DeviceSource.o AudioInputDevice.o WAVAudioFileSource.o MPEG1or2Demux.o MPEG1or2DemuxedElementaryStream.o MPEGVideoStreamFramer.o MPEG1or2VideoStreamFramer.o MPEG1or2VideoStreamDiscreteFramer.o MPEG4VideoStreamFramer.o MPEG4VideoStreamDiscreteFramer.o H264VideoStreamFramer.o H264VideoStreamDiscreteFramer.o MPEGVideoStreamParser.o MPEG1or2AudioStreamFramer.o MPEG1or2AudioRTPSource.o MPEG4LATMAudioRTPSource.o MPEG4ESVideoRTPSource.o MPEG4GenericRTPSource.o MP3FileSource.o MP3HTTPSource.o MP3Transcoder.o MP3ADU.o MP3ADUdescriptor.o MP3ADUinterleaving.o MP3ADUTranscoder.o MP3StreamState.o MP3Internals.o MP3InternalsHuffman.o MP3InternalsHuffmanTable.o MP3ADURTPSource.o MPEG1or2VideoRTPSource.o MPEG2TransportStreamMultiplexor.o MPEG2TransportStreamFromPESSource.o MPEG2TransportStreamFromESSource.o MPEG2TransportStreamFramer.o ADTSAudioFileSource.o H263plusVideoRTPSource.o H263plusVideoStreamFramer.o H263plusVideoStreamParser.o AC3AudioStreamFramer.o AC3AudioRTPSource.o DVVideoStreamFramer.o DVVideoRTPSource.o JPEGVideoSource.o AMRAudioSource.o AMRAudioFileSource.o InputFile.o MediaSink.o FileSink.o BasicUDPSink.o AMRAudioFileSink.o H264VideoFileSink.o MPEG1or2AudioRTPSink.o MP3ADURTPSink.o MPEG1or2VideoRTPSink.o MPEG4LATMAudioRTPSink.o MPEG4GenericRTPSink.o MPEG4ESVideoRTPSink.o H263plusVideoRTPSink.o H264VideoRTPSink.o DVVideoRTPSink.o AC3AudioRTPSink.o VorbisAudioRTPSink.o VP8VideoRTPSink.o GSMAudioRTPSink.o JPEGVideoRTPSink.o SimpleRTPSink.o AMRAudioRTPSink.o T140TextRTPSink.o TCPStreamSink.o OutputFile.o uLawAudioFilter.o RTPSource.o MultiFramedRTPSource.o SimpleRTPSource.o H261VideoRTPSource.o H264VideoRTPSource.o QCELPAudioRTPSource.o AMRAudioRTPSource.o JPEGVideoRTPSource.o VorbisAudioRTPSource.o VP8VideoRTPSource.o RTPSink.o MultiFramedRTPSink.o AudioRTPSink.o VideoRTPSink.o TextRTPSink.o RTPInterface.o RTCP.o rtcp_from_spec.o RTSPServer.o RTSPClient.o RTSPCommon.o RTSPServerSupportingHTTPStreaming.o SIPClient.o MediaSession.o ServerMediaSession.o PassiveServerMediaSubsession.o OnDemandServerMediaSubsession.o FileServerMediaSubsession.o MPEG4VideoFileServerMediaSubsession.o H264VideoFileServerMediaSubsession.o H263plusVideoFileServerMediaSubsession.o WAVAudioFileServerMediaSubsession.o AMRAudioFileServerMediaSubsession.o MP3AudioFileServerMediaSubsession.o MPEG1or2VideoFileServerMediaSubsession.o MPEG1or2FileServerDemux.o MPEG1or2DemuxedServerMediaSubsession.o MPEG2TransportFileServerMediaSubsession.o ADTSAudioFileServerMediaSubsession.o DVVideoFileServerMediaSubsession.o AC3AudioFileServerMediaSubsession.o QuickTimeFileSink.o QuickTimeGenericRTPSource.o AVIFileSink.o MPEG2IndexFromTransportStream.o MPEG2TransportStreamIndexFile.o MPEG2TransportStreamTrickModeFilter.o MatroskaFile.o MatroskaFileParser.o EBMLNumber.o MatroskaDemuxedTrack.o MatroskaFileServerDemux.o H264VideoMatroskaFileServerMediaSubsession.o VP8VideoMatroskaFileServerMediaSubsession.o AACAudioMatroskaFileServerMediaSubsession.o AC3AudioMatroskaFileServerMediaSubsession.o MP3AudioMatroskaFileServerMediaSubsession.o VorbisAudioMatroskaFileServerMediaSubsession.o T140TextMatroskaFileServerMediaSubsession.o DarwinInjector.o BitVector.o StreamParser.o DigestAuthentication.o our_md5.o our_md5hl.o Base64.o Locale.o x86_64-pc-linux-gnu-ld: unrecognised emulation mode: 64 Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 i386linux elf_l1om elf_k1om make[1]: *** [libliveMedia.a] Fehler 1 make[1]: Leaving directory `/home/thomas/daten/portage/media-plugins/live-2011.12.20/work/live-static/liveMedia' make: *** [all] Fehler 2 emake failed
Created attachment 296795 [details] live-2011.12.20.ebuild-multilib.patch
Created attachment 296797 [details] live-2011.12.20-libdeps.patch
Since there has been no reaction nor comment on this bug for many months now, i plan to move the latest adjusted testing version from multilib-portage overlay [1] next month. So please add a comment here, if there is any specific reason preventing the fix of this bug. [1]: http://git.overlays.gentoo.org/gitweb/?p=proj/multilib-portage.git;a=blob;f=media-plugins/live/live-2012.01.07.ebuild;h=7c6271dfab123ac3f5faf9cd616bd5fb681cbb6d;hb=a13a9d8921967aac82f2c74e2978a47d3235c9e5
(In reply to comment #11) > Since there has been no reaction nor comment on this bug for many months now, i > plan to move the latest adjusted testing version from multilib-portage overlay > [1] next month. > So please add a comment here, if there is any specific reason preventing the > fix of this bug. > > [1]: > http://git.overlays.gentoo.org/gitweb/?p=proj/multilib-portage.git;a=blob;f=media-plugins/live/live-2012.01.07.ebuild;h=7c6271dfab123ac3f5faf9cd616bd5fb681cbb6d;hb=a13a9d8921967aac82f2c74e2978a47d3235c9e5 please attach a diff if you want comments (In reply to comment #9) > Created attachment 296795 [details] > live-2011.12.20.ebuild-multilib.patch src_prepare() { - cd "${WORKDIR}" + epatch "${FILESDIR}"/${PN}-2009.09.28-buildorder.patch unrelated to this bug (but probably useful though) - cp -pPR live live-shared - mv live live-static + cp -pPR live live-shared || die + pushd live-shared || die + # To build shared libraries with proper NEEDED entries, we need + # these libraries to link to eachother. This patch does this. + epatch "${FILESDIR}"/${P}-libdeps.patch + popd || die + + mv live live-static || die ditto - ./genMakefiles gentoo - emake -j1 LINK_OPTS="-L. $(raw-ldflags)" || die "failed to build static libraries" + emake -C ${PN}-static -j1 buildorder.patch isnt supposed to remove the need for -j1 ? - dolib.so live-shared/${library}/lib${library}$(get_libname ${LIVE_ABI_VERSION}) - dosym lib${library}$(get_libname ${LIVE_ABI_VERSION}) /usr/$(get_libdir)/lib${library}$(get_libname) + + mv ${PN}-shared/${library}/lib${library}.so{,.${LIVE_ABI_VERSION}} || die sounds hackish... why not keep the old behavior, building .so.LIVE_ABI_VERSION and _then_ symlinking ? - find live-static/testProgs -type f -perm +111 -print0 | \ + find live-shared/testProgs -type f -perm +111 -print0 | \ the -shared executables are built as PIC, which we dont need. and the changes are unrelated anyway (In reply to comment #8) > Since the addition of default *FLAGS for amd64 on amd64, this now also breaks > building media-plugins/live at least with multilib-portage, where the default > flags for the target are added to the user flags, part of build.log: > x86_64-pc-linux-gnu-ld -olibliveMedia.a -L. --as-needed --hash-style=gnu -m64 you injected -m64 in LDFLAGS ? either your default flags are broken or the raw_ldflags function should be fixed so that it translates gcc ldflags to ld ldflags in a way that doesnt break...
> (In reply to comment #8) > > Since the addition of default *FLAGS for amd64 on amd64, this now also breaks > > building media-plugins/live at least with multilib-portage, where the default > > flags for the target are added to the user flags, part of build.log: > > x86_64-pc-linux-gnu-ld -olibliveMedia.a -L. --as-needed --hash-style=gnu -m64 > > you injected -m64 in LDFLAGS ? > either your default flags are broken or the raw_ldflags function should be > fixed so that it translates gcc ldflags to ld ldflags in a way that doesnt > break... multilib-portage does add CFLAGS_${target_abi} to CFLAGS, LDFLAGS and some other vars. This adds e.g. -m32, when cross-compiling for x86 on amd64. With the introduction of x32 ABI, vapier also committed default target flags for amd64, which means, that -m64 is now added to *FLAGS, when building by default for amd64. For the rest, i will allow binki as the author to answer to your comments.
(In reply to comment #13) > > (In reply to comment #8) > > > Since the addition of default *FLAGS for amd64 on amd64, this now also breaks > > > building media-plugins/live at least with multilib-portage, where the default > > > flags for the target are added to the user flags, part of build.log: > > > x86_64-pc-linux-gnu-ld -olibliveMedia.a -L. --as-needed --hash-style=gnu -m64 > > > > you injected -m64 in LDFLAGS ? > > either your default flags are broken or the raw_ldflags function should be > > fixed so that it translates gcc ldflags to ld ldflags in a way that doesnt > > break... > > multilib-portage does add CFLAGS_${target_abi} to CFLAGS, LDFLAGS and some > other vars. This adds e.g. -m32, when cross-compiling for x86 on amd64. since it seems correct and necessary to do this, then you should really consider fixing the raw-ldflags function. you're just hiding problems otherwise and may hit more in the future.
(In reply to comment #14) > (In reply to comment #13) > > > (In reply to comment #8) > > > > Since the addition of default *FLAGS for amd64 on amd64, this now also breaks > > > > building media-plugins/live at least with multilib-portage, where the default > > > > flags for the target are added to the user flags, part of build.log: > > > > x86_64-pc-linux-gnu-ld -olibliveMedia.a -L. --as-needed --hash-style=gnu -m64 > > > > > > you injected -m64 in LDFLAGS ? > > > either your default flags are broken or the raw_ldflags function should be > > > fixed so that it translates gcc ldflags to ld ldflags in a way that doesnt > > > break... > > > > multilib-portage does add CFLAGS_${target_abi} to CFLAGS, LDFLAGS and some > > other vars. This adds e.g. -m32, when cross-compiling for x86 on amd64. > > since it seems correct and necessary to do this, then you should really > consider fixing the raw-ldflags function. you're just hiding problems otherwise > and may hit more in the future. raw-ldflags() should be considered deprecated. The only proper way to send flags to the linker is indirectly through the compiler driver, because the driver provides a unified interface to things like choosing the ABI. See bug 308373 comment 6 "people who want to invoke the linker directly (like the media-plugins/live package) should be fixed to invoke the compiler driver instead." I'll try to respond to more objections and produce another diff when/if I have time. Thanks for looking, though.
I don't think this is an issue anymore; cannot reproduce the build system calling /usr/bin/ld. Closing.
