[FFmpeg-trac] #1623(FFmpeg:new): libutvideo fails to link to FFmpeg if assembly is enabled
FFmpeg
trac at avcodec.org
Tue Aug 14 09:12:33 CEST 2012
#1623: libutvideo fails to link to FFmpeg if assembly is enabled
------------------------------------+----------------------------------
Reporter: qyot27 | Owner:
Type: defect | Status: new
Priority: normal | Component: FFmpeg
Version: git-master | Resolution:
Keywords: libutvideo | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
------------------------------------+----------------------------------
Comment (by qyot27):
According to the output of ''file'', the object files NASM produced seem
to be what they're supposed to be (ELF 32-bit if I don't specify OS= and
use ARCH=x86 and COFF if I make sure OS=windows and ARCH=x86).
I was working with my own [https://github.com/qyot27/libutvideo
buildsystem branch], which I had integrated that commit into. I also went
back and double-checked with your's to make sure the files produced match
the same way.
After some testing, if I was compiling for my 64-bit setup and enabled x64
asm, then everything linked (even with my branch), although it resulted in
a segfault whenever libutvideo was used for decoding or encoding. The
linking problems seem to be focused only on compiling libutvideo+asm and
ffmpeg as 32-bit.
Would changing {{{elif __i386__}}} to {{{elif __x86_32__}}} in
TunedFunc.cpp actually work? I thought about it because it would parallel
the x64 pattern right above it, since that one does link (segfault
notwithstanding). It seemed to let a 32-bit compile link to ffmpeg, but
for all I know I just told it to ignore assembly altogether (even though
running nm -s on the resultant libutvideo.a showed the *asm_x86.o files
and their symbols). The 32-bit build of libutvideo+asm/ffmpeg also did
not segfault the way the 64-bit one did, so I'm unsure if that's also
hinting to it not actually having the assembly linked in or simply that
the x64 asm has a problem (it did show some warnings while compiling, or
maybe it was because I forgot to use PIC).
And while this is somewhat off-topic, the define being
-DSTATIC_LIB_WITH_ASM, does that preclude the ability of shared libraries
using it? I would assume it does, but I just want to be sure. I have
shared compilation worked out in my branch (although I've still not
hammered all the kinks out of the install step or having it build
alongside the static lib), and FFmpeg seems to work with it without
problems, but I'm not sure how the '''STATIC'''_LIB_WITH_ASM thing would
factor in, if at all.
--
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/1623#comment:2>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list