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

[Jordan Justen]

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

What are the licensing implications?

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.

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

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

>      - or, rework current code (open to suggestions)?

Such as re-implementing the pthreads specific code using windows
threads when building for windows?

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