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

Wed Jun 4 23:47:32 PDT 2014

----- Original Message -----
> 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?

Maybe I misinterpreted things.  I always saw mingw as a mean to an end, to facilitate development and get things started (ie, without forcing Emil to obtain and learn to use use a completely new set of tools).  And not the end itself (distribute binaries to the world), because:

 - MinGW often generates bad code, I've seen it happening with Mesa and Apitrace [1]; so I while use MinGW debug binaries all the time, I don't trust MinGW to produce distributable release binaries
 - MinGW debug information is not understood by MSVC tools, so when an MSVC user debugs its code, it won't be able to get any symbols from waffle if waffle was build with MinGW

IMHO, the best sort of binaries are .DLLs produced by MSVC (any version) with statically linked CRT (so no additional dependencies -- no need to ship MSVC redistributables installer).  And they should be usable with applications built with anything (MSVC MinGW)  

Anyway, this is just a mere suggestion.  I can always build my own binaries from source if needed.

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

No, using mingw is great as development.  But it looked to me that figuring out the license situation was a distraction. (Specially if we'll end up needing to produce MSVC binaries anyway, when the port is ready for wider audience.)

Jose