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

Dmitriy Kuminov coding at dmik.org
Mon Apr 18 15:19:04 CEST 2016

On 2016-04-18 11:52:15 +0000, KO Myung-Hun said:

> Strange conclusion. Anyway not important.

In Dave's case the symlink functionality check fails because it is 
performed in TMPDIR which is located on ramfs.ifs (which fails to use 
symlinks). But I believe his real build directory is not on ramfs.ifs 
and symlinks are in fact supported there (and can be used). But this 
problem is not OS/2-specific, it may happen on any platform where 
TMPDIR is on a volume that doesn't support symlinks for sojme reason. I 
think the FFmpeg guys should fix this check to make it performed inside 
the build directory, not in TMPDIR.

> Good to know that. I wish to see the latest bash for OS/2 soon.

Well, in fact, having bash would be not bad indeed, but since it has 
little impact on end users, this is postponed for later. Your 
contribution is (as always) welcome.

> I meant those who don't use ln at all for compatibility with other OS/2
> programs not built with kLIBC, like me.

Okay, but still. I don't think ongoing OS/2 development should be 
chained by people like you :) (nothing personal, of course). For 
instance, you won't be able to build the latest Firefox if your system 
doesn't support symlinks (at least because of python's virtualenv). And 
I'm not going to invest time in making it work in such a case, not at 
all (it's a pure waste). This is clearly offtopic for this mailing list 
though, so let's continue this conversation in private if you want.

> My "correction" is not removing ln_s overriding. I don't want to use ln
> -s on OS/2.

Sorry but I really doubt things affecting other people should happen or 
not happen just because you want it or not. We are all here to 
collaborate. I added what I needed and what I think is the best. You 
don't agree, that's OK, so I offered you a compromise - write your own 
patch that will make it work for you the way you want it w/o breaking 
what I need. You refuse to do so and I don't find it collaborative. 
It's upto FFmpeg maintainers to decide what to do here, but I won't 
accept symlink usage removal in our repositiries. I will, however, 
accept your patch that will allow to go both ways (with the symlink 
usage being the default choice if supported by the underlying IFS).

Kind regards,
Dmitriy Kuminov
CPO of bww bitwise works GmbH

More information about the ffmpeg-devel mailing list