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.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 _______________________________________________ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle