[FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.

Dave Yeo daveryeo at telus.net
Tue Apr 19 08:03:52 CEST 2016


On 04/16/16 11:00 AM, Dmitriy Kuminov wrote:
> On 2016-04-16 17:24:12 +0000, Dave Yeo said:
>
>> Actually I now get this at the beginning of the configure run, using a
>> ramfs.ifs volume for $TMPDIR,
>>
>> [K:\usr\local\src\ffmpeg.obj]sh ../ffmpeg/configure --enable-gpl
>> --disable-doc --samples=/usr/local/share/fate-suite --cpu=i686
>> --extra-libs=-lpoll --prefix='r:/tmp/ffmpeg' --disable-static
>> --enable-shared
>> ln: failed to create symbolic link `R:/tmp/name_VJhuEZNf': Operation not
>> supported on socket
>
> Hmm, interesting use case. I bet this is because ramfs.ifs has some
> problems with EAs (which are needed for proper symlink support on OS/2).
> Looks like a ramfs.ifs bug to me.

While ramfs.ifs has a few shortcomings, it dies support 64kbs of EAs, 
which shouldbe enough for most uses. Perhaps the problem is lack of 
DosFindNotify() or file locking.

>
> And yes, it seems that the master branch uses ln_s not only in DLL
> creation but also to symlink to src in the shadow build tree (I was
> checking against the 2.8 branch before where it was not used). It,
> however, contains a fallback code that should cover the failure in your
> case (if I read it right). So I still think we should remove ln_s
> redefinition via cp on OS/2 in FFmpeg. In case of a proper IFS (I have
> JFS here but HPFS is also fine) symlinking src works like a charm
> (performed a full build).
>

The problem is that symlinks on OS/2 (unless using TVFS.IFS) are 
inherently fragile. It just takes one utility that is not aware of them 
to break things and not everything is linked against kLIBC. In FFmpegs 
case we use lxlite, which is a Pascal program and knows nothing of symlinks.
I personally prefer to only use symlinks when needed, such as 
_virtualenv, and currently using my older environment can often pass all 
the FATE tests, whereas the new environment has more failures.
As leaving it in doesn't hurt your use case anyways, my vote is to leave 
it in.
Dave
http://fate.ffmpeg.org/history.cgi?slot=x86.os2.446
http://fate.ffmpeg.org/history.cgi?slot=x86.os2.492





More information about the ffmpeg-devel mailing list