[FFmpeg-devel] [PATCH] Re-add OS/2 support

[Diego Biurrun]

On Sun, Oct 07, 2007 at 10:16:26PM -0700, Dave Yeo wrote:
> Diego Biurrun wrote:
>> On Sat, Sep 15, 2007 at 09:38:39PM -0700, Dave Yeo wrote:
>>> Diego Biurrun wrote:
> ...
>>>>> +    SLIB_INSTALL_EXTRA_CMD="-install -m 644 
>>>>> \$(SLIBNAME:\$(SLIBSUF)=.lib) \$(SLIBNAME:\$(SLIBSUF)=.a) \$(LIBDIR)"
>>>> This looks wrong.  First you set SLIBSUF to .dll then you change it
>>>> here?  What's going on?  Also, there should be no libs with the names
>>>> you are trying to install, since they are created under different names
>>>> according to what you have set LIBSUF and SLIBSUF to ...
>>> GCC on OS/2 supports both a.out binaries, objects and libs. Libs use .a 
>>> suffix, uses ld for linking, needs to be bound to execute. Plus OMF 
>>> objects, binaries, and libs. Libs use .lib suffix, and uses native linker 
>>> for linking. Can also use IBM debuggers and other tools.
>> You are contradicting yourself here by saying two different things about
>> libs ...
>
> No contradiction, just 2 different ways to create libs and binaries. GCC 
> probably only supported a.out binary format when first ported to OS/2 
> (1991?) with native OMF binary format added to the port later. It still 
> uses a.out by default.
>
>>> To link to DLLs we create an import lib from the DLL (or DEF) and link to 
>>> that so ideally we want to end up with static foo_s.a and foo_s.lib (we 
>>> only get the .lib now), foo.dll and foo.a and foo.lib which the 
>>> respective linkers actually link against. Most of this is taken care of 
>>> here by dllar.cmd.
> ...
>>> These could also be named libfoo_s.a, libfoo.dll.a etc. Older GCC did not 
>>> understand these so I stayed with the older naming partially out of habit 
>>> and partially to keep some backwards compatibility.
>> I say forget backwards compatibility and go for the clean solution.
>
> Well now on install they are renamed to libfoo_dll.a etc. A cleaner 
> solution is to update dllar.cmd upstream which will have to wait for a 
> future release of klibc.
>>> Note also that we (and also Windows?) need an extra uninstall command as 
>>> well in a future patch.
>> Patches welcome.
>
> Yes, well one patch at a time :)

Let's see the patch right away.  If it is needed on Windows I'll likely
apply it right away.

>>> After ./configure --enable-shared --enable-os2threads && make && make 
>>> install with attached patch.
>
> 10-07-07   6:53p   2244033         124  avcodec-51.44.0.dll
> 10-07-07   6:53p   2244033         124  avcodec-51.dll
> 10-07-07   6:53p   2244033         124  avcodec.dll
> 10-07-07   6:53p    168056         124  libavcodec_dll.a
> 10-07-07   6:53p    103936         124  libavcodec_dll.lib
> 10-07-07   6:53p  11030528         124  libavcodec_s.lib
> ...
>
> updated patch attached

Here are some further comments.

> --- configure	(revision 10679)
> +++ configure	(working copy)
> @@ -1210,6 +1212,25 @@
>      targetos=irix
>      ranlib="echo ignoring ranlib"
>      ;;
> +  os/2)
> +    ln_s="cp -f"
> +    LIBSUF="_s.lib"
> +    SLIBPREF=""
> +    SLIBSUF=".dll"
> +    SLIBNAME_WITH_VERSION='$(SLIBPREF)$(NAME)-$(LIBVERSION)$(SLIBSUF)'
> +    SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(NAME)-$(LIBMAJOR)$(SLIBSUF)'
> +    SLIB_EXTRA_CMD='dllar -o $(SLIBNAME) $(LIB) -d $(SLIBNAME_WITH_MAJOR) -omf -ord $(LDFLAGS) $(EXTRALIBS) $(EXTRAOBJS); cp -f $(SLIBNAME) $(SLIBNAME_WITH_MAJOR)'

The cp -f command is redundant, look at common.mak more closely, it's
already there.

> +    SLIB_INSTALL_EXTRA_CMD='install -m 644 $(SLIBNAME:$(SLIBSUF)=.lib) $(LIBDIR)/$(LIBPREF)$(NAME)_dll.lib; install -m 644 $(SLIBNAME:$(SLIBSUF)=.a) $(LIBDIR)/$(LIBPREF)$(NAME)_dll.a'

$(SLIBNAME:$(SLIBSUF)=.a) could be simplified if you set LIBPREF and
used LIB.

Diego