[FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
coding at dmik.org
Tue Apr 19 15:51:12 CEST 2016
On 2016-04-19 06:03:52 +0000, Dave Yeo said:
> 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.
lxlite works with executables and we can't use symlinks for executables
anyway (because the kernel doesn't support them and won't be able to
load such binaries). If lxlite encounters a symlink to a dll or an exe,
it will simply skip it (becuase it will only see a text file) - and
this is asbolutely fine and safe. So lxlite is not a problem. You also
speak theoretically, like KOMH. In practice, I personally don't know a
single problem that would come out of symlinks and require something
non-trivial to solve it. And I do A LOT of stuff.
> 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.
I always use symlinks and have absolutely no problems with that. You
use the RPM/YUM UNIXROOT environment too (IIRC) so you indirectly use
them as well. I can assure you, you wouldn't see all the current OS/2
progress if we didn't switch to the Unix-based toolchain. And symlinks
is part of it. So it's not about the number of votes, it's about
progress and future.
Regarding tests, that's a different story. I believe symlinks have a
tiny contribution in test failures (if at all). And that's in general,
again. In case of FFmpeg, symlinks don't make any harm (at least you
didn't present any proof of that so far).
CPO of bww bitwise works GmbH
More information about the ffmpeg-devel