On Fri, 9 Aug 2013 09:36:02 +0200, Hendrik Leppkes <h.lepp...@gmail.com> wrote: > 1) Rever the whole set. We've been fine without close-on-exec for > years, and it causes this major headache.
So you say. I can also say that I've been fine without linking multiple instances of the CRT in a single project, and indeed it causes major headaches. > 2) Partly revert the set, only use the flag on "open" calls, no > wrapper for fcntl. > > 3) Call shared builds with static CRT unsupported. I personally do not > agree with this, since its a perfectly valid use-case, as it avoids > the need for the user to install the CRT version matching your > compiler (which usually annoys users) That looks invalid to me. The libav* libraries and your executable or library all share the libavutil ABI, and by way of it, the C ABI. Running a single instance of libavutil and multiple instance of the CRT seems completely insane to me. At the very least, you'd have to link libavutil statically too, but arguably you should link everything statically into your DLL/EXE; that is the only sane option IMO. > 4) inline avpriv_open, this will most likely end up being rather ugly, > especially with the wchar open wrapper for win32 > > 5) Rename to ff_open and clone the symbol into all libraries, like > done with some data symbols. > > Personally, i would favor 2, but as a Windows user that whole flag > doesn't exist/work anyway, On Windows, the default (in this case, the saner default) is to not inherit handles. That does not mean the notion is non-existent. > so i may not see the big advantage of > supporting legacy systems with fnctl and the like. FWIW, legacy systems include all released versions of MacOS, or generally any non-2008-conformant POSIX system. I don't care about any of these. But I am pretty sure some people do. -- Rémi Denis-Courmont Sent from my collocated server _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
