[FFmpeg-devel] [PATCH] Re-add OS/2 support
Mon Oct 8 15:28:03 CEST 2007
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 @@
> 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
> + 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
More information about the ffmpeg-devel