On Fri, Jul 28, 2017 at 01:57:53PM +0200, Nicolas George wrote: > Le decadi 10 thermidor, an CCXXV, Clement Boesch a écrit : > > From: Clément Bœsch <cboe...@gopro.com> > > > > --- > > configure | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > I am not sure exactly what the code does, but I think it must make a > difference between iconv provided by the libc on good Unix systems and > iconv provided by GNU libiconv. > > When iconv is provided by the system's libc, then I think it should be > enabled automatically.
I'm not changing the behaviour here, iconv is already autodetected. Though, --disable-autodetect will disable its auto-detection, be it a "system" or a randomly installed library. > It does not go against reproducible builds, I > think. Well, being maintained by the base system or through a normal package doesn't make much difference since the system can also gets updated with a new iconv (major bumped). Here are some exceptions I can think of: libc (well, hard to get around this one) and pthread. AFAIK the later may be replaced by "native" code; I think clang doesn't rely on a library for this, so I'm assuming there is no such thing as a link to libpthread in the final program. So, unless iconv is a native feature of the compiler causing the final program not to link against any external library, I don't think iconv should be enabled by default. Regards, -- Clément B.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
