| Submitter | Nitin A Kamble |
|---|---|
| Date | Jan. 17, 2012, 8:30 p.m. |
| Message ID | <b042b10b86d6e28290a64e42e1e23de81621630b.1326831402.git.nitin.a.kamble@intel.com> |
| Download | mbox | patch |
| Permalink | /patch/19611/ |
| State | New |
| Headers | show |
Comments
On 01/17/2012 12:30 PM, nitin.a.kamble@intel.com wrote: > From: Nitin A Kamble<nitin.a.kamble@intel.com> > > This recipe is needed by guile. > And guile is needed for autogen. > > Signed-off-by: Nitin A Kamble<nitin.a.kamble@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? Sau! > +LIC_FILES_CHKSUM = "file://README.QUICK;md5=9b9dd874f6940641b6ab19893ee8f1cc" > + > +SRC_URI = "http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/bdwgc-7_2alpha5-20110107.tar.bz2" > + > +SRC_URI[md5sum] = "4f3c130fc71ff23584edaa19a37739ee" > +SRC_URI[sha256sum] = "1f57b959ae1144e1e5fa59d52d7cb4ed626fd74cf47da1c9c119b8b46ae2722d" > + > +PR = "r0" > + > +S = "${WORKDIR}/bdwgc" > + > +do_install_append (){ > + rm -f ${D}${datadir}/${PN} > +} > + > +inherit autotools > +BBCLASSEXTEND = "native nativesdk"
On Tue, Jan 17, 2012 at 1:43 PM, Saul Wold <sgw@linux.intel.com> wrote: > On 01/17/2012 12:30 PM, nitin.a.kamble@intel.com wrote: >> >> From: Nitin A Kamble<nitin.a.kamble@intel.com> >> >> This recipe is needed by guile. >> And guile is needed for autogen. >> >> Signed-off-by: Nitin A Kamble<nitin.a.kamble@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. Doing above should cover all bases. -b > > Sau! > > >> +LIC_FILES_CHKSUM = >> "file://README.QUICK;md5=9b9dd874f6940641b6ab19893ee8f1cc" >> + >> +SRC_URI = >> "http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/bdwgc-7_2alpha5-20110107.tar.bz2" >> + >> +SRC_URI[md5sum] = "4f3c130fc71ff23584edaa19a37739ee" >> +SRC_URI[sha256sum] = >> "1f57b959ae1144e1e5fa59d52d7cb4ed626fd74cf47da1c9c119b8b46ae2722d" >> + >> +PR = "r0" >> + >> +S = "${WORKDIR}/bdwgc" >> + >> +do_install_append (){ >> + rm -f ${D}${datadir}/${PN} >> +} >> + >> +inherit autotools >> +BBCLASSEXTEND = "native nativesdk" > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> -----Original Message----- > From: openembedded-core-bounces@lists.openembedded.org > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of > Flanagan, Elizabeth > Sent: Tuesday, January 17, 2012 2:21 PM > To: Patches and discussions about the oe-core layer > Subject: Re: [OE-core] [PATCH 1/5] bdwgc: new recipe for autogen > > On Tue, Jan 17, 2012 at 1:43 PM, Saul Wold <sgw@linux.intel.com> wrote: > > On 01/17/2012 12:30 PM, nitin.a.kamble@intel.com wrote: > >> > >> From: Nitin A Kamble<nitin.a.kamble@intel.com> > >> > >> This recipe is needed by guile. > >> And guile is needed for autogen. > >> > >> Signed-off-by: Nitin A Kamble<nitin.a.kamble@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. Beth, As seen in the sources: http://bdwgc.cvs.sourceforge.net/viewvc/bdwgc/bdwgc/ The ltmain.sh is part of the source. So as per your recommendation I am setting LICENSE = "MIT & FSF-Unlimited & GPL-2.0" Thanks, Nitin > > Doing above should cover all bases. > > -b > > > > > Sau! > > > > > >> +LIC_FILES_CHKSUM = > >> "file://README.QUICK;md5=9b9dd874f6940641b6ab19893ee8f1cc" > >> + > >> +SRC_URI = > >> "http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/bdwgc- > 7_2alpha5-20110107.tar.bz2" > >> + > >> +SRC_URI[md5sum] = "4f3c130fc71ff23584edaa19a37739ee" > >> +SRC_URI[sha256sum] = > >> "1f57b959ae1144e1e5fa59d52d7cb4ed626fd74cf47da1c9c119b8b46ae2722d" > >> + > >> +PR = "r0" > >> + > >> +S = "${WORKDIR}/bdwgc" > >> + > >> +do_install_append (){ > >> + rm -f ${D}${datadir}/${PN} > >> +} > >> + > >> +inherit autotools > >> +BBCLASSEXTEND = "native nativesdk" > > > > > > _______________________________________________ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > > > -- > Elizabeth Flanagan > Yocto Project > Build and Release > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On Tue, 2012-01-17 at 14:20 -0800, Flanagan, Elizabeth wrote: > On Tue, Jan 17, 2012 at 1:43 PM, Saul Wold <sgw@linux.intel.com> wrote: > > On 01/17/2012 12:30 PM, nitin.a.kamble@intel.com wrote: > >> > >> From: Nitin A Kamble<nitin.a.kamble@intel.com> > >> > >> This recipe is needed by guile. > >> And guile is needed for autogen. > >> > >> Signed-off-by: Nitin A Kamble<nitin.a.kamble@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
On Tue, Jan 17, 2012 at 2:52 PM, Richard Purdie <rpurdie@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@linux.intel.com> wrote: >> > On 01/17/2012 12:30 PM, nitin.a.kamble@intel.com wrote: >> >> >> >> From: Nitin A Kamble<nitin.a.kamble@intel.com> >> >> >> >> This recipe is needed by guile. >> >> And guile is needed for autogen. >> >> >> >> Signed-off-by: Nitin A Kamble<nitin.a.kamble@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@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On Tue, Jan 17, 2012 at 12:30 PM, <nitin.a.kamble@intel.com> wrote: > This recipe is needed by guile. > And guile is needed for autogen. is this really needed by guile. if yes what part of guide need it ?
Khem, Here was the configure error: | configure: error: Package requirements (bdw-gc) were not met: | | No package 'bdw-gc' found | | Consider adjusting the PKG_CONFIG_PATH environment variable if you | installed software in a non-standard prefix. | | Alternatively, you may set the environment variables BDW_GC_CFLAGS | and BDW_GC_LIBS to avoid the need to call pkg-config. | See the pkg-config man page for more details. | ERROR: oe_runconf failed Nitin > -----Original Message----- > From: openembedded-core-bounces@lists.openembedded.org > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of > Khem Raj > Sent: Tuesday, January 17, 2012 3:23 PM > To: Patches and discussions about the oe-core layer > Subject: Re: [OE-core] [PATCH 1/5] bdwgc: new recipe for autogen > > On Tue, Jan 17, 2012 at 12:30 PM, <nitin.a.kamble@intel.com> wrote: > > This recipe is needed by guile. > > And guile is needed for autogen. > > is this really needed by guile. if yes what part of guide need it ? > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> -----Original Message----- > From: openembedded-core-bounces@lists.openembedded.org > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of > Kamble, Nitin A > Sent: Tuesday, January 17, 2012 5:29 PM > To: Patches and discussions about the oe-core layer > Subject: Re: [OE-core] [PATCH 1/5] bdwgc: new recipe for autogen > > Khem, > Here was the configure error: > | configure: error: Package requirements (bdw-gc) were not met: > | > | No package 'bdw-gc' found > | > | Consider adjusting the PKG_CONFIG_PATH environment variable if you > | installed software in a non-standard prefix. > | > | Alternatively, you may set the environment variables BDW_GC_CFLAGS > | and BDW_GC_LIBS to avoid the need to call pkg-config. > | See the pkg-config man page for more details. > | ERROR: oe_runconf failed > > Nitin > And it is being used in this c file: libguile/threads.c Thanks, Nitin > > > -----Original Message----- > > From: openembedded-core-bounces@lists.openembedded.org > > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf > Of > > Khem Raj > > Sent: Tuesday, January 17, 2012 3:23 PM > > To: Patches and discussions about the oe-core layer > > Subject: Re: [OE-core] [PATCH 1/5] bdwgc: new recipe for autogen > > > > On Tue, Jan 17, 2012 at 12:30 PM, <nitin.a.kamble@intel.com> wrote: > > > This recipe is needed by guile. > > > And guile is needed for autogen. > > > > is this really needed by guile. if yes what part of guide need it ? > > > > _______________________________________________ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On Tue, Jan 17, 2012 at 5:33 PM, Kamble, Nitin A <nitin.a.kamble@intel.com> wrote: > > >> -----Original Message----- >> From: openembedded-core-bounces@lists.openembedded.org >> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of >> Kamble, Nitin A >> Sent: Tuesday, January 17, 2012 5:29 PM >> To: Patches and discussions about the oe-core layer >> Subject: Re: [OE-core] [PATCH 1/5] bdwgc: new recipe for autogen >> >> Khem, >> Here was the configure error: >> | configure: error: Package requirements (bdw-gc) were not met: >> | >> | No package 'bdw-gc' found >> | >> | Consider adjusting the PKG_CONFIG_PATH environment variable if you >> | installed software in a non-standard prefix. >> | >> | Alternatively, you may set the environment variables BDW_GC_CFLAGS >> | and BDW_GC_LIBS to avoid the need to call pkg-config. >> | See the pkg-config man page for more details. >> | ERROR: oe_runconf failed yeah I see guile-2 needs a garbage collector. Did you try the original libgc ? http://anonscm.debian.org/gitweb/?p=collab-maint/libgc.git;a=summary >> >> Nitin >> > And it is being used in this c file: libguile/threads.c > > Thanks, > Nitin > >> >> > -----Original Message----- >> > From: openembedded-core-bounces@lists.openembedded.org >> > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf >> Of >> > Khem Raj >> > Sent: Tuesday, January 17, 2012 3:23 PM >> > To: Patches and discussions about the oe-core layer >> > Subject: Re: [OE-core] [PATCH 1/5] bdwgc: new recipe for autogen >> > >> > On Tue, Jan 17, 2012 at 12:30 PM, <nitin.a.kamble@intel.com> wrote: >> > > This recipe is needed by guile. >> > > And guile is needed for autogen. >> > >> > is this really needed by guile. if yes what part of guide need it ? >> > >> > _______________________________________________ >> > Openembedded-core mailing list >> > Openembedded-core@lists.openembedded.org >> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core >> >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> -----Original Message----- > From: openembedded-core-bounces@lists.openembedded.org > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of > Khem Raj > Sent: Tuesday, January 17, 2012 9:46 PM > To: Patches and discussions about the oe-core layer > Subject: Re: [OE-core] [PATCH 1/5] bdwgc: new recipe for autogen > > On Tue, Jan 17, 2012 at 5:33 PM, Kamble, Nitin A > <nitin.a.kamble@intel.com> wrote: > > > > > >> -----Original Message----- > >> From: openembedded-core-bounces@lists.openembedded.org > >> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf > Of > >> Kamble, Nitin A > >> Sent: Tuesday, January 17, 2012 5:29 PM > >> To: Patches and discussions about the oe-core layer > >> Subject: Re: [OE-core] [PATCH 1/5] bdwgc: new recipe for autogen > >> > >> Khem, > >> Here was the configure error: > >> | configure: error: Package requirements (bdw-gc) were not met: > >> | > >> | No package 'bdw-gc' found > >> | > >> | Consider adjusting the PKG_CONFIG_PATH environment variable if you > >> | installed software in a non-standard prefix. > >> | > >> | Alternatively, you may set the environment variables BDW_GC_CFLAGS > >> | and BDW_GC_LIBS to avoid the need to call pkg-config. > >> | See the pkg-config man page for more details. > >> | ERROR: oe_runconf failed > > yeah I see guile-2 needs a garbage collector. Did you try the original > libgc ? > http://anonscm.debian.org/gitweb/?p=collab-maint/libgc.git;a=summary > Khem, As the bdwgc was working as expected, I did not try to find any alternative there. Nitin > > >> > >> Nitin > >> > > And it is being used in this c file: libguile/threads.c > > > > Thanks, > > Nitin > > > >> > >> > -----Original Message----- > >> > From: openembedded-core-bounces@lists.openembedded.org > >> > [mailto:openembedded-core-bounces@lists.openembedded.org] On > Behalf > >> Of > >> > Khem Raj > >> > Sent: Tuesday, January 17, 2012 3:23 PM > >> > To: Patches and discussions about the oe-core layer > >> > Subject: Re: [OE-core] [PATCH 1/5] bdwgc: new recipe for autogen > >> > > >> > On Tue, Jan 17, 2012 at 12:30 PM, <nitin.a.kamble@intel.com> > wrote: > >> > > This recipe is needed by guile. > >> > > And guile is needed for autogen. > >> > > >> > is this really needed by guile. if yes what part of guide need it > ? > >> > > >> > _______________________________________________ > >> > Openembedded-core mailing list > >> > Openembedded-core@lists.openembedded.org > >> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded- > core > >> > >> _______________________________________________ > >> Openembedded-core mailing list > >> Openembedded-core@lists.openembedded.org > >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded- > core > > > > _______________________________________________ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Patch
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" +LIC_FILES_CHKSUM = "file://README.QUICK;md5=9b9dd874f6940641b6ab19893ee8f1cc" + +SRC_URI = "http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/bdwgc-7_2alpha5-20110107.tar.bz2" + +SRC_URI[md5sum] = "4f3c130fc71ff23584edaa19a37739ee" +SRC_URI[sha256sum] = "1f57b959ae1144e1e5fa59d52d7cb4ed626fd74cf47da1c9c119b8b46ae2722d" + +PR = "r0" + +S = "${WORKDIR}/bdwgc" + +do_install_append (){ + rm -f ${D}${datadir}/${PN} +} + +inherit autotools +BBCLASSEXTEND = "native nativesdk"