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

[Jordan Justen]

On Wed, Jun 4, 2014 at 1:18 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
> ----- Original Message -----
>> On Sun, May 25, 2014 at 08:00:49PM -0700, Jordan Justen wrote:
>> > 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://urldefense.proofpoint.com/v1/url?u=https://www.gnu.org/licenses/gcc-exception-3.1-faq.html&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=0dWLL1eK7zXGaHLwGR8JQNvgR0iR%2BeSjmnMVBlMUMwU%3D%0A&s=f5e6e804df74284b34407c9df79fcd092ac004d7341177df10dd1859df58f389
>> > >>
>> > >> 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 Waffle needs a stacked license to support Win32, that's ok with me.
>> Liberal licenses in the BSD, MIT, and Apache family are all acceptable.
>>
>> I am not a lawyer either, so I do not know if statically linking the
>> parts you speak of are safe to do so. I think you should make your
>> initial decision based on its technical merits. Then, after the
>> technical, decision is made but before you've invested too much time in
>> it, all of us (you, Jordan, me, Jose) should analyze any license issues.
>>
>> FWIW, I prefer to avoid runtime dependency hell by statically linking
>> small, problematic components. But my opinion is of limited value here,
>> because I'm unfamiliar with the problem domain of mingw and MSVC.
>
> FWIW, my opinion is that we shouldn't get too distracted by licensing and what release binaries should look like.  It is not something that needs to be decided now, or ever: ultimately, that decision can be pushed to the final user.  They might prefer mingw, they might prefer msvc for easy of debugging, or because they want to statically link, etc.
>

I thought we wanted to go ahead an provide a binary build for windows, and thus:
1. It should be buildable under Linux using mingw
2. The binary should have a reasonable license situation

Didn't we already pretty much have this worked out anyhow?

> IMHO the most important is getting waffle to build and run on Windows on some form.

Sure, if using mingw is holding Emil back, but I don't think it is. Right?

-Jordan