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

Wed Jun 4 23:49:37 PDT 2014

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

Oops. Ended up removing the link -- http://people.freedesktop.org/~jrfonseca/apitrace/README.txt

Jose

> ; 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
> _______________________________________________
> waffle mailing list
> waffle at lists.freedesktop.org
> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/waffle&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=wBufIoCLIVTyFMY7jitI%2FOuu8XEM1IC3lK3NQCbeLvg%3D%0A&s=763cac9fda3eaf8ccdb8befc07c14f79d2ddc6b1316555c4fe83f5549918bb1a
> 