Hmmmmmmm.......

On Mon, Dec 19, 2016 at 11:51:36AM +0200, Martin Storsjö wrote:
> It seems like checkasm has started failing to build in MSVC DLL setups
> recently, see e.g. this instance:
> https://fate.libav.org/i686-msvc-10-dll-wine
> 
> The reason is that once you build with --enable-shared with MSVC, you can't
> link those object files via static libraries any longer. (See
> d66c52c2b369401ba4face1c171ccb19130b7a31, that added support for MSVC built
> DLLs, for the full explanation.) And checkasm links to the libs statically
> in order to link to non-exported fucntions.
> 
> In practice, this hasn't been an issue so far, but since
> 972c71e9cb63e24f57ee481e413199c7d88a8813, checkasm seems to pull in enough
> object files from libavcodec to start exhibiting the problem I explained in
> the commit when MSVC DLL support as added above. So it has only worked by
> coincidence so far.
> 
> We could of course try to figure out what part of the dsp object files that
> checkasm links suddenly pulls in bsf code in this link, but that'd also be
> just hacking around the problem.

I'm afraid we're hacking around the problem either way and the only proper
solution is to rid ourselves of avpriv_, which is basically the devil.

> Since checkasm in MSVC DLL builds isn't that important, since it's covered
> pretty well in other test setups anyway, I would suggest to just disable
> checkasm in this case. We easily have got CONFIG_SHARED available in
> makefile, but I guess we'd need to add something else to identify MSVC. Or
> just a "disable checkasm" or similar, somewhere in configure?

I pointed out how you could achieve this by adding a CONFIG_STATIC condition
in the right place, but what about the other TESTPROGS? The situation wrt
them seems equally brittle. At any point in the future some avpriv_ symbol
might get pulled in and break linking them. Disabling all the tests that
use TESTPROGS also seems undesirable since we're speaking of 200+ tests.
The seek tests are among them...

This looks like a dilemma where all the alternatives are hacks to me...

Diego
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to