[OE-core] [PATCH 1/5] bdwgc: new recipe for autogen

Flanagan, Elizabeth elizabeth.flanagan at intel.com
Tue Jan 17 22:59:57 UTC 2012


On Tue, Jan 17, 2012 at 2:52 PM, Richard Purdie <rpurdie at rpsys.net> wrote:
> On Tue, 2012-01-17 at 14:20 -0800, Flanagan, Elizabeth wrote:
>> On Tue, Jan 17, 2012 at 1:43 PM, Saul Wold <sgw at linux.intel.com> wrote:
>> > On 01/17/2012 12:30 PM, nitin.a.kamble at intel.com wrote:
>> >>
>> >> From: Nitin A Kamble<nitin.a.kamble at intel.com>
>> >>
>> >> This recipe is needed by guile.
>> >> And guile is needed for autogen.
>> >>
>> >> Signed-off-by: Nitin A Kamble<nitin.a.kamble at intel.com>
>> >> ---
>> >>  meta/recipes-support/bdwgc/bdwgc_20110107.bb |   38
>> >> ++++++++++++++++++++++++++
>> >>  1 files changed, 38 insertions(+), 0 deletions(-)
>> >>  create mode 100644 meta/recipes-support/bdwgc/bdwgc_20110107.bb
>> >>
>> >> diff --git a/meta/recipes-support/bdwgc/bdwgc_20110107.bb
>> >> b/meta/recipes-support/bdwgc/bdwgc_20110107.bb
>> >> new file mode 100644
>> >> index 0000000..1aaa5b8
>> >> --- /dev/null
>> >> +++ b/meta/recipes-support/bdwgc/bdwgc_20110107.bb
>> >> @@ -0,0 +1,38 @@
>> >> +SUMMARY = "A garbage collector for C and C++"
>> >> +
>> >> +DESCRIPTION = "The Boehm-Demers-Weiser conservative garbage collector can
>> >> be\
>> >> + used as a garbage collecting replacement for C malloc or C++ new. It
>> >> allows\
>> >> + you to allocate memory basically as you normally would, without
>> >> explicitly\
>> >> + deallocating memory that is no longer useful. The collector
>> >> automatically\
>> >> + recycles memory when it determines that it can no longer be otherwise\
>> >> + accessed.\
>> >> +  The collector is also used by a number of programming language\
>> >> + implementations that either use C as intermediate code, want to
>> >> facilitate\
>> >> + easier interoperation with C libraries, or just prefer the simple
>> >> collector\
>> >> + interface.\
>> >> +  Alternatively, the garbage collector may be used as a leak detector for
>> >> C\
>> >> + or C++ programs, though that is not its primary goal.\
>> >> +  Empirically, this collector works with most unmodified C programs,
>> >> simply\
>> >> + by replacing malloc with GC_malloc calls, replacing realloc with
>> >> GC_realloc\
>> >> + calls, and removing free calls."
>> >> +
>> >> +HOMEPAGE = "http://www.hpl.hp.com/personal/Hans_Boehm/gc/"
>> >> +SECTION = "devel"
>> >> +LICENSE = "custom"
>> >
>> > What's custom?  Is this the correct LICENSE name to use here?
>> > Beth comments?
>>
>> custom is certainly not correct. This one isn't a particularly easy one.
>>
>> openSuSE says BSD-3-Clause. This isn't actually true from what I'm
>> seeing. It looks to me more like:
>>
>> LICENSE = "MIT & FSF-Unlimited & GPL-2.0"
>>
>> linux_threads.c and Makefile.am appear to be MIT.
>>
>> "Several files supporting GNU-style builds are copyrighted by the Free
>> Software Foundation, and carry a different license from that given
>> below." I would assume that that is FSF-Unlimited.
>>
>> The main portion of the license is MIT.
>>
>> It does mention that there are some GPL code in here:
>>
>> "A few of the files needed to use the GNU-style build procedure come with
>> slightly different licenses, though they are all similar in spirit.  A few
>> are GPL'ed, but with an exception that should cover all uses in the
>> collector.  (If you are concerned about such things, I recommend you look
>> at the notice in config.guess or ltmain.sh.)"
>>
>> ltmain.sh is GPL-2.0. Is it distributed in the package? If so, then I
>> would add it to LICENSE.
>
> ltmain.sh is from libtool and is a build time tool used by *many* of our
> recipes. I don't think that one needs to be mentioned in LICENSE, or if
> it does, we have much bigger problems than this recipe.
>
> Cheers,
>
> Richard

Good point. We do still have GPL-2.0 if we're packaging up code built
from libatomic_ops/src/atomic_ops_stack.c.

-b

>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core



-- 
Elizabeth Flanagan
Yocto Project
Build and Release




More information about the Openembedded-core mailing list