[vlc-devel] report from the Win32 front

[John Freed]

First of all, apologies for the long first message, which I didn't realize
I had sent. I really don't like the new Gmail interface.

Now, to the rest ...

On Sun, Jan 29, 2012 at 8:39 PM, <vlc-devel-request at videolan.org> wrote:
>
> On Sun, Jan 29, 2012 at 08:14:25PM +0100, John Freed wrote :
> > 1) upgrading to Qt 4.8
> > Fedora 16 uses Qt 4.8. I had hoped I could fool MOC into using the 4.7.4
> > libs, but failed. Not wanting to downgrade to Qt 4.7 (essentially moving
> > back to Fedora 15) and too lazy to use a virtual machine, I upgraded my
> > contribs to Qt 4.8. I figured VLC will eventually move there anyhow, so
> why
> > not try? The good news is, this required only a couple of tiny patches to
> > work. I'll be happy to submit if you want.
>
> We will move to Qt 4.8 eventually, but, I would prefer to avoid .0
> releases of Qt, because of the issual issue we have in those releases.
>
> Very sensible. I'll keep using it more out of necessity than desire, but
so far so good. I personally avoid any software that ends in .0, which is
one reason I recommended that the next release be 2.1 not 2.0. :)


> > 2) building using Mingw32 under Fedora
> > It was necessary to
> > set PKG_CONFIG_LIBDIR=../contrib/i686-pc-mingw32/lib/pkgconfig for
> building
> > both the vlc.exe binary and the installation package. I'll note that in
> the
> > Fedora build wiki page.
> Cool.
>
> done.


> > There was a new error introduced that did not appear in the Linux build.
> > Specifically, the mingw compiler barfed at this line in
> > modules/gui/qt4/components/playlist/playlist_model.cpp:
> > const PlMimeData *plMimeData = qobject_cast<const PlMimeData*>( data );
> > This needed to be changed to reinterpret_cast. (Same problem
> > in modules/gui/qt4/components/playlist/selector.cpp.) After that, the
> build
> > went fine.
>
> Those are wrong, I think. PLMimeData derives from QMimeData derives from
> QObject. Then, we should use qobject_cast.
>
> Well, perhaps in theory, but in fact it didn't work. I for one am
mystified at casting a const to a different sort of const, even if in a
derived class, but I am no expert on casting. The new object is passed to
routines that have things like "Add" and "Del" in the name; if its memory
footprint in fact changes, I'd think the result would be undefined and
would depend on the good graces of the operating system.



> > 3) building the win32 installation package.
> > Even with the correct PKG_CONFIG_LIBDIR, "make package-win-common"
> > complained that it could not find LIBVLC. I'm guessing there is some
> > interim problem with the build process or there is a workaround used on
> the
> > buildbot machine. In any case, I found the .pc file and tried to tell
> > pkg-config to use it, but that didn't work for me, so I manually set the
> > CFLAGS and LIBS environment variables as follows:
> >
> > LIBVLC_CFLAGS=-I/usr/src/winvlc/win32/_win32/include
> > LIBVLC_LIBS="-L/usr/src/winvlc/win32/_win32/lib -lvlc" make
> > package-win-common
> >
> > /usr/src/winvlc/win32/ is the directory I was building from, so these are
> > in the _win32/include and _win32/lib relative directories.
>
> For npapi?
>
> I think yes. See
http://forum.videolan.org/viewtopic.php?f=32&t=97311&p=324928#p324928

> ONE final problem, that's finding the two files libstdc++-6.dll and
> > libgcc_s_sjlj-1.dll
> >
> > The file Makefile.in in the build root directory uses this formula to
> find
> > them:
> >
> > gcc_lib_dir=`$(CXX) -v /dev/null 2>&1 | grep ^LIBRARY_PATH|cut -d=
> -f2|cut
> > -d: -f1`
> >
> > A couple of observations: 1) the current nightly builds don't include
> those
> > files, so I suspect they're not being found even by the VLC buildbots, 2)
> > that formula does not produce the location specified in Fedora.
>
> You should not use those dlls at all for VLC. They give a lot of
> problems and headaches when releasing and when using libVLC application.
>
> The NB do not have it, because this is statically linked, as it should.
>
> Good to know. The latest NB doesn't work for me at all on a WinXP virtual
machine, nor on another machine that I think is running Win7. Nor, for that
matter, does my own build from git without these two DLLs. I discovered
they were missing by running the executable under Wine (!!!). It complained
right off the bat that those DLLs were missing, and when I added them, all
is OK. (Amazingly, VLC for Win32 runs under Wine. Who knew?) So there is
some other problem, I guess ... possibly related to the forum topic noted
above?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20120129/3a4d5c58/attachment.html>