[vlc-devel] [vlc-commits] configure: unbreak cross-pkg-config support with contrib

Rémi Denis-Courmont remi at remlab.net
Tue Mar 4 11:42:02 CET 2014

On Tue, 04 Mar 2014 11:19:17 +0100, Rafaël Carré <funman at videolan.org>
>>> Again you are avoiding the details such as bug number for this
>>> hypothetical problem.
>> #10507 dude. The bug is over a year old and the report over a month
>> old...
> Cool, so now I am aware of it at least.
>>>> - Packaging depends on a hard-coded path to WINE for the ActiveX.
>>>> breaks any system who WINE path does not match that of the Makefile
>>>> author
>>>> (including any recent Linux distro), and prevents builds from
>>> You can always set WINE_SDK_PATH.
>> Indeed I probably can set my non-standard WINE path. And you can set
>> non-standard PKG_CONFIG_LIBDIR.
>> Instead, I just gave up, made some hacks. And I kept them for myself
>> because I don't push hacks to the tree on the sole basis that they fix
>> build.
> I just checked that wine.git still installs in
> Not sure what's your point here.

I don't think that works with multiarch distros. That said, I just gave up
on NPAPI at that point and made a custom unpublished hack. So I have not
dug the problem very deeply.

> In any case you didn't report it when you noticed that problem.

I was not sure if it was a problem with my system or a bug, and it's only
been two days. Besides the would-be bug was hidden behind the OBJCXX bug,
which looks far more serious and yet is still unfixed.

>>> mingw-w64-tools does not and will not provide pkg-config.
>> In Debian, it does. I got there by following the wiki Win32 compilation
>> instructions by the way. And they do claim to support my Debian version
>> for
>> build.
> Sure we claim to support the ever moving Debian sid, and it never

Indeed it may be unreasonable, but that is how the wiki read anyway.

> There is also the option of talking to me directly about the problems
> you have, but I'm sure you never considered doing this.

See below.
>> Tell that to JB. That's coming from JB. And at least Ludovic confirmed
>> hitting the same problem.
> And I told them how to fix it...

That's between them and you and I am unable to comment. All I see from my
vantage point is that this is not fixed in VLC.git, Debian Sid, Mingw-w64
and/or wherever it should be fixed.

> But as you refuse talking to me (and people tell me that it looks
> like a small child behaviour) you would of
> course not get the advice straight from the source.

Our mutually frequently hostile attitude tells me that it is preferable
for me to leave you alone as much as practical. I don't know if this is
childish, but I will note that a number of people have recommended that
attitude to me.

>>> *gcc* links to pthread and of course it depends on how it was
>> configured.
>>>> - Also with that, VLC depends on gcc_s without sources for it.
>>> http://www.gnu.org/licenses/gcc-exception.html
>> That's an excuse for ignoring GCC's license, not VLC's license, and
>> unincidentally my copyrights.
> So VLC license and your copyrights apply to libgcc? hmm..

GPL contamination by VLC requires the libgcc_s source code.

Rémi Denis-Courmont
Sent from my collocated server

More information about the vlc-devel mailing list