On Sat, 31 Dec 2016, Diego Biurrun wrote:
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.
Yes. In this particular case, getting rid of the avpriv data symbols is
enough; the avpriv functions are harmless wrt this.
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...
I don't see that as being too bad. Given the choice between removing these
fate instances altogether (or, playing devil's advocate even further,
removing the MSVC DLL support altogether, since it's something of a hack
wrt avpriv data), or disabling a couple hundred of the tests, I much
prefer disabling these tests.
We've got corresponding fate instances that test the library internals in
general, thoroughly, without building as DLLs. When building as DLLs, the
only thing that you really can test is avconv.exe.
This looks like a dilemma where all the alternatives are hacks to me...
Well, partially yes. But the patch I posted based on your suggestion isn't
all that wrong either (although incomplete wrt testprogs); if
CONFIG_STATIC is disabled, one probably shouldn't try to link checkasm
(and the others).
Basically, as far as I know, the only fate instances with CONFIG_STATIC
disabled would be my MSVC DLL ones.
It would probably hit people building with --disable-static (wanting to
redistribute only e.g. shared libs), making a "make check" in their builds
test things a little less thoroughly, but I would see that as an
acceptable compromise.
// Martin
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
