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

[Emil Velikov]

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

> 
> 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".

>>     - 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.

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.

>>      - or, rework current code (open to suggestions)?
> 
> Such as re-implementing the pthreads specific code using windows
> threads when building for windows?
> 
I was thinking more of "ripping the code out for windows builds" :] And yes
this is not what I would like to do.

-Emil

> It seems like this is last on your list, so I guess that isn't very
> appealing? :)
> 
> -Jordan
> 
>>   Suggestion:
>>     The above list states my order of preference.
>>
>>
>> Any feedback would be great. Meanwhile I will send out a few misc/cleanup
>> patches :)
>>
>> Cheers,
>> Emil