[FFmpeg-devel] [PATCH] revision r12484 breaks OS/2
Thu Mar 20 20:27:48 CET 2008
On Thu, Mar 20, 2008 at 12:08:48PM -0700, Dave Yeo wrote:
> On 03/20/08 10:25 am, M?ns Rullg?rd wrote:
>> Dave Yeo <daveryeo at telus.net> writes:
>>> Attached patch makes object files aout (aout-emx) format. Executables
>>> need .exe so ld will create a LX executable instead of an aout
>>> binary. The various tools like nm do understand aout.
>>> --- configure (revision 12515)
>>> +++ configure (working copy)
>>> @@ -1268,16 +1268,13 @@
>>> ranlib="echo ignoring ranlib"
>>> - ar="emxomfar -p256"
>>> - ranlib="echo ignoring ranlib"
>>> ln_s="cp -f"
>>> - add_cflags "-Zomf"
>>> FFLDFLAGS="-Zomf -Zbin-files -Zargs-wild -Zmap"
>>> SHFLAGS='$(NAME).def -Zdll -Zomf'
>>> - LIBSUF="_s.lib"
>>> + LIBSUF="_s.a"
>> I'm all for cruft removal. Is this certain not to cause any other
>> problems? I'd like to think those flags were added for a reason.
> Previously there was no aout to OMF conversion at the linking stage so
> CLFAGS and LDFLAGS both had to have the -Zomf flag, this will end
> partial support of GCC 3.2.2 (libc05).
> At times I have seen the linker get confused when mixing aout and OMF
> but this is usually when libsuf was wrong. With quite a bit of testing
> in last couple of days the only issue I've seen is having to do make
> distclean more often (make test failing with missing symbols). Probably
> a good habit anyways.
> Also previously configure would fail without cflags=-Zomf due to the
> previously mentioned problem with lack of .exe when testing executable
> The emxomfar and lack of ranlib are just the OMF versions of the
> toolset. The .lib vs .a libsuf differentiates OMF and aout libs.
Whatever you say, patch applied.
> Long term solution is to write an emxomfnm or add OMF support to nm,
> something that should be done anyways.
Yes, this is likely the best solution.
More information about the ffmpeg-devel