[FFmpeg-devel] [PATCH] revision r12484 breaks OS/2

[Dave Yeo]

On 03/20/08 10:25 am, M?ns Rullg?rd wrote:
> Dave Yeo <daveryeo at telus.net> writes:
> 
>> On 03/18/08 03:23 am, M?ns Rullg?rd wrote:
>>> Dave Yeo wrote:
>>>> Hi, the patch committed for r12384 breaks OS/2 due to nm.exe not
>>>> understanding OMF object format.
>>>> nm --help
>>>> [...]
>>>> nm: supported targets: a.out-emx elf32-i386 efi-app-ia32 pe-i386
>>>> pei-i386 elf32-little elf32-big srec symbolsrec tekhex binary ihex trad-core
>>>>
>>>> epm: I:\usr\src\ffmpeg >sh ./configure --enable-gpl --enable-os2threads
>>>> nm: F:/XFREE86/TMP/ffmpeg-conf--35636-.o: File format not recognized
>>> The general idea is that your toolset should be working...
>>>
>> 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.
>> Dave
>> Index: configure
>> ===================================================================
>> --- configure	(revision 12515)
>> +++ configure	(working copy)
>> @@ -871,7 +871,7 @@
>>  
>>  TMPC="${TMPDIR1}/ffmpeg-conf-${RANDOM}-$$-${RANDOM}.c"
>>  TMPO="${TMPDIR1}/ffmpeg-conf-${RANDOM}-$$-${RANDOM}.o"
>> -TMPE="${TMPDIR1}/ffmpeg-conf-${RANDOM}-$$-${RANDOM}"
>> +TMPE="${TMPDIR1}/ffmpeg-conf-${RANDOM}-$$-${RANDOM}$EXESUF"
>>  TMPS="${TMPDIR1}/ffmpeg-conf-${RANDOM}-$$-${RANDOM}.S"
>>  TMPH="${TMPDIR1}/ffmpeg-conf-${RANDOM}-$$-${RANDOM}.h"
> 
> This wrong.  EXESUF hasn't been set there.

Previously testing basically the same patch configure would fail without 
  the $EXESUF added to TMPE. This includes testing the OpenWatcom 
compiler a few weeks back.
Anyways now the -Zomf is getting added at the correct places (or tests 
have changed) and this part of the patch is not needed anymore.
Updated patch attached.

> 
>> @@ -1268,16 +1268,13 @@
>>          ranlib="echo ignoring ranlib"
>>          ;;
>>      os/2*)
>> -        ar="emxomfar -p256"
>> -        ranlib="echo ignoring ranlib"
>>          strip="lxlite"
>>          ln_s="cp -f"
>> -        add_cflags "-Zomf"
>>          EXESUF=".exe"
>>          FFLDFLAGS="-Zomf -Zbin-files -Zargs-wild -Zmap"
>>          SHFLAGS='$(NAME).def -Zdll -Zomf'
>>          FFSERVERLDFLAGS=""
>> -        LIBSUF="_s.lib"
>> +        LIBSUF="_s.a"
>>          SLIBPREF=""
>>          SLIBSUF=".dll"
>>          SLIBNAME_WITH_VERSION='$(SLIBPREF)$(NAME)-$(LIBVERSION)$(SLIBSUF)'
> 
> 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 
creation.
The emxomfar and lack of ranlib are just the OMF versions of the 
toolset. The .lib vs .a libsuf differentiates OMF and aout libs.
Long term solution is to write an emxomfnm or add OMF support to nm, 
something that should be done anyways.
Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: configure.aout.diff
Type: text/x-patch
Size: 698 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080320/c9ea3e38/attachment.bin>