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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
