On Thu, Nov 28, 2013 at 10:48:00AM +0200, Martin Storsjö wrote:
> On Wed, 27 Nov 2013, Diego Biurrun wrote:
> >On Wed, Nov 27, 2013 at 10:15:09PM +0200, Martin Storsjö wrote:
> >>On Wed, 27 Nov 2013, Diego Biurrun wrote:
> >>>--- a/configure
> >>>+++ b/configure
> >>>@@ -3355,45 +3380,52 @@ esac
> >>>+ add_${pfx}cppflags -U__STRICT_ANSI__
> >>>+ elif check_${pfx}func_headers stdlib.h _get_doserrno; then
> >>>+ eval ${pfx}libc_type=msvcrt
> >>>+ add_compat strtod.o strtod=avpriv_strtod
> >>>+ add_compat msvcrt/snprintf.o snprintf=avpriv_snprintf \
> >>>+ _snprintf=avpriv_snprintf \
> >>>+ vsnprintf=avpriv_vsnprintf
> >>
> >>Things like add_compat here (and below) should only be done if this
> >>is the target libc, not if it's the host one. In general, every
> >>single action (add/set/whatever) in this needs to include $pfx in
> >>one way or another, otherwise it's doing something wrong.
> >
> >When using msvc as host compiler this is not necessary?
>
> Well, add_compat only adds the objects to be used in target
> complication anyway, so calling that based on the host libc
> detection is just broken anyway.
>
> Apparently we've been able to cope just fine without these with MSVC
> as host compiler so far. They are only added in the target
> compilation to amend the existing strtod/snprintf implementations to
> comply with more corner cases that we don't exercise in the host
> tools. For strtod, it's about parsing hex literal strings (which
> strtol can handle but not strtod in both msvcrt and bionic) - and I
> don't think any of the host tools use that feature. For snprintf,
> it's about getting the right semantics in case the buffer overflows
> (the msvcrt implementation doesn't null terminate it in this case,
> which the C standard says it should). So for target compilation,
> it's needed because otherwise a whole lot of string handling
> suddenly would be insecure. For host building, you're not (quite as
> much at least) exposed to the threat of any random incoming data,
> but only to the threat of what's in the libav source itself.
So basically we don't need it now and can maybe or even probably get
away with cutting a corner here, at least for the foreseeable future.
Still it would be cleaner to apply this to both host and target
compilation.
> So unless there's some real need, I wouldn't try to expand the
> add_compat framework for host building yet. (Hint: It's a little
> more work than you'd expect - you'd need to build these object files
> as compat/strtod_host.o or so, to separate them from the compat objs
> for the target.)
Oh, I'm aware of the need to build (some of) the object files for the
host again. I just stumbled across this very problem in my dvenc split
patch, which breaks when crossbuilding x86_32 on x86_64, since the dv
data tables are then in an object file needed both by the target lib
and the host hardcoded tables generator.
So maybe the time has come to allow building some of those object
files twice.
Diego
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
