Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
- Original Message - On Wed, Jun 4, 2014 at 1:18 PM, Jose Fonseca jfons...@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.veli...@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.veli...@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.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=0dWLL1eK7zXGaHLwGR8JQNvgR0iR%2BeSjmnMVBlMUMwU%3D%0As=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
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
- Original Message - - Original Message - On Wed, Jun 4, 2014 at 1:18 PM, Jose Fonseca jfons...@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.veli...@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.veli...@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.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=0dWLL1eK7zXGaHLwGR8JQNvgR0iR%2BeSjmnMVBlMUMwU%3D%0As=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
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
On Wed, Jun 04, 2014 at 11:47:32PM -0700, Jose Fonseca wrote: 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. Jose, I had the same interpretation as you. Despite being useful for development, mingw was a mean to an end. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
On Wed, Jun 04, 2014 at 01:24:38PM -0700, Jose Fonseca wrote:
- Original Message -
On 02/06/14 19:55, Chad Versace wrote:
On Sat, May 31, 2014 at 12:02:10PM -0700, Jose Fonseca wrote:
- Original Message -
- Original Message -
On 24/05/14 20:28, Emil Velikov wrote:
Hi all,
Another round of interesting bits and bulbs.
Bit of an update:
The email came out a bit longer than expected, although it provides a
decent
list of possible solutions. Let me know which one you'll go with.
Four topics sorted by priority - high to low (based on my humble
opinion)
* ChoosePixelFormat - close yet quite different across platforms.
- glXChoosePixelFormat- depends on display (matches waffle's
model).
- CGLChoosePixelFormat- no dependencies.
- {wgl,}ChoosePixelFormat - depends on a device_context/existing
window.
To make things better, wgl functions depend on a current context as
well.
The
recommended way of doing things under windows seems to be the
following:
window_handle = CreateWindow(...)
device_context = GetDC(window_handle);
gl_rendering_context = wglCreateContext(device_context);
wglMakeCurrent (device_handle, gl_rendering_context);
// any of the following
wglGetProcAddress(...)
wglChoosePixelFormat(...)
wglMakeCurrent (device_handle, NULL);
wglDeleteContext (gl_rendering_context);
ReleaseDC(device_context);
DestroyWindow(window_handle);
Yep.
AFAICS waffle is unique wrt other projects (apitrace, epoxy, glut) as
it
allows the PixelFormat to be called prior to the creation of either
window
or
context.
If you could rewrite this problematic portion of Waffle's API, how would
you design it? I'm asking so that, if we do redesign Waffle's API one
day, it can better accommodate Windows and Mac.
One requirement of any API redesign, though, is to preserve the ability
to create a context and render into it without creating a throwaway
surface, as in EGL_KHR_surfaceless_context. (Through-away surfaces are
ok as long as they are internal to Waffle).
If I understand things correctly surface(egl)/drawable(glx) are not as
clearly
separated in wgl. At least not initially.
Redesign of Waffle's API sounds like an overkill imho, as the only thing we
need is an easier way get from context/config data to window. Otherwise
wcore_(context|config|window) will be dummies and everything will be stored
in
a wcore_display wrapper (wgl_display).
Perhaps the following rough flow illustrates things a bit better
Abstracting across many platforms is always complicated, and even more
if we can't run tests on all of them. So even if we end up
redesigning, it might be better to first get windows to work (even if
that requires a few hacks/assumptions) first, so we can run
tests/examples.
I totally agree. Let's focus on getting Windows working with the current
API, even if it requires imperfect hacks.
glx (in the following example window is optional)
display glx create_context window gl*
wgl (here window is the root, i.e. think of (wgl)window == (glx)display)
window create_context wgl/gl
Currently I shove everything in wgl_display, although a slightly cleaner
approach might be better.
This makes sense to me.
From my uninformed perspective, it seems that shoving the Win32
window/display/device/whatever into wgl_display is the best approach.
But you and Jose likely know better than me. Whatever you need to do to
get it to work.
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
- 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.veli...@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.veli...@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.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=0dWLL1eK7zXGaHLwGR8JQNvgR0iR%2BeSjmnMVBlMUMwU%3D%0As=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. IMHO the most important is getting waffle to build and run on Windows on some form. Jose ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
- Original Message - On 31/05/14 19:59, Jose Fonseca wrote: - Original Message - On 24/05/14 20:28, Emil Velikov wrote: [snip] AFAICS waffle is unique wrt other projects (apitrace, epoxy, glut) as it allows the PixelFormat to be called prior to the creation of either window or context. Options: - Create a window, choose format, destroy window. No guarantee that the function will behave the same for another window/device_context. In practice, the odds of this happening are very low. I'd recommend creating an invisible window, do your things then, keep the window around, and then merely double check later that things are not busted. Still not sure which one of the two you are recommending: Create a invisible(dummy) window initially and create a new one at wfl_window_create. or This one. But I'm not 100% what is the best way. Whatever works really. Jose Create a invisible(dummy) window initially and bring it up/use it at wfl_window_create/wfl_window_show. ? Pardon if the above question sound rather dull :) Thanks Emil You can see in https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/wgl/stw_ext_pbuffer.ck=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=EVvdAN6DpAMPSYORbM%2BCu4MTEMmLt5L7XFRXd%2Be9PvI%3D%0As=7d4dab293ed0b1192ad5e333f73785f2aa7efedbd4ea4ec656a41ff96078d8c3 how to create an invisible window (This is how Mesa implements pbuffers on Windows!.) Jose - or, create window, choose format, reuse window on waffle_window_create() Sanest solution. If windows is not created just make one (i.e. waffle_config_choose is not executed before waffle_window_create). - or, store the attributes, and invoke ChoosePixelFormat as waffle_window_create is executed. What if code-flow depends on waffle_config_choose's return value ? - or rework waffle API ... (no, please no) Suggestion: Cache the window, and reuse it on waffle_window_create. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
- Original Message -
On 02/06/14 19:55, Chad Versace wrote:
On Sat, May 31, 2014 at 12:02:10PM -0700, Jose Fonseca wrote:
- Original Message -
- Original Message -
On 24/05/14 20:28, Emil Velikov wrote:
Hi all,
Another round of interesting bits and bulbs.
Bit of an update:
The email came out a bit longer than expected, although it provides a
decent
list of possible solutions. Let me know which one you'll go with.
Four topics sorted by priority - high to low (based on my humble
opinion)
* ChoosePixelFormat - close yet quite different across platforms.
- glXChoosePixelFormat- depends on display (matches waffle's
model).
- CGLChoosePixelFormat- no dependencies.
- {wgl,}ChoosePixelFormat - depends on a device_context/existing
window.
To make things better, wgl functions depend on a current context as
well.
The
recommended way of doing things under windows seems to be the following:
window_handle = CreateWindow(...)
device_context = GetDC(window_handle);
gl_rendering_context = wglCreateContext(device_context);
wglMakeCurrent (device_handle, gl_rendering_context);
// any of the following
wglGetProcAddress(...)
wglChoosePixelFormat(...)
wglMakeCurrent (device_handle, NULL);
wglDeleteContext (gl_rendering_context);
ReleaseDC(device_context);
DestroyWindow(window_handle);
Yep.
AFAICS waffle is unique wrt other projects (apitrace, epoxy, glut) as it
allows the PixelFormat to be called prior to the creation of either
window
or
context.
If you could rewrite this problematic portion of Waffle's API, how would
you design it? I'm asking so that, if we do redesign Waffle's API one
day, it can better accommodate Windows and Mac.
One requirement of any API redesign, though, is to preserve the ability
to create a context and render into it without creating a throwaway
surface, as in EGL_KHR_surfaceless_context. (Through-away surfaces are
ok as long as they are internal to Waffle).
If I understand things correctly surface(egl)/drawable(glx) are not as
clearly
separated in wgl. At least not initially.
Redesign of Waffle's API sounds like an overkill imho, as the only thing we
need is an easier way get from context/config data to window. Otherwise
wcore_(context|config|window) will be dummies and everything will be stored
in
a wcore_display wrapper (wgl_display).
Perhaps the following rough flow illustrates things a bit better
Abstracting across many platforms is always complicated, and even more if we
can't run tests on all of them. So even if we end up redesigning, it might be
better to first get windows to work (even if that requires a few
hacks/assumptions) first, so we can run tests/examples.
glx (in the following example window is optional)
display glx create_context window gl*
wgl (here window is the root, i.e. think of (wgl)window == (glx)display)
window create_context wgl/gl
Currently I shove everything in wgl_display, although a slightly cleaner
approach might be better.
-Emil
Jose
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
On 04/06/14 21:18, Jose Fonseca 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.veli...@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.veli...@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.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=0dWLL1eK7zXGaHLwGR8JQNvgR0iR%2BeSjmnMVBlMUMwU%3D%0As=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. IMHO the most important is getting waffle to build and run on Windows on some form. Fair enough. Curious why did this get so much attention, perhaps the option leave it to the user/dev was not clear enough in my original email. -Emil Jose ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
On Wed, Jun 4, 2014 at 1:18 PM, Jose Fonseca jfons...@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.veli...@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.veli...@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.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=0dWLL1eK7zXGaHLwGR8JQNvgR0iR%2BeSjmnMVBlMUMwU%3D%0As=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 ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
On 02/06/14 19:55, Chad Versace wrote:
On Sat, May 31, 2014 at 12:02:10PM -0700, Jose Fonseca wrote:
- Original Message -
- Original Message -
On 24/05/14 20:28, Emil Velikov wrote:
Hi all,
Another round of interesting bits and bulbs.
Bit of an update:
The email came out a bit longer than expected, although it provides a
decent
list of possible solutions. Let me know which one you'll go with.
Four topics sorted by priority - high to low (based on my humble opinion)
* ChoosePixelFormat - close yet quite different across platforms.
- glXChoosePixelFormat- depends on display (matches waffle's
model).
- CGLChoosePixelFormat- no dependencies.
- {wgl,}ChoosePixelFormat - depends on a device_context/existing
window.
To make things better, wgl functions depend on a current context as well.
The
recommended way of doing things under windows seems to be the following:
window_handle = CreateWindow(...)
device_context = GetDC(window_handle);
gl_rendering_context = wglCreateContext(device_context);
wglMakeCurrent (device_handle, gl_rendering_context);
// any of the following
wglGetProcAddress(...)
wglChoosePixelFormat(...)
wglMakeCurrent (device_handle, NULL);
wglDeleteContext (gl_rendering_context);
ReleaseDC(device_context);
DestroyWindow(window_handle);
Yep.
AFAICS waffle is unique wrt other projects (apitrace, epoxy, glut) as it
allows the PixelFormat to be called prior to the creation of either window
or
context.
If you could rewrite this problematic portion of Waffle's API, how would
you design it? I'm asking so that, if we do redesign Waffle's API one
day, it can better accommodate Windows and Mac.
One requirement of any API redesign, though, is to preserve the ability
to create a context and render into it without creating a throwaway
surface, as in EGL_KHR_surfaceless_context. (Through-away surfaces are
ok as long as they are internal to Waffle).
If I understand things correctly surface(egl)/drawable(glx) are not as clearly
separated in wgl. At least not initially.
Redesign of Waffle's API sounds like an overkill imho, as the only thing we
need is an easier way get from context/config data to window. Otherwise
wcore_(context|config|window) will be dummies and everything will be stored in
a wcore_display wrapper (wgl_display).
Perhaps the following rough flow illustrates things a bit better
glx (in the following example window is optional)
display glx create_context window gl*
wgl (here window is the root, i.e. think of (wgl)window == (glx)display)
window create_context wgl/gl
Currently I shove everything in wgl_display, although a slightly cleaner
approach might be better.
-Emil
Options:
- Create a window, choose format, destroy window.
No guarantee that the function will behave the same for another
window/device_context.
In practice, the odds of this happening are very low.
Just to be clear. This assumption will break when there are multiple GPUs on
the system (each CPU connected to a different display). Anyway, getting
OpenGL to work across multiple GPU (if you move the window from one display
to another bad things will probably happen.)
The reason that wglGetProcAddress requires window/context is because only
then will OPENGL32.DLL know which ICD DLL to load.
Emil, if you decide to create an invisible window internal to Waffle,
maybe the best time to do that is during waffle_display_connect() and
store it in the display. Just a thought, and maybe not a good one.
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
On Sat, May 31, 2014 at 12:02:10PM -0700, Jose Fonseca wrote:
- Original Message -
- Original Message -
On 24/05/14 20:28, Emil Velikov wrote:
Hi all,
Another round of interesting bits and bulbs.
Bit of an update:
The email came out a bit longer than expected, although it provides a
decent
list of possible solutions. Let me know which one you'll go with.
Four topics sorted by priority - high to low (based on my humble
opinion)
* ChoosePixelFormat - close yet quite different across platforms.
- glXChoosePixelFormat- depends on display (matches waffle's
model).
- CGLChoosePixelFormat- no dependencies.
- {wgl,}ChoosePixelFormat - depends on a device_context/existing
window.
To make things better, wgl functions depend on a current context as well.
The
recommended way of doing things under windows seems to be the following:
window_handle = CreateWindow(...)
device_context = GetDC(window_handle);
gl_rendering_context = wglCreateContext(device_context);
wglMakeCurrent (device_handle, gl_rendering_context);
// any of the following
wglGetProcAddress(...)
wglChoosePixelFormat(...)
wglMakeCurrent (device_handle, NULL);
wglDeleteContext (gl_rendering_context);
ReleaseDC(device_context);
DestroyWindow(window_handle);
Yep.
AFAICS waffle is unique wrt other projects (apitrace, epoxy, glut) as it
allows the PixelFormat to be called prior to the creation of either window
or
context.
If you could rewrite this problematic portion of Waffle's API, how would
you design it? I'm asking so that, if we do redesign Waffle's API one
day, it can better accommodate Windows and Mac.
One requirement of any API redesign, though, is to preserve the ability
to create a context and render into it without creating a throwaway
surface, as in EGL_KHR_surfaceless_context. (Through-away surfaces are
ok as long as they are internal to Waffle).
Options:
- Create a window, choose format, destroy window.
No guarantee that the function will behave the same for
another
window/device_context.
In practice, the odds of this happening are very low.
Just to be clear. This assumption will break when there are multiple GPUs on
the system (each CPU connected to a different display). Anyway, getting
OpenGL to work across multiple GPU (if you move the window from one display
to another bad things will probably happen.)
The reason that wglGetProcAddress requires window/context is because only
then will OPENGL32.DLL know which ICD DLL to load.
Emil, if you decide to create an invisible window internal to Waffle,
maybe the best time to do that is during waffle_display_connect() and
store it in the display. Just a thought, and maybe not a good one.
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
Sorry for the late reply. I missed you first email somehow.
- Original Message -
Hi all,
Another round of interesting bits and bulbs.
The email came out a bit longer than expected, although it provides a decent
list of possible solutions. Let me know which one you'll go with.
Four topics sorted by priority - high to low (based on my humble opinion)
* ChoosePixelFormat - close yet quite different across platforms.
- glXChoosePixelFormat- depends on display (matches waffle's model).
- CGLChoosePixelFormat- no dependencies.
- {wgl,}ChoosePixelFormat - depends on a device_context/existing window.
Options:
- Create a window, choose format, destroy window.
No guarantee that the function will behave the same for another
window/device_context.
- or, create window, choose format, reuse window on
waffle_window_create()
Sanest solution. If windows is not created just make one (i.e.
waffle_config_choose is not executed before waffle_window_create).
- or, store the attributes, and invoke ChoosePixelFormat as
waffle_window_create is executed.
What if code-flow depends on waffle_config_choose's return value ?
- or rework waffle API ... (no, please no)
Suggestion:
Cache the window, and reuse it on waffle_window_create.
* CreateContext, MakeCurrent - same story as ChoosePixelFormat :\
* Thread-safe and Co.
AFAICS it's used to provide thread independent waffle error info. Have I
missed something ?
- strerror_r is depreciated in favour of strerror_s. MS claims that the
former is not TS, while *nix man page disagrees.
- Current mingw-w64 build does not work on Win XP - missing strerror_s.
Fix landed in mingw-w64 trunk ~a few weeks ago.
- Back-port commit and build things with custom mingw_w64
- or, port the commit over to waffle ?
Suggestion:
Port over to waffle.
* 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
I personally use --static-libgcc and -static-libstdc++ to avoid DLL
dependencies on MINGW. But for example the MinGW binaries for Qt depend on
them. It's probably not a big issue either way. We could put an CMAKE option
to control this.
Options:
- Static link libgcc_s, generally not bad idea
- 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
- or, rebuild mingw-w64-gcc with --enable-threads=win32
- or, rework current code (open to suggestions)?
I'm pretty disapointed MinGW introduced this dependency. I actually reverted
my MinGW compilers to gcc-4.6 to avoid getting caught by this.
Either way, I wouldn't worry too much about this. Sooner or later somebody
will manage to get MSVC builds.
At very least we must provide MSVC import libaries, as MSVC linker can't link
to DLL directly.
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
Jose
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
- Original Message -
On 24/05/14 20:28, Emil Velikov wrote:
Hi all,
Another round of interesting bits and bulbs.
Bit of an update:
The email came out a bit longer than expected, although it provides a
decent
list of possible solutions. Let me know which one you'll go with.
Four topics sorted by priority - high to low (based on my humble opinion)
* ChoosePixelFormat - close yet quite different across platforms.
- glXChoosePixelFormat- depends on display (matches waffle's model).
- CGLChoosePixelFormat- no dependencies.
- {wgl,}ChoosePixelFormat - depends on a device_context/existing window.
To make things better, wgl functions depend on a current context as well. The
recommended way of doing things under windows seems to be the following:
window_handle = CreateWindow(...)
device_context = GetDC(window_handle);
gl_rendering_context = wglCreateContext(device_context);
wglMakeCurrent (device_handle, gl_rendering_context);
// any of the following
wglGetProcAddress(...)
wglChoosePixelFormat(...)
wglMakeCurrent (device_handle, NULL);
wglDeleteContext (gl_rendering_context);
ReleaseDC(device_context);
DestroyWindow(window_handle);
Yep.
AFAICS waffle is unique wrt other projects (apitrace, epoxy, glut) as it
allows the PixelFormat to be called prior to the creation of either window or
context.
Options:
- Create a window, choose format, destroy window.
No guarantee that the function will behave the same for another
window/device_context.
In practice, the odds of this happening are very low.
I'd recommend creating an invisible window, do your things then, keep the
window around, and then merely double check later that things are not busted.
You can see in
http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/wgl/stw_ext_pbuffer.c
how to create an invisible window (This is how Mesa implements pbuffers on
Windows!.)
Jose
- or, create window, choose format, reuse window on
waffle_window_create()
Sanest solution. If windows is not created just make one (i.e.
waffle_config_choose is not executed before
waffle_window_create).
- or, store the attributes, and invoke ChoosePixelFormat as
waffle_window_create is executed.
What if code-flow depends on waffle_config_choose's return value
?
- or rework waffle API ... (no, please no)
Suggestion:
Cache the window, and reuse it on waffle_window_create.
I'm planning to give the cache the windows a stab soon, although
I would greatly appreciate if anyone has an opinion/comment.
* CreateContext, MakeCurrent - same story as ChoosePixelFormat :\
* Thread-safe and Co.
AFAICS it's used to provide thread independent waffle error info. Have I
missed something ?
- strerror_r is depreciated in favour of strerror_s. MS claims that the
former is not TS, while *nix man page disagrees.
- Current mingw-w64 build does not work on Win XP - missing strerror_s.
Fix landed in mingw-w64 trunk ~a few weeks ago.
- Back-port commit and build things with custom mingw_w64
- or, port the commit over to waffle ?
Suggestion:
Port over to waffle.
The commit addressing strerror_s + mingw-w64 + WinXP has been backported to
the stable branch of mingw-w64. We can mandate that version (to be released)
as the minimum requirement in the readme/build-scripts.
* 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
- 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.
As spotted by Jordan, there should be no implications of static linking with
libgcc[1]. I've added a couple of lines to the build and so far it works like
a charm.
[1]
https://urldefense.proofpoint.com/v1/url?u=https://www.gnu.org/licenses/gcc-exception-3.1-faq.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=nPzAHYznyFhyA6Bn%2FXHt2AeHO%2FNhVm9VWwNYkwnEmIc%3D%0As=f1ea3aad8cc771542f8ab3be427e2335d4486e0516e7e738e83019b3457a475c
Library:
libwinpthread-1
pthread_key_create
pthread_mutex_lock
pthread_mutex_unlock
pthread_once
pthread_setspecific
Options:
- Static link
- or, rebuild mingw-w64-gcc with
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
On 31/05/14 19:59, Jose Fonseca wrote: - Original Message - On 24/05/14 20:28, Emil Velikov wrote: [snip] AFAICS waffle is unique wrt other projects (apitrace, epoxy, glut) as it allows the PixelFormat to be called prior to the creation of either window or context. Options: - Create a window, choose format, destroy window. No guarantee that the function will behave the same for another window/device_context. In practice, the odds of this happening are very low. I'd recommend creating an invisible window, do your things then, keep the window around, and then merely double check later that things are not busted. Still not sure which one of the two you are recommending: Create a invisible(dummy) window initially and create a new one at wfl_window_create. or Create a invisible(dummy) window initially and bring it up/use it at wfl_window_create/wfl_window_show. ? Pardon if the above question sound rather dull :) Thanks Emil You can see in http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/wgl/stw_ext_pbuffer.c how to create an invisible window (This is how Mesa implements pbuffers on Windows!.) Jose - or, create window, choose format, reuse window on waffle_window_create() Sanest solution. If windows is not created just make one (i.e. waffle_config_choose is not executed before waffle_window_create). - or, store the attributes, and invoke ChoosePixelFormat as waffle_window_create is executed. What if code-flow depends on waffle_config_choose's return value ? - or rework waffle API ... (no, please no) Suggestion: Cache the window, and reuse it on waffle_window_create. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
On 24/05/14 20:28, Emil Velikov wrote:
Hi all,
Another round of interesting bits and bulbs.
Bit of an update:
The email came out a bit longer than expected, although it provides a decent
list of possible solutions. Let me know which one you'll go with.
Four topics sorted by priority - high to low (based on my humble opinion)
* ChoosePixelFormat - close yet quite different across platforms.
- glXChoosePixelFormat- depends on display (matches waffle's model).
- CGLChoosePixelFormat- no dependencies.
- {wgl,}ChoosePixelFormat - depends on a device_context/existing window.
To make things better, wgl functions depend on a current context as well. The
recommended way of doing things under windows seems to be the following:
window_handle = CreateWindow(...)
device_context = GetDC(window_handle);
gl_rendering_context = wglCreateContext(device_context);
wglMakeCurrent (device_handle, gl_rendering_context);
// any of the following
wglGetProcAddress(...)
wglChoosePixelFormat(...)
wglMakeCurrent (device_handle, NULL);
wglDeleteContext (gl_rendering_context);
ReleaseDC(device_context);
DestroyWindow(window_handle);
AFAICS waffle is unique wrt other projects (apitrace, epoxy, glut) as it
allows the PixelFormat to be called prior to the creation of either window or
context.
Options:
- Create a window, choose format, destroy window.
No guarantee that the function will behave the same for another
window/device_context.
- or, create window, choose format, reuse window on waffle_window_create()
Sanest solution. If windows is not created just make one (i.e.
waffle_config_choose is not executed before waffle_window_create).
- or, store the attributes, and invoke ChoosePixelFormat as
waffle_window_create is executed.
What if code-flow depends on waffle_config_choose's return value ?
- or rework waffle API ... (no, please no)
Suggestion:
Cache the window, and reuse it on waffle_window_create.
I'm planning to give the cache the windows a stab soon, although
I would greatly appreciate if anyone has an opinion/comment.
* CreateContext, MakeCurrent - same story as ChoosePixelFormat :\
* Thread-safe and Co.
AFAICS it's used to provide thread independent waffle error info. Have I
missed something ?
- strerror_r is depreciated in favour of strerror_s. MS claims that the
former is not TS, while *nix man page disagrees.
- Current mingw-w64 build does not work on Win XP - missing strerror_s.
Fix landed in mingw-w64 trunk ~a few weeks ago.
- Back-port commit and build things with custom mingw_w64
- or, port the commit over to waffle ?
Suggestion:
Port over to waffle.
The commit addressing strerror_s + mingw-w64 + WinXP has been backported to
the stable branch of mingw-w64. We can mandate that version (to be released)
as the minimum requirement in the readme/build-scripts.
* 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
- 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.
As spotted by Jordan, there should be no implications of static linking with
libgcc[1]. I've added a couple of lines to the build and so far it works like
a charm.
[1] https://www.gnu.org/licenses/gcc-exception-3.1-faq.html
Library:
libwinpthread-1
pthread_key_create
pthread_mutex_lock
pthread_mutex_unlock
pthread_once
pthread_setspecific
Options:
- Static link
- or, rebuild mingw-w64-gcc with --enable-threads=win32
- or, rework current code (open to suggestions)?
Suggestion:
The above list states my order of preference.
My initial assumption was that the library is GPL 2 and/or 3 based.
Closer look revealed that it is X/MIT and 3-clause BSD licensed, and afaik
there should be no problems with distributing the binary (pending the no
advertisement stating it's license).
Meanwhile I did take a look at how greatly piglit depends on waffle. Nicely
separated codebase, falling back to glut whenever waffle is not available.
A couple more patches have emerged as well
* Autodetect the targets under linux, and
* Remove the restrict definition from waffle.h
which I would like to test a bit more and send it out for review.
Cheers
Emil
Any feedback would be great. Meanwhile I will send out a few misc/cleanup
patches :)
Cheers,
Emil
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
On 28/05/14 20:37, Emil Velikov wrote: window_handle = CreateWindow(...) device_context = GetDC(window_handle); gl_rendering_context = wglCreateContext(device_context); wglMakeCurrent (device_handle, gl_rendering_context); // any of the following wglGetProcAddress(...) wglChoosePixelFormat(...) Correction wglChoosePixelFormat does not require a context. Although wglGetProcAddress does. -Emil ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
On 25/05/14 21:35, Jordan Justen wrote: On Sat, May 24, 2014 at 12:28 PM, Emil Velikov emil.l.veli...@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 ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
On Sun, May 25, 2014 at 2:43 PM, Emil Velikov emil.l.veli...@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.veli...@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://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. 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 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. I'd guess that he likely has arch running somewhere. :) I'd still prefer a solution where this wasn't required. -Jordan ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
