From: Cody P. <cod...@gm...> - 2012-10-22 23:00:34
|
On Mon, Oct 22, 2012 at 4:50 PM, Paul T. Bauman <ptb...@gm...> wrote: > Sorry I haven't been able to be more helpful in reproducing the errors. Is > the pretty much settled at this point (i.e. ditching the non-release > version of fparser) or is there still some more stuff y'all would like me > to try? Don't know - libMesh may be off the hook! I have a patch ready to go that will support both the release and development versions of fparser and it seems to be working fine. I was able to configure and run libmesh 4.7 in debug mode and run the examples with my patch. MOOSE however is another story I'll have to continue to debug but I'm still running into some very bizarre errors that occur only in debug mode that simply don't make sense. I'll do a little more testing tomorrow and will probably commit this patch. For the record, the error I'm receiving (pointer being freed was not allocated) was one of the errors I saw repeatedly with the fparser stuff. Still investigating... Thanks, Cody > > Isn't the retina display bad ass? > > > On Fri, Oct 19, 2012 at 10:32 AM, Cody Permann <cod...@gm...>wrote: > >> >> >> On Thu, Oct 18, 2012 at 9:39 AM, Paul T. Bauman <ptb...@gm...>wrote: >> >>> On Thu, Oct 18, 2012 at 10:29 AM, Cody Permann <cod...@gm...>wrote: >>> >>>> >>>> Haven't really had much time to work on these issues this week but >>>> Jason did try the automake branch and it worked flawlessly with GCC 4.6. >>>> Interestingly on the same system in a different directory we were still >>>> able to reproduce the same issue when using HEAD. This gives me a little >>>> hope, I'm going to start looking at flags and other things to see what >>>> differences there might be between the two branches. >>>> >>> >>> OK, great. This was on my TODO list to look at this difference because >>> the hiccup I was seeing in ex6 was fixed with using the the automake branch >>> which means libtool is probably stripping out some incompatible flags or >>> something at link time. I'll try and look at this tomorrow and let y'all >>> know if I find anything. >>> >> >> Well I'm the proud new owner of a new MacBook Pro (Retina Display) which >> will be nice to play around with while I figure out these compiler issues. >> Yesterday, Jason installed GCC 4.6 on it from source and it still failed >> to build libMesh in debug mode. I also had very weird issues with Clang >> for the first time ever so that wasn't a very nice start. As usual the >> hard drive comes from Apple partitioned with a case-insensitive filesystem >> so I'm going to blow it away, repartition the drive and start from scratch >> again today. This time I'm going to do all of the work myself to make sure >> Jason isn't introducing some odd bug in the process somewhere but at this >> point I don't think he is doing anything wrong. I'm debating on trying Mac >> Ports first to see if I can get something to work since I still haven't had >> time to look at those flags yet. If you learn anything keep me posted. >> >> For fun Derek and I did some compile time comparisons with GCC4.6 (opt >> mode) versus Apples GCC4.2 compilers on his Macbook pro (last year's >> model). It turns out that Apple's compilers are quite a bit faster than >> GCC even against my new hardware. I don't think he'll win though when I >> get clang going again. It's too bad that Apple had to break 'em. >> >> Thanks, >> Cody >> >> >>> Best, >>> >>> Paul >>> >>> >> > |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-10-22 23:25:48
|
That error is eerily familiar to what I get on OSX when I use boost.unit in my app code. No resolution yet, but definitely let me know if you figure it out! On Oct 22, 2012, at 4:00 PM, "Cody Permann" <cod...@gm...<mailto:cod...@gm...>> wrote: On Mon, Oct 22, 2012 at 4:50 PM, Paul T. Bauman <ptb...@gm...<mailto:ptb...@gm...>> wrote: Sorry I haven't been able to be more helpful in reproducing the errors. Is the pretty much settled at this point (i.e. ditching the non-release version of fparser) or is there still some more stuff y'all would like me to try? Don't know - libMesh may be off the hook! I have a patch ready to go that will support both the release and development versions of fparser and it seems to be working fine. I was able to configure and run libmesh 4.7 in debug mode and run the examples with my patch. MOOSE however is another story I'll have to continue to debug but I'm still running into some very bizarre errors that occur only in debug mode that simply don't make sense. I'll do a little more testing tomorrow and will probably commit this patch. For the record, the error I'm receiving (pointer being freed was not allocated) was one of the errors I saw repeatedly with the fparser stuff. Still investigating... Thanks, Cody Isn't the retina display bad ass? On Fri, Oct 19, 2012 at 10:32 AM, Cody Permann <cod...@gm...<mailto:cod...@gm...>> wrote: On Thu, Oct 18, 2012 at 9:39 AM, Paul T. Bauman <ptb...@gm...<mailto:ptb...@gm...>> wrote: On Thu, Oct 18, 2012 at 10:29 AM, Cody Permann <cod...@gm...<mailto:cod...@gm...>> wrote: Haven't really had much time to work on these issues this week but Jason did try the automake branch and it worked flawlessly with GCC 4.6. Interestingly on the same system in a different directory we were still able to reproduce the same issue when using HEAD. This gives me a little hope, I'm going to start looking at flags and other things to see what differences there might be between the two branches. OK, great. This was on my TODO list to look at this difference because the hiccup I was seeing in ex6 was fixed with using the the automake branch which means libtool is probably stripping out some incompatible flags or something at link time. I'll try and look at this tomorrow and let y'all know if I find anything. Well I'm the proud new owner of a new MacBook Pro (Retina Display) which will be nice to play around with while I figure out these compiler issues. Yesterday, Jason installed GCC 4.6 on it from source and it still failed to build libMesh in debug mode. I also had very weird issues with Clang for the first time ever so that wasn't a very nice start. As usual the hard drive comes from Apple partitioned with a case-insensitive filesystem so I'm going to blow it away, repartition the drive and start from scratch again today. This time I'm going to do all of the work myself to make sure Jason isn't introducing some odd bug in the process somewhere but at this point I don't think he is doing anything wrong. I'm debating on trying Mac Ports first to see if I can get something to work since I still haven't had time to look at those flags yet. If you learn anything keep me posted. For fun Derek and I did some compile time comparisons with GCC4.6 (opt mode) versus Apples GCC4.2 compilers on his Macbook pro (last year's model). It turns out that Apple's compilers are quite a bit faster than GCC even against my new hardware. I don't think he'll win though when I get clang going again. It's too bad that Apple had to break 'em. Thanks, Cody Best, Paul ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Libmesh-devel mailing list Lib...@li...<mailto:Lib...@li...> https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Cody P. <cod...@gm...> - 2012-10-25 17:39:46
|
Working with Macs is not without it's challenges. I now have my workstation and laptop (both ML) both working with full stacks built against GCC and Clang without any special compiler options or other libMesh flag hacks ;) However, Apple, not wanting us to get bored has created another minor hurdle for us. It appears that Clang no longer links with the current version of the Apple Command Line tools package! It turns out that this issue is not a clang problem directly, but rather a linker (ld) problem which is failing with a seg fault. Some bizarre combination of flags is causing the issue but the link lines are different enough between the way GCC and Clang invoke the linker that I really don't feel like diving in right now. There is a workaround though, the slightly older (August 7th, 2012) version of the command line tools which works just fine without any further changes. Good luck! Cody On Mon, Oct 22, 2012 at 5:25 PM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > That error is eerily familiar to what I get on OSX when I use boost.unit > in my app code. No resolution yet, but definitely let me know if you figure > it out! > > > > On Oct 22, 2012, at 4:00 PM, "Cody Permann" <cod...@gm...> wrote: > > > > On Mon, Oct 22, 2012 at 4:50 PM, Paul T. Bauman <ptb...@gm...>wrote: > >> Sorry I haven't been able to be more helpful in reproducing the errors. >> Is the pretty much settled at this point (i.e. ditching the non-release >> version of fparser) or is there still some more stuff y'all would like me >> to try? > > > Don't know - libMesh may be off the hook! I have a patch ready to go that > will support both the release and development versions of fparser and it > seems to be working fine. I was able to configure and run libmesh 4.7 in > debug mode and run the examples with my patch. > > MOOSE however is another story I'll have to continue to debug but I'm > still running into some very bizarre errors that occur only in debug mode > that simply don't make sense. I'll do a little more testing tomorrow and > will probably commit this patch. For the record, the error I'm receiving > (pointer being freed was not allocated) was one of the errors I saw > repeatedly with the fparser stuff. Still investigating... > > Thanks, > Cody > > >> >> Isn't the retina display bad ass? >> >> >> On Fri, Oct 19, 2012 at 10:32 AM, Cody Permann <cod...@gm...>wrote: >> >>> >>> >>> On Thu, Oct 18, 2012 at 9:39 AM, Paul T. Bauman <ptb...@gm...>wrote: >>> >>>> On Thu, Oct 18, 2012 at 10:29 AM, Cody Permann <cod...@gm...>wrote: >>>> >>>>> >>>>> Haven't really had much time to work on these issues this week but >>>>> Jason did try the automake branch and it worked flawlessly with GCC 4.6. >>>>> Interestingly on the same system in a different directory we were still >>>>> able to reproduce the same issue when using HEAD. This gives me a little >>>>> hope, I'm going to start looking at flags and other things to see what >>>>> differences there might be between the two branches. >>>>> >>>> >>>> OK, great. This was on my TODO list to look at this difference because >>>> the hiccup I was seeing in ex6 was fixed with using the the automake branch >>>> which means libtool is probably stripping out some incompatible flags or >>>> something at link time. I'll try and look at this tomorrow and let y'all >>>> know if I find anything. >>>> >>> >>> Well I'm the proud new owner of a new MacBook Pro (Retina Display) which >>> will be nice to play around with while I figure out these compiler issues. >>> Yesterday, Jason installed GCC 4.6 on it from source and it still failed >>> to build libMesh in debug mode. I also had very weird issues with Clang >>> for the first time ever so that wasn't a very nice start. As usual the >>> hard drive comes from Apple partitioned with a case-insensitive filesystem >>> so I'm going to blow it away, repartition the drive and start from scratch >>> again today. This time I'm going to do all of the work myself to make sure >>> Jason isn't introducing some odd bug in the process somewhere but at this >>> point I don't think he is doing anything wrong. I'm debating on trying Mac >>> Ports first to see if I can get something to work since I still haven't had >>> time to look at those flags yet. If you learn anything keep me posted. >>> >>> For fun Derek and I did some compile time comparisons with GCC4.6 (opt >>> mode) versus Apples GCC4.2 compilers on his Macbook pro (last year's >>> model). It turns out that Apple's compilers are quite a bit faster than >>> GCC even against my new hardware. I don't think he'll win though when I >>> get clang going again. It's too bad that Apple had to break 'em. >>> >>> Thanks, >>> Cody >>> >>> >>>> Best, >>>> >>>> Paul >>>> >>>> >>> >> > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > > |
From: Cody P. <cod...@gm...> - 2012-10-23 16:12:20
|
Alright, Paul's suggestion was indeed spot on. DGLIBCXX_DEBUG was indeed causing my issues and appears to have been causing at least some of my issues with the developer version of fparser as well. I've known for a very long time that those flags simply didn't work with the Apple compilers, but I was surprised to learn that they don't appear to work at all on OS X even with the GNU GCC compilers. I'll work with Paul and one of us will make the appropriate changes to just strip those flags out universally on all OS X compilers inside of libMesh. As far as the changeset that I've put together to switch between the release and development versions of fparser goes, I still think that this is a good direction and would like to commit that changeset unless anyone has any objections. Cody On Mon, Oct 22, 2012 at 5:25 PM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > That error is eerily familiar to what I get on OSX when I use boost.unit > in my app code. No resolution yet, but definitely let me know if you figure > it out! > > > > On Oct 22, 2012, at 4:00 PM, "Cody Permann" <cod...@gm...> wrote: > > > > On Mon, Oct 22, 2012 at 4:50 PM, Paul T. Bauman <ptb...@gm...>wrote: > >> Sorry I haven't been able to be more helpful in reproducing the errors. >> Is the pretty much settled at this point (i.e. ditching the non-release >> version of fparser) or is there still some more stuff y'all would like me >> to try? > > > Don't know - libMesh may be off the hook! I have a patch ready to go that > will support both the release and development versions of fparser and it > seems to be working fine. I was able to configure and run libmesh 4.7 in > debug mode and run the examples with my patch. > > MOOSE however is another story I'll have to continue to debug but I'm > still running into some very bizarre errors that occur only in debug mode > that simply don't make sense. I'll do a little more testing tomorrow and > will probably commit this patch. For the record, the error I'm receiving > (pointer being freed was not allocated) was one of the errors I saw > repeatedly with the fparser stuff. Still investigating... > > Thanks, > Cody > > >> >> Isn't the retina display bad ass? >> >> >> On Fri, Oct 19, 2012 at 10:32 AM, Cody Permann <cod...@gm...>wrote: >> >>> >>> >>> On Thu, Oct 18, 2012 at 9:39 AM, Paul T. Bauman <ptb...@gm...>wrote: >>> >>>> On Thu, Oct 18, 2012 at 10:29 AM, Cody Permann <cod...@gm...>wrote: >>>> >>>>> >>>>> Haven't really had much time to work on these issues this week but >>>>> Jason did try the automake branch and it worked flawlessly with GCC 4.6. >>>>> Interestingly on the same system in a different directory we were still >>>>> able to reproduce the same issue when using HEAD. This gives me a little >>>>> hope, I'm going to start looking at flags and other things to see what >>>>> differences there might be between the two branches. >>>>> >>>> >>>> OK, great. This was on my TODO list to look at this difference because >>>> the hiccup I was seeing in ex6 was fixed with using the the automake branch >>>> which means libtool is probably stripping out some incompatible flags or >>>> something at link time. I'll try and look at this tomorrow and let y'all >>>> know if I find anything. >>>> >>> >>> Well I'm the proud new owner of a new MacBook Pro (Retina Display) which >>> will be nice to play around with while I figure out these compiler issues. >>> Yesterday, Jason installed GCC 4.6 on it from source and it still failed >>> to build libMesh in debug mode. I also had very weird issues with Clang >>> for the first time ever so that wasn't a very nice start. As usual the >>> hard drive comes from Apple partitioned with a case-insensitive filesystem >>> so I'm going to blow it away, repartition the drive and start from scratch >>> again today. This time I'm going to do all of the work myself to make sure >>> Jason isn't introducing some odd bug in the process somewhere but at this >>> point I don't think he is doing anything wrong. I'm debating on trying Mac >>> Ports first to see if I can get something to work since I still haven't had >>> time to look at those flags yet. If you learn anything keep me posted. >>> >>> For fun Derek and I did some compile time comparisons with GCC4.6 (opt >>> mode) versus Apples GCC4.2 compilers on his Macbook pro (last year's >>> model). It turns out that Apple's compilers are quite a bit faster than >>> GCC even against my new hardware. I don't think he'll win though when I >>> get clang going again. It's too bad that Apple had to break 'em. >>> >>> Thanks, >>> Cody >>> >>> >>>> Best, >>>> >>>> Paul >>>> >>>> >>> >> > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > > |
From: Cody P. <cod...@gm...> - 2012-10-23 17:16:03
|
On Tue, Oct 23, 2012 at 11:08 AM, Roy Stogner <roy...@ic...>wrote: > > On Tue, 23 Oct 2012, Cody Permann wrote: > > So I just sent the patch to John and he wasn't very crazy about the >> whole direction as he reviewed my patch. I made the arbitrary >> decision to turn off the optimizer for the release version and the >> optimizer for the development version instead of having a more >> complicated grid of options giving us 4 configuration possibilities. >> I figured that most of us really don't care if the optimizer is on >> or not. We can't turn it on anyway on OS X and function evaluation >> never shows up in our timings. The patch works but he and Derek are >> really leaning towards just going to the release version only... >> What are your thoughts? Do you want the patch? Unfortunately it's >> large again because I had to include one more *.inc file for the >> release version that we don't need for the development version. >> > > I'd definitely prefer have the release-or-development-version option > for GPL compatibility. > Wait is this the issue? Are you sure that the release version is not GPL compatible? > > I don't care about the optimizer, though. If someone else eventually > does then they can add a configure option for it. > Ok - this seems like a reasonable compromise. I think we should get weigh-in from the other devs. Cody --- > Roy |
From: Derek G. <fri...@gm...> - 2012-10-23 17:23:30
|
Ummm - the license in the released version is the BSD3-Clause license. It is an open source license (in fact it's one of the most permissive licenses) and it is both GPL and LGPL compatible. I don't think there is a problem with using that code... Derek On Tue, Oct 23, 2012 at 11:15 AM, Cody Permann <cod...@gm...>wrote: > > > On Tue, Oct 23, 2012 at 11:08 AM, Roy Stogner <roy...@ic...>wrote: > >> >> On Tue, 23 Oct 2012, Cody Permann wrote: >> >> So I just sent the patch to John and he wasn't very crazy about the >>> whole direction as he reviewed my patch. I made the arbitrary >>> decision to turn off the optimizer for the release version and the >>> optimizer for the development version instead of having a more >>> complicated grid of options giving us 4 configuration possibilities. >>> I figured that most of us really don't care if the optimizer is on >>> or not. We can't turn it on anyway on OS X and function evaluation >>> never shows up in our timings. The patch works but he and Derek are >>> really leaning towards just going to the release version only... >>> What are your thoughts? Do you want the patch? Unfortunately it's >>> large again because I had to include one more *.inc file for the >>> release version that we don't need for the development version. >>> >> >> I'd definitely prefer have the release-or-development-version option >> for GPL compatibility. >> > > Wait is this the issue? Are you sure that the release version is not GPL > compatible? > > >> >> I don't care about the optimizer, though. If someone else eventually >> does then they can add a configure option for it. >> > > Ok - this seems like a reasonable compromise. > > I think we should get weigh-in from the other devs. > Cody > > --- >> Roy > > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > > |
From: Roy S. <roy...@ic...> - 2012-10-23 17:39:58
|
On Tue, 23 Oct 2012, Derek Gaston wrote: > Ummm - the license in the released version is the BSD3-Clause > license. It is an open source license (in fact it's one of the most > permissive licenses) and it is both GPL and LGPL compatible. I > don't think there is a problem with using that code... We can release libmesh.so without any source code under the most permissive license imaginable, but the license choice wouldn't make it GPL compatible. Similarly, tens of thousands of lines like "#define gX2 +mflit1_1*" does not qualify as "the preferred form of the work for making modifications to it". --- Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-10-23 18:01:28
|
>> Ummm - the license in the released version is the BSD3-Clause >> license. It is an open source license (in fact it's one of the most >> permissive licenses) and it is both GPL and LGPL compatible. I >> don't think there is a problem with using that code... > > We can release libmesh.so without any source code under the most > permissive license imaginable, but the license choice wouldn't make it > GPL compatible. > > Similarly, tens of thousands of lines like > > "#define gX2 +mflit1_1*" > > does not qualify as "the preferred form of the work for making > modifications to it". Given the work that's gone into packaging the development version, I'm all for leaving it in there but not building it unless explicitly asked… I like the idea of distributing both but by default building the "released" version… -Ben |
From: Roy S. <roy...@ic...> - 2012-10-23 18:11:22
|
On Tue, 23 Oct 2012, Kirk, Benjamin (JSC-EG311) wrote: > Given the work that's gone into packaging the development version, > I'm all for leaving it in there but not building it unless > explicitly asked… I like the idea of distributing both but by > default building the "released" version… Cody, it looks like your patch defaults to building the development version? I'm happy whichever way is the default, just as long as it's not too much of a hassle for GPL sticklers to build purely from source or for people with compiler issues to skip the problematic bits. --- Roy |
From: Derek G. <fri...@gm...> - 2012-10-23 18:34:09
|
On Tue, Oct 23, 2012 at 11:39 AM, Roy Stogner <roy...@ic...>wrote: > We can release libmesh.so without any source code under the most > permissive license imaginable, but the license choice wouldn't make it > GPL compatible. > > Similarly, tens of thousands of lines like > > "#define gX2 +mflit1_1*" > > does not qualify as "the preferred form of the work for making > modifications to it". > _We_ don't have to distribute "the preferred form" if we don't make modifications to it (which we're not). It's enough just to say that we're using fparser and that the source is available... which it is: from Sourceforge. There is absolutely nothing wrong with distributing binary versions of GPL/LGPL software as long as the source is available _somewhere_. We are only responsible for distributing modified forms of the source with any binary / non-preferred forms. I personally don't plan on editing those yak generated files... But Cody's patch can do both... so if there's not a problem with his patch... then let's just use that. Derek |
From: Roy S. <roy...@ic...> - 2012-10-23 19:00:55
|
On Tue, 23 Oct 2012, Derek Gaston wrote: > _We_ don't have to distribute "the preferred form" if we don't make > modifications to it (which we're not). It's enough just to say that > we're using fparser and that the source is available... which it is: > from Sourceforge. Correct, and you emphasized the correct word: _We_. Our LGPL doesn't care what BSD-based binary blobs get tacked on. But if users wanted to link a GPL code with libMesh and redistribute, they would either have to get the development fparser themselves or violate that other code's license. We wouldn't be committing any violations ourselves, but we'd be making it harder for our users to avoid doing so. > There is absolutely nothing wrong with distributing binary versions > of GPL/LGPL software as long as the source is available _somewhere_. This is a popular enough misconception to have made the FAQ. http://www.gnu.org/licenses/gpl-faq.html#UnchangedJustBinary > But Cody's patch can do both... so if there's not a problem with his patch... then let's just use that. Agreed; I certainly didn't see any problems with it. --- Roy |
From: Cody P. <cod...@gm...> - 2012-10-23 19:09:12
|
---------- Forwarded message ---------- From: Roy Stogner <roy...@ic...> Date: Tue, Oct 23, 2012 at 1:00 PM Subject: Re: [Libmesh-devel] Compiler Fiasco Upate To: Derek Gaston <fri...@gm...> Cc: Cody Permann <cod...@gm...>, lib...@li... On Tue, 23 Oct 2012, Derek Gaston wrote: _We_ don't have to distribute "the preferred form" if we don't make > modifications to it (which we're not). It's enough just to say that > we're using fparser and that the source is available... which it is: > from Sourceforge. > Correct, and you emphasized the correct word: _We_. Our LGPL doesn't care what BSD-based binary blobs get tacked on. But if users wanted to link a GPL code with libMesh and redistribute, they would either have to get the development fparser themselves or violate that other code's license. We wouldn't be committing any violations ourselves, but we'd be making it harder for our users to avoid doing so. There is absolutely nothing wrong with distributing binary versions > of GPL/LGPL software as long as the source is available _somewhere_. > This is a popular enough misconception to have made the FAQ. http://www.gnu.org/licenses/**gpl-faq.html#**UnchangedJustBinary<http://www.gnu.org/licenses/gpl-faq.html#UnchangedJustBinary> But Cody's patch can do both... so if there's not a problem with his > patch... then let's just use that. > Agreed; I certainly didn't see any problems with it. Alright - I'll commit if the server ever comes back online. Cody --- Roy |
From: Derek G. <fri...@gm...> - 2012-10-23 22:25:36
|
On Tue, Oct 23, 2012 at 1:00 PM, Roy Stogner <roy...@ic...>wrote: > There is absolutely nothing wrong with distributing binary versions >> of GPL/LGPL software as long as the source is available _somewhere_. >> > > This is a popular enough misconception to have made the FAQ. > http://www.gnu.org/licenses/**gpl-faq.html#**UnchangedJustBinary<http://www.gnu.org/licenses/gpl-faq.html#UnchangedJustBinary> This isn't our situation. In our situation the source is being distributed for those "binaries".... just not by us. Not only that but this link is about binaries of _GPL_ applications / libraries. That doesn't apply to BSD licensed libraries. I don't see how linking in a BSD licensed binary blob can ever be a GPL violation and it wouldn't be a BSD license violation as long as somewhere they say that they were using libMesh (which retains the BSD acknowledgement). Derek |
From: Roy S. <roy...@ic...> - 2012-10-23 23:21:30
|
On Tue, 23 Oct 2012, Derek Gaston wrote: > On Tue, Oct 23, 2012 at 1:00 PM, Roy Stogner <roy...@ic...> wrote: > There is absolutely nothing wrong with distributing binary versions > of GPL/LGPL software as long as the source is available _somewhere_. > > This is a popular enough misconception to have made the FAQ. > http://www.gnu.org/licenses/gpl-faq.html#UnchangedJustBinary > > This isn't our situation. "The general rule is, if you distribute binaries, you must distribute the complete corresponding source code too." does cover the situation of anyone who wants to distribute GPL software modified to link against libMesh. This would be more difficult if libMesh did not include the complete corresponding source code of libMesh. > In our situation the source is being distributed for those > "binaries".... just not by us. Someone else supplying the source code could qualify under 6(d) of the GPL, assuming that "Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements." I'd like people to be allowed to distribute GPL'ed libMesh applications without them having to ensure that warp.povusers.org page is online or prepare their own fparser source copy first. We've already had to wean ourselves off GMV and fork code from a pre-LGPL-incompatible GetPot version; from now on I think it's just safest to assume that any third party code availability is subject to change without notice. > Not only that but this link is about binaries of _GPL_ applications > / libraries. That doesn't apply to BSD licensed libraries. As I said before, I'm speaking about the hypothetical case of a user wanting to link libMesh with a different, GPL'ed code. > I don't see how linking in a BSD licensed binary blob can ever be a > GPL violation The whole reason the GPL was created was to protect people's source code from being redistributed in derived works linked with binary blobs, regardless of the binary's license. That's basically the whole difference between GPL and LGPL too - the latter lets you redistribute derived works that combine source-code-available and binary-only objects, the former doesn't. If you've got the support of the original authors of all the GPL'ed components, of course, you can add whatever exceptions you wish. But the only exception the GPL itself adds is for "system libraries". http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs --- Roy |
From: Derek G. <fri...@gm...> - 2012-10-23 23:43:38
|
On Tue, Oct 23, 2012 at 5:21 PM, Roy Stogner <roy...@ic...>wrote: > > The whole reason the GPL was created was to protect people's source > code from being redistributed in derived works linked with binary > blobs, regardless of the binary's license. That's basically the whole > difference between GPL and LGPL too - the latter lets you redistribute > derived works that combine source-code-available and binary-only > objects, the former doesn't. > > If you've got the support of the original authors of all the GPL'ed > components, of course, you can add whatever exceptions you wish. But > the only exception the GPL itself adds is for "system libraries". > > http://www.gnu.org/licenses/**gpl-faq.html#**GPLIncompatibleLibs<http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs> No - you have that backwards. The GPL says nothing about distributing BSD binary blobs with your GPL'd application/library. That would be covered by the BSD license the binary blob is under. The GPL _does_ cover distributing binary blobs _of_ GPL'd applications / libraries and or linking to them. To be clear... you _can_ distribute a GPL'd application that comes with binary blobs in other licenses (provided that you satisfy those other license clauses when you do so). The GPL would only cover _your_ code that is GPL'd... and has nothing to do with what you're doing with someone else's code. Now - if you compile a binary blob that includes both GPL'd and non-GPL'd software... what you do with that blob _must_ conform to the GPL (it should also conform to the other licenses as well... but they're usually less restrictive than the GPL) which generally means that you need to make the source code available for the GPL'd portions AND for any non-GPL'd portions that interface with GPL'd code (ie call GPL'd functions, use GPL'd symbols, etc). If a GPL'd code is using a BSD library like fparser... then there are no problems with distributing a binary of fparser (provided you satisfy the BSD license with the copyright notice publication somewhere) linked into your GPL'd code. fparser would not be calling GPL'd functions, nor would it be using GPL'd symbols in any way. To put it plainly the fparser object file contains no GPL'd software and therefore the distribution of that part of the binary would NOT need to follow the GPL.... you would simply need to satisfy the BSD license for fparser. You are absolutely right that the GPL protects against linking in GPL libraries and distributing a binary. But that's not what's happening with fparser. You are linking in a BSD library and only need to follow the rules for doing so.... even in the case that your software is GPL'd. Derek |
From: Cody P. <cod...@gm...> - 2012-10-23 23:46:14
|
I vote that we stop the license war. I plan to satisfy all requirements with my fparser patch tomorrow. :-) cheers Sent from my iPhone On Oct 23, 2012, at 5:43 PM, Derek Gaston <fri...@gm...> wrote: On Tue, Oct 23, 2012 at 5:21 PM, Roy Stogner <roy...@ic...>wrote: > > The whole reason the GPL was created was to protect people's source > code from being redistributed in derived works linked with binary > blobs, regardless of the binary's license. That's basically the whole > difference between GPL and LGPL too - the latter lets you redistribute > derived works that combine source-code-available and binary-only > objects, the former doesn't. > > If you've got the support of the original authors of all the GPL'ed > components, of course, you can add whatever exceptions you wish. But > the only exception the GPL itself adds is for "system libraries". > > http://www.gnu.org/licenses/**gpl-faq.html#**GPLIncompatibleLibs<http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs> No - you have that backwards. The GPL says nothing about distributing BSD binary blobs with your GPL'd application/library. That would be covered by the BSD license the binary blob is under. The GPL _does_ cover distributing binary blobs _of_ GPL'd applications / libraries and or linking to them. To be clear... you _can_ distribute a GPL'd application that comes with binary blobs in other licenses (provided that you satisfy those other license clauses when you do so). The GPL would only cover _your_ code that is GPL'd... and has nothing to do with what you're doing with someone else's code. Now - if you compile a binary blob that includes both GPL'd and non-GPL'd software... what you do with that blob _must_ conform to the GPL (it should also conform to the other licenses as well... but they're usually less restrictive than the GPL) which generally means that you need to make the source code available for the GPL'd portions AND for any non-GPL'd portions that interface with GPL'd code (ie call GPL'd functions, use GPL'd symbols, etc). If a GPL'd code is using a BSD library like fparser... then there are no problems with distributing a binary of fparser (provided you satisfy the BSD license with the copyright notice publication somewhere) linked into your GPL'd code. fparser would not be calling GPL'd functions, nor would it be using GPL'd symbols in any way. To put it plainly the fparser object file contains no GPL'd software and therefore the distribution of that part of the binary would NOT need to follow the GPL.... you would simply need to satisfy the BSD license for fparser. You are absolutely right that the GPL protects against linking in GPL libraries and distributing a binary. But that's not what's happening with fparser. You are linking in a BSD library and only need to follow the rules for doing so.... even in the case that your software is GPL'd. Derek ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Libmesh-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Roy S. <roy...@ic...> - 2012-10-24 01:43:49
|
On Tue, 23 Oct 2012, Cody Permann wrote: > I vote that we stop the license war. Okay; this will be my last post. It's hardly a "war", but there's nothing else I was going to say that isn't covered by that FAQ; anyone confused can just go read the whole thing. I thought that last entry was pretty clear, though. Maybe something shorter would have been more persuasive? https://www.gnu.org/licenses/gpl-faq.html#MoneyGuzzlerInc --- Roy |
From: Derek G. <fri...@gm...> - 2012-10-24 02:58:01
|
Hmmmm... Yes. You are right. Too many damned situations to keep track of. GPL applications can link to non-free libraries... BUT only in the case of "system" libraries. So... if fparser were distributed with operating systems as a binary blob then a GPL application can use it. However, a binary blob of fparser cannot be distributed with a GPL application without the source to that binary blob. What a mess. That brings me to another topic... we have other binary blobs in libMesh... like tecio.a... Don't we have the same problems there? At any rate the GPL is madness. This kind of crap really turns me off of the whole "free software" movement... Derek Sent from my iPhone On Oct 23, 2012, at 7:43 PM, Roy Stogner <roy...@ic...> wrote: > > On Tue, 23 Oct 2012, Cody Permann wrote: > >> I vote that we stop the license war. > > Okay; this will be my last post. It's hardly a "war", but there's > nothing else I was going to say that isn't covered by that FAQ; anyone > confused can just go read the whole thing. > > I thought that last entry was pretty clear, though. Maybe something > shorter would have been more persuasive? > > https://www.gnu.org/licenses/gpl-faq.html#MoneyGuzzlerInc > --- > Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-10-24 03:34:37
|
On Oct 23, 2012, at 7:57 PM, Derek Gaston <fri...@gm...> wrote: > What a mess. > > That brings me to another topic... we have other binary blobs in > libMesh... like tecio.a... Don't we have the same problems there? > > At any rate the GPL is madness. This kind of crap really turns me off > of the whole "free software" movement... all I want is free beer - you can keep your free speech! ;-) There are certainly components we distribute which are not strictly open source. Even now that I have source for tecio in the libmesh automake branch, the license of it is unclear. Simply says "copyright Tecplot" To make it super-clear, we could support an --enable-gpl-compliant or something which only uses blessed contributed packages. TecIO is by no means a necessity - we can write Tecplot ASCII format ourselves, it is just a matter of convenience. But whenever it is possible to include what we need to compliantly build everything, I applaud efforts to do so. It could be important for compliant application codes, but also if we were to get packaged by a strict OS as well. I plan to look at building a macports port file and rpm .spec file, which would make it that much easier to get libMesh packaged by someone, and I could easily see a desire to have it be built only from 'pure sources' -Ben |
From: Paul T. B. <ptb...@gm...> - 2012-10-24 03:20:35
|
On Tue, Oct 23, 2012 at 5:08 PM, Paul T. Bauman <ptb...@gm...> wrote: > Attached patch work for you guys? Haven't been able to fully test - seems > latest XCode update broke something and I'm having to rebuild one of the > libraries. configure seems to work correctly for me in dbg mode. > Actually, check that. That patch was not the right way to do this. Will post an updated version soon. Instead of just checking if we're on Darwin, we still need to distinguish between Apple compilers and non Apple compilers on Darwin. |
From: Roy S. <roy...@ic...> - 2012-10-24 04:12:26
|
On Tue, 23 Oct 2012, Derek Gaston wrote: > That brings me to another topic... we have other binary blobs in > libMesh... like tecio.a... We've got like a hundred different tecio.a versions in there, but I thought that was the only blob. > Don't we have the same problems there? Yeah, we do. tecplot had to be stripped out for the libMesh package that's in Debian & Ubuntu, to meet the Debian Free Software Guidelines. Hmm... I just became aware of one of my subconscious motivations for wanting fparser source distributed: I've been thinking about helping the Debian people update their libMesh dpkg sometime after the autotools merge (their version is more than a year old now), and I wanted one fewer worry licensing-wise about getting new features into the Debian repos. With Tecplot we don't even have the option of making source code available, pure-GPL app developers would have to distribute a tecplot-disabled binary regardless, and so our only choice is "Tecplot for non-GPL apps" vs "no Tecplot for anyone". If we were going to be that purist we might as well switch from the LGPL to the GPL ourselves. Plus, with Tecplot I just don't care. :-) I stopped using it myself a while ago, Exodus->Paraview is a great substitute, and our viz MeshOutput is abstracted enough that it's easy to switch options anyway. But I could see myself becoming very dependent on fparser, so if there had been any chance that one day we might have to disassemble those .inc files in order to fix some newly-triggered bug or compatibility issue, I'd have ripped it out and put a less read-only parser package in it's place already. There's some other non-free-software in contrib/... nothing as blatant as a binary blob, but one of these days we probably ought to create a contrib-free directory and a --enable-lgpl-only configure option so that nobody trying to build commercial apps on top of libMesh sabotages themselves. libHilbert is GPL; Laspack's, Triangle's and Tetgen's licenses are free for non-commercial use only; and for ParMETIS, Ben got special permission to redistribute but not permission to give others permission to redistribute... Huh. I just noticed that we now have both GPL and GPL-incompatible licenses in contrib/. We should still be fine redistributing it all together in source form, but doing ./configure without either "--disable-libHilbert" or "--disable-laspack --disable-triangle --disable-tecplot --disable-tetgen --disable-metis --disable-parmetis" will eventually give you personal-use-only binaries. As if fixing our libHilbert issues wasn't already a high enough priority... --- Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-10-24 12:21:04
|
> If we were going to be > that purist we might as well switch from the LGPL to the GPL > ourselves. To be clear, I have never wanted to do that, and I don't think it is the right path - I hope R. Stogner, Esquire is simply offering that as what strict compliance would mean for us. I certainly applaud what the GPL tries to accomplish, but I also feel it is orthogonal to what libMesh is trying to accomplish. If someone wants to use our code to build a closed source app I don't really have a problem with that, in fact I would be willing to sell them a support contract. ;-) My main thought with the LGPL originally was that the GPL may be too heavy handed for paranoid academic types... Now what I think is Roy's point though - if someone *does* want to create a GPL app that uses libMesh I'm all for that too, and agree we should facilitate that to the extent possible. -Ben |
From: Roy S. <roy...@ic...> - 2012-10-24 12:38:29
|
On Wed, 24 Oct 2012, Kirk, Benjamin (JSC-EG311) wrote: >> If we were going to be >> that purist we might as well switch from the LGPL to the GPL >> ourselves. > > To be clear, I have never wanted to do that, and I don't think it is > the right path - I hope R. Stogner, Esquire is simply offering that > as what strict compliance would mean for us. Yikes! I completely agree, sorry if I accidentally insinuated otherwise. I don't share Derek's newfound anger at the GPL. If people want to get paid for their software that's fine, and if their preferred form of pay is "you can't link with it without open sourcing some of your stuff" rather than "you can't run it without giving me some of your money" that's fine too. But I don't want either policy for libMesh. > I certainly applaud what the GPL tries to accomplish, but I also > feel it is orthogonal to what libMesh is trying to accomplish. If > someone wants to use our code to build a closed source app I don't > really have a problem with that, in fact I would be willing to sell > them a support contract. ;-) Agreed. Time to replace or marginalize libHilbert, then. What was the advantage of that over the sfcurves code? > My main thought with the LGPL originally was that the GPL may be too > heavy handed for paranoid academic types... Then we got lucky. We've had too many contributors of major chunks of code at this point; if we ever did want to change the license to something non-LGPL-upgradeable, it'd probably be easier to start rewrite from scratch than to hunt down everybody who sent in large-enough-to-copyright patches under the understanding that they were going to be LGPLed. --- Roy |
From: Cody P. <cod...@gm...> - 2012-10-24 14:10:34
|
I'll check it out and let you know. On Wed, Oct 24, 2012 at 7:37 AM, Paul T. Bauman <ptb...@gm...> wrote: > On Tue, Oct 23, 2012 at 10:20 PM, Paul T. Bauman <ptb...@gm...>wrote: > >> Actually, check that. That patch was not the right way to do this. Will >> post an updated version soon. Instead of just checking if we're on Darwin, >> we still need to distinguish between Apple compilers and non Apple >> compilers on Darwin. >> > > (If everyone is done playing out their lawyer fantasy...) Better patch > attached that works for me. Cody, this work for you guys? > > |
From: Cody P. <cod...@gm...> - 2012-10-24 14:40:15
|
Looks good - please commit Cody On Wed, Oct 24, 2012 at 8:10 AM, Cody Permann <cod...@gm...> wrote: > I'll check it out and let you know. > > > On Wed, Oct 24, 2012 at 7:37 AM, Paul T. Bauman <ptb...@gm...>wrote: > >> On Tue, Oct 23, 2012 at 10:20 PM, Paul T. Bauman <ptb...@gm...>wrote: >> >>> Actually, check that. That patch was not the right way to do this. Will >>> post an updated version soon. Instead of just checking if we're on Darwin, >>> we still need to distinguish between Apple compilers and non Apple >>> compilers on Darwin. >>> >> >> (If everyone is done playing out their lawyer fantasy...) Better patch >> attached that works for me. Cody, this work for you guys? >> >> > |