[vlc-devel] report from the Win32 front

[John Freed]

On Sun, Jan 29, 2012 at 10:57 PM, <vlc-devel-request at videolan.org> wrote:
>
> Le 2012-01-29 14:31, Jean-Baptiste Kempf a ?crit :
> > 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.
>
> You could build contribs from source to fix that, or take the moc 4.7.4
> binary from debian.
>
> Hmm... hadn't thought of just downgrading that and not the rest, though it
would make yum very unhappy.

>> 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.
>
> We can accept or look at the patches anyway, so please send them
>
> will do


> >> 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.
>
> Strange, configure should do that already
>
> it does, it seems. I'm retracing my footsteps to minimize the changes from
the documented non-Fedora mingw32 page. Will be updating the documentation
once I've backed out as many of the exceptions as I can.


> >> 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.
>
> Nope there's none
>
> well, those vlclib files aren't moved from the _win32 directory, which
strikes me as odd but in any event pkg-config won't find them there!


> >> 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,
>
> The win64 one has them (uses different compiler)
>
> >> 2) that formula does not produce the location specified in Fedora.
>
> What does it give? Where are the DLLs (if they are here) ?
>
> the existing formula gives the first entry in LIBRARY_PATH, which on
Fedora 16 is:
/usr/lib64/gcc/i686-pc-mingw32/4.6.1/

In fact, the two DLLs (on F16) are in:
/usr/i686-pc-mingw32/sys-root/mingw/bin/



> > 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.
>
> When I asked mingw-w64 developers about it they gave me good reasons to
> not use C++ static linking (with exceptions?).
>
> I don't remember them at the moment but either:
>
> - it's a mingw-w64 specific problem
> - you don't know what you're talking about
> - debian mingw-w64 package is buggy and/or we need to force auto* to
> link statically
> - probably other options
>
> No idea which one it is but input is welcome.
>
> i shan't get involved in this!!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20120129/2694b3dd/attachment.html>