Date: Sun, 18 Apr 2010 22:10:48 -0700 From: Xin LI <delphij@delphij.net> To: Doug Barton <dougb@FreeBSD.org> Cc: Garrett Cooper <yanefbsd@gmail.com>, jsa@wickedmachine.net, freebsd-ports@freebsd.org Subject: Re: VLC does not support the audio or video format "XVID". Message-ID: <4BCBE5D8.2050207@delphij.net> In-Reply-To: <4BCB9F97.1010401@FreeBSD.org> References: <4BCAAB3F.5020407@FreeBSD.org> <4BCB7DA9.40105@FreeBSD.org> <n2s7d6fde3d1004181630u52c0c57cu26d207511307dc0f@mail.gmail.com> <4BCB9F97.1010401@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010/04/18 17:11, Doug Barton wrote: > On 04/18/10 16:30, Garrett Cooper wrote: >> On Sun, Apr 18, 2010 at 2:46 PM, Doug Barton <dougb@freebsd.org> wrote: >> >>> My plan at this point is to re-upgrade to the latest -current, record >>> the error I get from libxml2 when recompiling openbox, and then try >>> recompiling stuff until I find the one that does the trick. Worst case >>> scenario I do 'portmaster -f vlc' but that constitutes 175 ports, which >>> would take a while. >> >> Yeah... that's what I thought it was. > > So we each get a cookie. :) My plan worked, and after recompiling > gpac-libgpac vlc can once again understand divx. The error I got when > trying to rebuild openbox with an old libxlm2 (linked against the old > libz) was: undefined reference to `gzopen@ZLIBprivate_1.0' > > Which makes sense because if I'm reading the change in r206709 right, > that's exactly what happened (gzopen et al moved from the private > interface to the public one). > > For delphij's sake I'm not sure if there is a "bug" here. For something > with less subtle use of shared libs the solution would have been > obvious. It's the fact that (as Garrett pointed out) vlc plays tricks > that masked the real source of the problem. Sorry for that. It looks like that the zlib author decided to drop usage of *64 functions on non-LFS64 platforms (in the past for instance gzopen() is #define'd as gzopen64()). To prevent future breakage, I think the only way to get around of this would be to move all potential "public" interfaces to the ZLIB_1.2.4.0 part. E.g. make sure that those exposed by zlib.h are always available in the same public namespace rather than only exposing the "available" ones. I'm working on an interface checker program to make sure that the "committed" interfaces won't change again. Cheers, - -- Xin LI <delphij@delphij.net> http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLy+XYAAoJEATO+BI/yjfBcN0IANAhfgkH0g7iwKHepAan3xGa VYDaF0r1t5SEUfcBIt0qyHYaw1+P/wBMl9MNGRQLAwUWEZmL5ZGOyOu1hhTM2RHx tdQ6q8dRgk2g1xa04YYcZ62sNmlGVVcTmOfKGINcWMkIcDFWj8w9AegYvBslopq+ LHB2rxMSBdasbooJtkUiUH03gnP1zdnide1CfoP/2PfAJzx5/F4ITFhEFoSt0+eH lXDGSPGygggI/wwy+9vEryyajFrQsiRHWhwzkwNdNZizBQP6uNNPdPjdZEa+8/59 dptJNneLMYHzqxq5Fe/J4LNm1MKMMgpKX97HmZUyswljk05fH80xIAT27hkEiTM= =lScc -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BCBE5D8.2050207>