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.<div><br></div><div>Now, to the rest ...<br><br><div class="gmail_quote">On Sun, Jan 29, 2012 at 8:39 PM,  <span dir="ltr"><<a href="mailto:vlc-devel-request@videolan.org">vlc-devel-request@videolan.org</a>></span> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sun, Jan 29, 2012 at 08:14:25PM +0100, John Freed wrote :<br>
> 1) upgrading to Qt 4.8<br>
> Fedora 16 uses Qt 4.8. I had hoped I could fool MOC into using the 4.7.4<br>
> libs, but failed. Not wanting to downgrade to Qt 4.7 (essentially moving<br>
> back to Fedora 15) and too lazy to use a virtual machine, I upgraded my<br>
> contribs to Qt 4.8. I figured VLC will eventually move there anyhow, so why<br>
> not try? The good news is, this required only a couple of tiny patches to<br>
> work. I'll be happy to submit if you want.<br>
<br>
We will move to Qt 4.8 eventually, but, I would prefer to avoid .0<br>
releases of Qt, because of the issual issue we have in those releases.<br>
<br></blockquote><div>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. :)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> 2) building using Mingw32 under Fedora<br>
> It was necessary to<br>
> set PKG_CONFIG_LIBDIR=../contrib/i686-pc-mingw32/lib/pkgconfig for building<br>
> both the vlc.exe binary and the installation package. I'll note that in the<br>
> Fedora build wiki page.<br>
Cool.<br>
<br></blockquote><div>done.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> There was a new error introduced that did not appear in the Linux build.<br>
> Specifically, the mingw compiler barfed at this line in<br>
> modules/gui/qt4/components/playlist/playlist_model.cpp:<br>
> const PlMimeData *plMimeData = qobject_cast<const PlMimeData*>( data );<br>
> This needed to be changed to reinterpret_cast. (Same problem<br>
> in modules/gui/qt4/components/playlist/selector.cpp.) After that, the build<br>
> went fine.<br>
<br>
Those are wrong, I think. PLMimeData derives from QMimeData derives from<br>
QObject. Then, we should use qobject_cast.<br>
<br></blockquote><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> 3) building the win32 installation package.<br>
> Even with the correct PKG_CONFIG_LIBDIR, "make package-win-common"<br>
> complained that it could not find LIBVLC. I'm guessing there is some<br>
> interim problem with the build process or there is a workaround used on the<br>
> buildbot machine. In any case, I found the .pc file and tried to tell<br>
> pkg-config to use it, but that didn't work for me, so I manually set the<br>
> CFLAGS and LIBS environment variables as follows:<br>
><br>
> LIBVLC_CFLAGS=-I/usr/src/winvlc/win32/_win32/include<br>
> LIBVLC_LIBS="-L/usr/src/winvlc/win32/_win32/lib -lvlc" make<br>
> package-win-common<br>
><br>
> /usr/src/winvlc/win32/ is the directory I was building from, so these are<br>
> in the _win32/include and _win32/lib relative directories.<br>
<br>
For npapi?<br>
<br></blockquote><div>I think yes. See <a href="http://forum.videolan.org/viewtopic.php?f=32&t=97311&p=324928#p324928">http://forum.videolan.org/viewtopic.php?f=32&t=97311&p=324928#p324928</a> </div><div>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> ONE final problem, that's finding the two files libstdc++-6.dll and<br>
> libgcc_s_sjlj-1.dll<br>
><br>
> The file Makefile.in in the build root directory uses this formula to find<br>
> them:<br>
><br>
> gcc_lib_dir=`$(CXX) -v /dev/null 2>&1 | grep ^LIBRARY_PATH|cut -d= -f2|cut<br>
> -d: -f1`<br>
><br>
> A couple of observations: 1) the current nightly builds don't include those<br>
> files, so I suspect they're not being found even by the VLC buildbots, 2)<br>
> that formula does not produce the location specified in Fedora.<br>
<br>
You should not use those dlls at all for VLC. They give a lot of<br>
problems and headaches when releasing and when using libVLC application.<br>
<br>
The NB do not have it, because this is statically linked, as it should.<br>
<br></blockquote><div>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?</div>
<div><br></div></div></div>