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

[KO Myung-Hun]

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.
> 

Even if it's a bug of ramfs.ifs, its bug should be considered when using
ln -s.

> 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).
> 

However, some shells such as bash and pdksh using EMX does not support a
symbolic link. In addition, there are people not using ln -s for
compatibility. So if possible, it would be better to avoid a symbolic link.

Anyway, test if ln -s really works and override ln_s if it fails.

-- 
KO Myung-Hun

Using Mozilla SeaMonkey 2.7.2
Under OS/2 Warp 4 for Korean with FixPak #15
In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM

Korean OS/2 User Community : http://www.ecomstation.co.kr