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

[Rémi Denis-Courmont]

On Tue, 04 Mar 2014 11:19:17 +0100, Rafaël Carré <funman at videolan.org>
wrote:
>>> 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.
That
>>>> breaks any system who WINE path does not match that of the Makefile
>>>> author
>>>> (including any recent Linux distro), and prevents builds from
non-x86.
>>>
>>> You can always set WINE_SDK_PATH.
>> 
>> Indeed I probably can set my non-standard WINE path. And you can set
your
>> 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
my
>> build.
> 
> I just checked that wine.git still installs in
prefix/include/wine/windows
> 
> 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
breaks.

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