After finding and fixing bug 192481 myself (doh! should have checked bugs first...oh well good experience :D), I ran into another issue concerning sox and gsm on amd64. Sox 14.0.0 fails with the infamous "a relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC" on amd64 with respect to gsm_destroy.o. To fix this I added the following line to gsm under src_compile(): use amd64 && append-flags -fPIC Not 100% sure of whether my solution is the preferred but it worked for me. From Gentoo's docs on relocation errors it seems that compiling with -fPIC in cxxflags globally is discouraged because it effects binaries as well. However, whenever I check the flags during the build after adding the above line, only the object files are compiled -fPIC and not the actual binaries (at least toast anyways...). This definitely fixed my issue but I'm curious what the preferred solution in this case is? ~jtriley
Please, post the actual errors and emerge --info output.
Created attachment 131097 [details] emerge --info sure thing, here you go. Thanks!
Created attachment 131099 [details] build.log for media-sound/sox failure due to gsm not being built fPIC
Noone will ever notice again unless you reopen the bug... ;)
(In reply to comment #4) > Noone will ever notice again unless you reopen the bug... ;) > Meaning since I didn't attach this stuff at the beginning all hope is lost for finding the best fix for this or did I somehow close the bug? My apologies if this is the case...
imho there are three options there : - make gsm build a shared .so lib compiled with pic on all arches. The problem is that if upstream doesn't do that that may be because it exports too much symbols, and they don't want to maintaint an abi.(Note that debian is doing that) - compile gsm with -fPIC on all arches, as it will most likely fail on anything but x86 (and cause textrels on x86), so that libgsm.a can be linked in shared libs. That's ugly. - disable external gsm support for sox. That will fix all our problems, but as it will be included and not updated may cause headaches. Note that linking to .a static lib will for sure not help if there is a security issue on gsm. I tend to prefer the first option, @sound, any preference ?
(In reply to comment #6) > I tend to prefer the first option, @sound, any preference ? You've got free hands here.. ;-)
(In reply to comment #7) > (In reply to comment #6) > > I tend to prefer the first option, @sound, any preference ? > > You've got free hands here.. ;-) > I've disabled external gsm lib support in sox for now, until gsm installs it correctly. When I bumped it, I didn't notice this "automagic" dep. Having support for external gsm will mean having it as a mandatory dep, thus dropping some keywords, I'll see about a -r1 for sox using this and a -r1 for gsm that will fix it.
better assigned like that probably
*** Bug 199951 has been marked as a duplicate of this bug. ***
These are also broken by this bug, media-plugins/gst-plugins-farsight:gsm net-im/ekg2:gsm net-voip/yate:gsm (This one is package.use.masked in amd64 profile)
Aballier, I've fixed media-sound/gsm to install a shared library (building objects twice, once -fPIC for shared and once without for static.) I've also tested building it against net-voip/yate, net-im/ekg2 and media-plugins/gst-plugins-farsight and they are all OK. Unfortunately keywords don't match with media-sound/gsm and media-sound/sox.. Nothing left for amd64 here, removing CC.
archteams, keywords ~alpha, ~hppa, ~ppc64 and ~x86-fbsd are required for media-sound/gsm to get matching keywords for media-sound/sox. thanks.
~x86-fbsd done, its fine here
added 14.0.0-r1, dropping keywords for arches that dont have it keyworded yet. Samples: http://samples.mplayerhq.hu/A-codecs/GSM/ Testing: play sample.gsm -> should play sox sample.gsm foo.wav -> foo.wav should be sample.gsm decoded into wav
Marked ~hppa.
~alpha done, thanks Tobias
~ppc64
keywords match now, nothing left here -> closing
