[waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window

[Jordan Justen]

On Sun, May 25, 2014 at 2:43 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 25/05/14 21:35, Jordan Justen wrote:
>> On Sat, May 24, 2014 at 12:28 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>> * Library dependencies, etc. (low priority)
>>> libwaffle-1.dll depends on mingw-w64 dlls - should we nuke the dependency,
>>> ship them in the zip or leave it to the user/dev ?
>>>
>>>   Library:
>>>     libgcc_s
>>>       __emutls_get_address
>>>       __udivdi3
>>>       __umoddi3
>>>
>>>   Options:
>>>     - Static link libgcc_s, generally not bad idea
> sigh, a bit of a typo here - the above should read:
>
> - Static link libgcc_s - generally _a bad_ idea

Doesn't gcc/binutils automatically do this when you compile/link?

>> What are the licensing implications?
>>
> That's possibly the main reason why I'm inclined to go with rework. I've never
> been good at the legal/licensing terms.
>
>> I think libgcc would be covered by this exception, right?
>> https://www.gnu.org/licenses/gcc-exception-3.1-faq.html
>>
>> If so, it seems like static linking might not be a problem.
>>
> IIUC you are correct. waffle is gpl-compatible (2-clause BSD), and no
> gpl-incompatible software is used during the "Compilation Process", thus we
> are "Eligible".

It sounds they only mean to prevent non-GPL compatible code from
getting into the internals of the GCC complication process. So, in
other words, you can't have a proprietary GCC plugin, and also use the
exception to link to libgcc, etc.

But, it seems like even proprietary code could use the exception to
link to libgcc as long as it was just being compiled by GCC.

>>>     - or, rework waffle ?
>>>           Split merged_version or move to (major << 8 | minor) for the
>>>           wcore_config_attrs_version_* helpers - will nuke the last two.
>>>           No idea how to nuke __emutls_get_address.
>>>
>>>   Suggestion:
>>>     Split to separate major/minor.
>>>
>>>
>>>   Library:
>>>      libwinpthread-1
>>>        pthread_key_create
>>>        pthread_mutex_lock
>>>        pthread_mutex_unlock
>>>        pthread_once
>>>        pthread_setspecific
>>>
>>>   Options:
>>>      - Static link
>>
>> What are the licensing implications?
>>
>> It doesn't look as good as the libgcc case.
>>
> The library is a combination of X/MIT and 3-clause BSD. Which afaics is rather
> vague on the topic of static linking the library and distribution of the final
> binary(ies). My guess is that we ought to be safe but IANAL.

This wasn't my concern. I was concerned the library might have been
GPL licensed, and thus the waffle DLL wouldn't be usable with a
proprietary application.

Chad, would you be okay with releasing the windows waffle DLL and
noting that it is partially covered by X/MIT, 3-clause BSD and
2-clause BSD?

> If I understand things correctly we are safe to ship the library, as long we
> abide the rules - include licenses, no advertisement, no liability.
>
>>>      - or, rebuild mingw-w64-gcc with --enable-threads=win32
>>
>> It sounds like Chad wouldn't be able to use the standard mingw from
>> his distro then, right?
>>
> Unfortunately you are absolutely right. Rebuilding things under Archlinux are
> easy as pie, although I'm not sure his main choice of a distribution.

I'd guess that he likely has arch running somewhere. :)

I'd still prefer a solution where this wasn't required.

-Jordan