[PATCH 0/2] upgrade libc-package.bbclass; add libgcc

[PATCH 0/2] upgrade libc-package.bbclass; add libgcc

[Dexuan Cui]

I tested on qemux86 and qemumips: bitbake poky-image-sdk and
meta-toolchain-sdk can build fine.

The patches are straightforward and should not incur regression.
Anyway, please review them carefully in case I made mistakes. :-)

thanks,
-- Dexuan

Pull URL: git://git.pokylinux.org/poky-contrib.git
  Branch: dcui/master
  Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/master

Thanks,
    Dexuan Cui <dexuan.cui@intel.com>
---


Dexuan Cui (2):
  libgcc: use the new recipe (rather than gcc-runtime) to install
    libgcc_s.so* and crt*.o
  libc-package.bbclass: should not rm scsi/*.h

 meta/classes/libc-package.bbclass                  |    3 -
 meta/conf/distro/include/poky-default.inc          |    1 +
 .../recipes-devtools/gcc/gcc-configure-runtime.inc |   16 +-------
 meta/recipes-devtools/gcc/gcc-package-runtime.inc  |    8 ----
 meta/recipes-devtools/gcc/gcc-runtime_4.3.3.bb     |    2 +-
 meta/recipes-devtools/gcc/gcc-runtime_4.5.1.bb     |    2 +-
 meta/recipes-devtools/gcc/libgcc_4.5.1.bb          |   43 ++++++++++++++++++++
 7 files changed, 47 insertions(+), 28 deletions(-)
 create mode 100644 meta/recipes-devtools/gcc/libgcc_4.5.1.bb

-- 
1.7.2

[PATCH 1/2] libgcc: use the new recipe (rather than gcc-runtime) to install libgcc_s.so* and crt*.o

[Dexuan Cui]

Currently gcc-runtime installs the files, but actually gcc-runtime's
do_configure checks if the files are available, so before we build gcc-runtime,
we should have some recipe install the files first! -- currently
gcc-cross-intermediate actually does that(gcc-cross also installs the files,
but it installs into the gcc-build-internal* directory), but
gcc-cross-intermediate will have its own sysroot in future, after that,
gcc-runtime won't build. So let us add this new target recipe and move the
installation of the files from gcc-runtime into it.

Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
---
 meta/conf/distro/include/poky-default.inc          |    1 +
 .../recipes-devtools/gcc/gcc-configure-runtime.inc |   16 +-------
 meta/recipes-devtools/gcc/gcc-package-runtime.inc  |    8 ----
 meta/recipes-devtools/gcc/gcc-runtime_4.3.3.bb     |    2 +-
 meta/recipes-devtools/gcc/gcc-runtime_4.5.1.bb     |    2 +-
 meta/recipes-devtools/gcc/libgcc_4.5.1.bb          |   43 ++++++++++++++++++++
 6 files changed, 47 insertions(+), 25 deletions(-)
 create mode 100644 meta/recipes-devtools/gcc/libgcc_4.5.1.bb

diff --git a/meta/conf/distro/include/poky-default.inc b/meta/conf/distro/include/poky-default.inc
index e5dd647..b693102 100644
--- a/meta/conf/distro/include/poky-default.inc
+++ b/meta/conf/distro/include/poky-default.inc
@@ -11,6 +11,7 @@ PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc-intermediate = "gcc-cross-interme
 PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc = "gcc-cross"
 PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}g++ = "gcc-cross"
 PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}compilerlibs = "gcc-runtime"
+PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}libgcc = "libgcc"
 PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}libc-initial = "${POKYLIBC}-initial"
 PREFERRED_PROVIDER_virtual/${SDK_PREFIX}libc-for-gcc-nativesdk ?= "${POKYLIBC}-nativesdk"
 
diff --git a/meta/recipes-devtools/gcc/gcc-configure-runtime.inc b/meta/recipes-devtools/gcc/gcc-configure-runtime.inc
index f9ad61d..6cc11e2 100644
--- a/meta/recipes-devtools/gcc/gcc-configure-runtime.inc
+++ b/meta/recipes-devtools/gcc/gcc-configure-runtime.inc
@@ -31,28 +31,14 @@ do_compile () {
 }
 
 do_install () {
-	target=`echo ${MULTIMACH_TARGET_SYS} | sed -e s#-nativesdk##`
-
-	# Install libgcc from our gcc-cross saved data
-	install -d ${D}${base_libdir} ${D}${libdir}
-	cp -fpPR ${STAGING_INCDIR_NATIVE}/gcc-build-internal-$target/* ${D}
-
 	for d in ${RUNTIMETARGET}; do
 		cd ${B}/$d/
 		oe_runmake 'DESTDIR=${D}' install
 	done
-
-	# Move libgcc_s into /lib
-	mkdir -p ${D}${base_libdir}
-	if [ -f ${D}${libdir}/nof/libgcc_s.so ]; then
-		mv ${D}${libdir}/nof/libgcc* ${D}${base_libdir}
-	else
-		mv ${D}${libdir}/libgcc* ${D}${base_libdir} || true
-	fi
 }
 
 INHIBIT_DEFAULT_DEPS = "1"
-DEPENDS = "virtual/${TARGET_PREFIX}gcc virtual/${TARGET_PREFIX}g++"
+DEPENDS = "virtual/${TARGET_PREFIX}gcc virtual/${TARGET_PREFIX}g++ libgcc"
 PROVIDES = "virtual/${TARGET_PREFIX}compilerlibs"
 
 BBCLASSEXTEND = "nativesdk"
diff --git a/meta/recipes-devtools/gcc/gcc-package-runtime.inc b/meta/recipes-devtools/gcc/gcc-package-runtime.inc
index 40a9ed0..e8c9011 100644
--- a/meta/recipes-devtools/gcc/gcc-package-runtime.inc
+++ b/meta/recipes-devtools/gcc/gcc-package-runtime.inc
@@ -1,6 +1,4 @@
 PACKAGES = "\
-  libgcc \
-  libgcc-dev \
   libstdc++ \
   libstdc++-precompile-dev \
   libstdc++-dev \
@@ -14,12 +12,6 @@ PACKAGES = "\
   libmudflap-dev \
 "
 
-FILES_libgcc = "${base_libdir}/libgcc*.so.*"
-FILES_libgcc-dev = " \
-  ${base_libdir}/libgcc*.so \
-  ${libdir}/${TARGET_SYS}/${BINV}/crt* \
-  ${libdir}/${TARGET_SYS}/${BINV}/libgcc*"
-
 FILES_libg2c = "${target_libdir}/libg2c.so.*"
 FILES_libg2c-dev = "\
   ${libdir}/libg2c.so \
diff --git a/meta/recipes-devtools/gcc/gcc-runtime_4.3.3.bb b/meta/recipes-devtools/gcc/gcc-runtime_4.3.3.bb
index 6b375f3..99f927a 100644
--- a/meta/recipes-devtools/gcc/gcc-runtime_4.3.3.bb
+++ b/meta/recipes-devtools/gcc/gcc-runtime_4.3.3.bb
@@ -1,4 +1,4 @@
-PR = "r17"
+PR = "r18"
 
 require gcc-${PV}.inc
 require gcc-configure-runtime.inc
diff --git a/meta/recipes-devtools/gcc/gcc-runtime_4.5.1.bb b/meta/recipes-devtools/gcc/gcc-runtime_4.5.1.bb
index ca22e8b..093f9bf 100644
--- a/meta/recipes-devtools/gcc/gcc-runtime_4.5.1.bb
+++ b/meta/recipes-devtools/gcc/gcc-runtime_4.5.1.bb
@@ -1,4 +1,4 @@
-PR = "r1"
+PR = "r2"
 
 require gcc-${PV}.inc
 require gcc-configure-runtime.inc
diff --git a/meta/recipes-devtools/gcc/libgcc_4.5.1.bb b/meta/recipes-devtools/gcc/libgcc_4.5.1.bb
new file mode 100644
index 0000000..37a4d38
--- /dev/null
+++ b/meta/recipes-devtools/gcc/libgcc_4.5.1.bb
@@ -0,0 +1,43 @@
+require gcc-${PV}.inc
+
+PR = "r0"
+
+INHIBIT_DEFAULT_DEPS = "1"
+DEPENDS = "virtual/${TARGET_PREFIX}gcc virtual/${TARGET_PREFIX}g++"
+PROVIDES = "virtual/${TARGET_PREFIX}libgcc"
+
+PACKAGES = "\
+  libgcc \
+  libgcc-dev \
+  "
+
+FILES_libgcc = "${base_libdir}/libgcc*.so.*"
+FILES_libgcc-dev = " \
+  ${base_libdir}/libgcc*.so \
+  ${libdir}/${TARGET_SYS}/${BINV}/crt* \
+  ${libdir}/${TARGET_SYS}/${BINV}/libgcc*"
+
+do_fetch[noexec] = "1"
+do_unpack[noexec] = "1"
+do_patch[noexec] = "1"
+do_configure[noexec] = "1"
+do_compile[noexec] = "1"
+
+do_install () {
+	target=`echo ${MULTIMACH_TARGET_SYS} | sed -e s#-nativesdk##`
+
+	# Install libgcc from our gcc-cross saved data
+	install -d ${D}${base_libdir} ${D}${libdir}
+	cp -fpPR ${STAGING_INCDIR_NATIVE}/gcc-build-internal-$target/* ${D}
+
+	# Move libgcc_s into /lib
+	mkdir -p ${D}${base_libdir}
+	if [ -f ${D}${libdir}/nof/libgcc_s.so ]; then
+		mv ${D}${libdir}/nof/libgcc* ${D}${base_libdir}
+	else
+		mv ${D}${libdir}/libgcc* ${D}${base_libdir} || true
+	fi
+}
+
+BBCLASSEXTEND = "nativesdk"
+
-- 
1.7.2

[PATCH 2/2] libc-package.bbclass: should not rm scsi/*.h

[Dexuan Cui]

{e}glibc should install the scsi/*.h files, which are needed by hal.
Currently hal can build because eglibc-initial (which has its own do_install)
installs the files. In future eglibc will have its own sysroot, so hal
won't build.

BTW: in OE side, eglibc's do_install also doesn't remove the files.

Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
---
 meta/classes/libc-package.bbclass |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/meta/classes/libc-package.bbclass b/meta/classes/libc-package.bbclass
index 4709b33..733f26b 100644
--- a/meta/classes/libc-package.bbclass
+++ b/meta/classes/libc-package.bbclass
@@ -95,9 +95,6 @@ do_install() {
 		mv ${WORKDIR}/SUPPORTED.tmp ${WORKDIR}/SUPPORTED
 	done
 	rm -f ${D}{sysconfdir}/rpc
-	rm -f ${D}${includedir}/scsi/sg.h
-	rm -f ${D}${includedir}/scsi/scsi_ioctl.h
-	rm -f ${D}${includedir}/scsi/scsi.h
 	rm -rf ${D}${datadir}/zoneinfo
 	rm -rf ${D}${libexecdir}/getconf
 }
-- 
1.7.2

Re: [PATCH 1/2] libgcc: use the new recipe (rather than gcc-runtime) to install libgcc_s.so* and crt*.o

[Koen Kooi]

Op 15 jan 2011, om 12:23 heeft Dexuan Cui het volgende geschreven:

> Currently gcc-runtime installs the files, but actually gcc-runtime's
> do_configure checks if the files are available, so before we build gcc-runtime,
> we should have some recipe install the files first! -- currently
> gcc-cross-intermediate actually does that(gcc-cross also installs the files,
> but it installs into the gcc-build-internal* directory), but
> gcc-cross-intermediate will have its own sysroot in future, after that,
> gcc-runtime won't build. So let us add this new target recipe and move the
> installation of the files from gcc-runtime into it.

I understand the problem, but...

> diff --git a/meta/recipes-devtools/gcc/libgcc_4.5.1.bb b/meta/recipes-devtools/gcc/libgcc_4.5.1.bb
> 
> +do_install () {
> +	target=`echo ${MULTIMACH_TARGET_SYS} | sed -e s#-nativesdk##`
> +
> +	# Install libgcc from our gcc-cross saved data
> +	install -d ${D}${base_libdir} ${D}${libdir}
> +	cp -fpPR ${STAGING_INCDIR_NATIVE}/gcc-build-internal-$target/* ${D}

... why can't gcc-cross create the libgcc(-dev) packages? You're using the exact files gcc-cross installs, so why have an extra recipe? It feels backwards to have one package grab files from another package from sysroots and package those.

regards,

Koen

Re: [PATCH 2/2] libc-package.bbclass: should not rm scsi/*.h

[Koen Kooi]

Op 15 jan 2011, om 12:23 heeft Dexuan Cui het volgende geschreven:

> {e}glibc should install the scsi/*.h files, which are needed by hal.
> Currently hal can build because eglibc-initial (which has its own do_install)
> installs the files. In future eglibc will have its own sysroot, so hal
> won't build.
> 
> BTW: in OE side, eglibc's do_install also doesn't remove the files.

As some background info: There's a conflict between linux-libc-headers-dev and libc-dev when installing on the target. In OE we do this instead:

koen@dominion:/OE/org.openembedded.dev$ grep scsi recipes/linux-libc-headers/ -rn
recipes/linux-libc-headers/linux-libc-headers_2.6.32.bb:23:     rm -f ${D}${exec_prefix}/include/scsi/scsi.h
recipes/linux-libc-headers/linux-libc-headers_2.6.31.bb:23:     rm -f ${D}${exec_prefix}/include/scsi/scsi.h
recipes/linux-libc-headers/linux-libc-headers_2.6.34.bb:42:     rm -f ${D}${exec_prefix}/include/scsi/scsi.h

regards,

Koen

Re: [PATCH 2/2] libc-package.bbclass: should not rm scsi/*.h

[Cui, Dexuan]

Koen Kooi wrote:
> Op 15 jan 2011, om 12:23 heeft Dexuan Cui het volgende geschreven:
> 
>> {e}glibc should install the scsi/*.h files, which are needed by hal.
>> Currently hal can build because eglibc-initial (which has its own
>> do_install) installs the files. In future eglibc will have its own
>> sysroot, so hal 
>> won't build.
>> 
>> BTW: in OE side, eglibc's do_install also doesn't remove the files.
> 
> As some background info: There's a conflict between
> linux-libc-headers-dev and libc-dev when installing on the target. In
> OE we do this instead:  
> 
> koen@dominion:/OE/org.openembedded.dev$ grep scsi
> recipes/linux-libc-headers/ -rn 
> recipes/linux-libc-headers/linux-libc-headers_2.6.32.bb:23:     rm -f
> ${D}${exec_prefix}/include/scsi/scsi.h
> recipes/linux-libc-headers/linux-libc-headers_2.6.31.bb:23:     rm -f
> ${D}${exec_prefix}/include/scsi/scsi.h
> recipes/linux-libc-headers/linux-libc-headers_2.6.34.bb:42:     rm -f
> ${D}${exec_prefix}/include/scsi/scsi.h   
My understanding is:
Linux kernel should not export these files: in OE side see 91d3d92a acked by you. :-)
So {e}glibc should supply the files -- previously poky did supply, but 7379ee77 removed the files -- I think this is incorrect.

BTW: in poky, we can see linux-libc-headers_2.6.36.bb also correctly removes the file.

thanks
-- Dexuan

Re: [PATCH 1/2] libgcc: use the new recipe (rather than gcc-runtime) to install libgcc_s.so* and crt*.o

[Cui, Dexuan]

Koen Kooi wrote:
> Op 15 jan 2011, om 12:23 heeft Dexuan Cui het volgende geschreven:
> 
>> Currently gcc-runtime installs the files, but actually gcc-runtime's
>> do_configure checks if the files are available, so before we build
>> gcc-runtime, 
>> we should have some recipe install the files first! -- currently
>> gcc-cross-intermediate actually does that(gcc-cross also installs
>> the files, 
>> but it installs into the gcc-build-internal* directory), but
>> gcc-cross-intermediate will have its own sysroot in future, after
>> that, 
>> gcc-runtime won't build. So let us add this new target recipe and
>> move the 
>> installation of the files from gcc-runtime into it.
> 
> I understand the problem, but...
> 
>> diff --git a/meta/recipes-devtools/gcc/libgcc_4.5.1.bb
>> b/meta/recipes-devtools/gcc/libgcc_4.5.1.bb 
>> 
>> +do_install () {
>> +	target=`echo ${MULTIMACH_TARGET_SYS} | sed -e s#-nativesdk##` +
>> +	# Install libgcc from our gcc-cross saved data
>> +	install -d ${D}${base_libdir} ${D}${libdir}
>> +	cp -fpPR ${STAGING_INCDIR_NATIVE}/gcc-build-internal-$target/* ${D}
> 
> ... why can't gcc-cross create the libgcc(-dev) packages? You're
> using the exact files gcc-cross installs, so why have an extra
> recipe? It feels backwards to have one package grab files from
> another package from sysroots and package those.   
I discussed this with Richard in the #yocto IRC channel several days ago.
Richard thinks the packaging of the files should be in a target recipe rather than a cross one.
Cc Richard for further explanation why doing the packaging in a gcc-cross is a mistake. :-)

Thanks,
-- Dexuan

Re: [PATCH 1/2] libgcc: use the new recipe (rather than gcc-runtime) to install libgcc_s.so* and crt*.o

[Koen Kooi]

Op 15 jan 2011, om 12:55 heeft Cui, Dexuan het volgende geschreven:

> Koen Kooi wrote:
>> Op 15 jan 2011, om 12:23 heeft Dexuan Cui het volgende geschreven:
>> 
>>> Currently gcc-runtime installs the files, but actually gcc-runtime's
>>> do_configure checks if the files are available, so before we build
>>> gcc-runtime, 
>>> we should have some recipe install the files first! -- currently
>>> gcc-cross-intermediate actually does that(gcc-cross also installs
>>> the files, 
>>> but it installs into the gcc-build-internal* directory), but
>>> gcc-cross-intermediate will have its own sysroot in future, after
>>> that, 
>>> gcc-runtime won't build. So let us add this new target recipe and
>>> move the 
>>> installation of the files from gcc-runtime into it.
>> 
>> I understand the problem, but...
>> 
>>> diff --git a/meta/recipes-devtools/gcc/libgcc_4.5.1.bb
>>> b/meta/recipes-devtools/gcc/libgcc_4.5.1.bb 
>>> 
>>> +do_install () {
>>> +	target=`echo ${MULTIMACH_TARGET_SYS} | sed -e s#-nativesdk##` +
>>> +	# Install libgcc from our gcc-cross saved data
>>> +	install -d ${D}${base_libdir} ${D}${libdir}
>>> +	cp -fpPR ${STAGING_INCDIR_NATIVE}/gcc-build-internal-$target/* ${D}
>> 
>> ... why can't gcc-cross create the libgcc(-dev) packages? You're
>> using the exact files gcc-cross installs, so why have an extra
>> recipe? It feels backwards to have one package grab files from
>> another package from sysroots and package those.   
> I discussed this with Richard in the #yocto IRC channel several days ago.
> Richard thinks the packaging of the files should be in a target recipe rather than a cross one.
> Cc Richard for further explanation why doing the packaging in a gcc-cross is a mistake. :-)

I know packaging files from gcc-cross leads to all kinds of problems, but you're not using a target recipe, you are now indirectly packaging files from gcc-cross instead of directly.

Since the files are exactly the same, why is this work around better than just packaging them directly. Or the other options, just building a new libgcc with a "real" recipe.

regards,

Koen 

Re: [PATCH 1/2] libgcc: use the new recipe (rather than gcc-runtime) to install libgcc_s.so* and crt*.o

[Richard Purdie]

On Sat, 2011-01-15 at 14:12 +0100, Koen Kooi wrote:
> Op 15 jan 2011, om 12:55 heeft Cui, Dexuan het volgende geschreven:
> 
> > Koen Kooi wrote:
> >> Op 15 jan 2011, om 12:23 heeft Dexuan Cui het volgende geschreven:
> >> 
> >>> Currently gcc-runtime installs the files, but actually gcc-runtime's
> >>> do_configure checks if the files are available, so before we build
> >>> gcc-runtime, 
> >>> we should have some recipe install the files first! -- currently
> >>> gcc-cross-intermediate actually does that(gcc-cross also installs
> >>> the files, 
> >>> but it installs into the gcc-build-internal* directory), but
> >>> gcc-cross-intermediate will have its own sysroot in future, after
> >>> that, 
> >>> gcc-runtime won't build. So let us add this new target recipe and
> >>> move the 
> >>> installation of the files from gcc-runtime into it.
> >> 
> >> I understand the problem, but...
> >> 
> >>> diff --git a/meta/recipes-devtools/gcc/libgcc_4.5.1.bb
> >>> b/meta/recipes-devtools/gcc/libgcc_4.5.1.bb 
> >>> 
> >>> +do_install () {
> >>> +	target=`echo ${MULTIMACH_TARGET_SYS} | sed -e s#-nativesdk##` +
> >>> +	# Install libgcc from our gcc-cross saved data
> >>> +	install -d ${D}${base_libdir} ${D}${libdir}
> >>> +	cp -fpPR ${STAGING_INCDIR_NATIVE}/gcc-build-internal-$target/* ${D}
> >> 
> >> ... why can't gcc-cross create the libgcc(-dev) packages? You're
> >> using the exact files gcc-cross installs, so why have an extra
> >> recipe? It feels backwards to have one package grab files from
> >> another package from sysroots and package those.   
> > I discussed this with Richard in the #yocto IRC channel several days ago.
> > Richard thinks the packaging of the files should be in a target recipe rather than a cross one.
> > Cc Richard for further explanation why doing the packaging in a gcc-cross is a mistake. :-)
> 
> I know packaging files from gcc-cross leads to all kinds of problems,
> but you're not using a target recipe, you are now indirectly packaging
> files from gcc-cross instead of directly.

Looking at the patch, isn't libgcc a target recipe?

The underlying problem here, highlighted when we dived into the separate
sysroots for the toolchain bootstrap is that gcc-runtime builds libstdc
++ against the gcc-cross-intermediate libgcc as its the one in the
sysroot, not the one from gcc-cross as it should.

I do think we should package things in the target recipe context and I
think this is what Dexuan's patch is doing.

> Since the files are exactly the same, why is this work around better
> than just packaging them directly. Or the other options, just building
> a new libgcc with a "real" recipe.

Building libgcc by itself turns out to be quite horrible to do. I live
in hope the gcc guys clean it up but until then...

Cheers,

Richard

Re: [PATCH 1/2] libgcc: use the new recipe (rather than gcc-runtime) to install libgcc_s.so* and crt*.o

[Cui, Dexuan]

Richard Purdie wrote:
> On Sat, 2011-01-15 at 14:12 +0100, Koen Kooi wrote:
>> Op 15 jan 2011, om 12:55 heeft Cui, Dexuan het volgende geschreven:
>> 
>>> Koen Kooi wrote:
>>>> Op 15 jan 2011, om 12:23 heeft Dexuan Cui het volgende geschreven:
>>>> 
>>>>> Currently gcc-runtime installs the files, but actually
>>>>> gcc-runtime's do_configure checks if the files are available, so
>>>>> before we build gcc-runtime, we should have some recipe install
>>>>> the files first! -- currently gcc-cross-intermediate actually
>>>>> does that(gcc-cross also installs the files, but it installs into
>>>>> the gcc-build-internal* directory), but gcc-cross-intermediate
>>>>> will have its own sysroot in future, after that, gcc-runtime
>>>>> won't build. So let us add this new target recipe and move the
>>>>> installation of the files from gcc-runtime into it. 
>>>> 
>>>> I understand the problem, but...
>>>> 
>>>>> diff --git a/meta/recipes-devtools/gcc/libgcc_4.5.1.bb
>>>>> b/meta/recipes-devtools/gcc/libgcc_4.5.1.bb
>>>>> 
>>>>> +do_install () {
>>>>> +	target=`echo ${MULTIMACH_TARGET_SYS} | sed -e s#-nativesdk##` +
>>>>> +	# Install libgcc from our gcc-cross saved data
>>>>> +	install -d ${D}${base_libdir} ${D}${libdir}
>>>>> +	cp -fpPR ${STAGING_INCDIR_NATIVE}/gcc-build-internal-$target/*
>>>>> ${D} 
>>>> 
>>>> ... why can't gcc-cross create the libgcc(-dev) packages? You're
>>>> using the exact files gcc-cross installs, so why have an extra
>>>> recipe? It feels backwards to have one package grab files from
>>>> another package from sysroots and package those.
>>> I discussed this with Richard in the #yocto IRC channel several
>>> days ago. 
>>> Richard thinks the packaging of the files should be in a target
>>> recipe rather than a cross one. Cc Richard for further explanation
>>> why doing the packaging in a gcc-cross is a mistake. :-) 
>> 
>> I know packaging files from gcc-cross leads to all kinds of problems,
>> but you're not using a target recipe, you are now indirectly
>> packaging files from gcc-cross instead of directly.
> 
> Looking at the patch, isn't libgcc a target recipe?
> 
> The underlying problem here, highlighted when we dived into the
> separate sysroots for the toolchain bootstrap is that gcc-runtime
> builds libstdc ++ against the gcc-cross-intermediate libgcc as its
> the one in the sysroot, not the one from gcc-cross as it should.
> 
> I do think we should package things in the target recipe context and I
> think this is what Dexuan's patch is doing.
> 
>> Since the files are exactly the same, why is this work around better
>> than just packaging them directly. Or the other options, just
>> building a new libgcc with a "real" recipe.
> 
> Building libgcc by itself turns out to be quite horrible to do. I live
> in hope the gcc guys clean it up but until then...
> 
> Cheers,
> 
> Richard

Hi Richard,  Thanks a lot for the explanation!

BTW: after careful checking, I found the crt*.o files are actually not packaged properly into the target image (the log is below) :-(
Looks my patch missed something? But looks the original gcc-runtime recipe also hasn't any special?
I'm debugging this. Any quick hint is appreciate!

NOTE: the following files were installed but not shipped in any package:
  /lib/libgcc_s.so
NOTE:   /lib/libgcc_s.so
  /usr/lib/i586-poky-linux/4.5.1/crtbeginS.o
NOTE:   /usr/lib/i586-poky-linux/4.5.1/crtbeginS.o
  /usr/lib/i586-poky-linux/4.5.1/crtfastmath.o
NOTE:   /usr/lib/i586-poky-linux/4.5.1/crtfastmath.o
  /usr/lib/i586-poky-linux/4.5.1/libgcc.a
NOTE:   /usr/lib/i586-poky-linux/4.5.1/libgcc.a
  /usr/lib/i586-poky-linux/4.5.1/libgcov.a
NOTE:   /usr/lib/i586-poky-linux/4.5.1/libgcov.a
  /usr/lib/i586-poky-linux/4.5.1/crtend.o
NOTE:   /usr/lib/i586-poky-linux/4.5.1/crtend.o
  /usr/lib/i586-poky-linux/4.5.1/crtbeginT.o
NOTE:   /usr/lib/i586-poky-linux/4.5.1/crtbeginT.o
  /usr/lib/i586-poky-linux/4.5.1/crtbegin.o
NOTE:   /usr/lib/i586-poky-linux/4.5.1/crtbegin.o
  /usr/lib/i586-poky-linux/4.5.1/crtendS.o
NOTE:   /usr/lib/i586-poky-linux/4.5.1/crtendS.o
  /usr/lib/i586-poky-linux/4.5.1/crtprec32.o
NOTE:   /usr/lib/i586-poky-linux/4.5.1/crtprec32.o
  /usr/lib/i586-poky-linux/4.5.1/libgcc_eh.a
NOTE:   /usr/lib/i586-poky-linux/4.5.1/libgcc_eh.a
  /usr/lib/i586-poky-linux/4.5.1/crtprec80.o
NOTE:   /usr/lib/i586-poky-linux/4.5.1/crtprec80.o
  /usr/lib/i586-poky-linux/4.5.1/crtprec64.o
NOTE:   /usr/lib/i586-poky-linux/4.5.1/crtprec64.o

Thanks,
-- Dexuan

Re: [PATCH 1/2] libgcc: use the new recipe (rather than gcc-runtime) to install libgcc_s.so* and crt*.o

[Cui, Dexuan]

Cui, Dexuan wrote:
> BTW: after careful checking, I found the crt*.o files are actually
> not packaged properly into the target image (the log is below) :-(
> Looks my patch missed something? But looks the original gcc-runtime
> recipe also hasn't any special?  
> I'm debugging this. Any quick hint is appreciated!
> 
> NOTE: the following files were installed but not shipped in any
>   package: /lib/libgcc_s.so
> NOTE:   /lib/libgcc_s.so
>   /usr/lib/i586-poky-linux/4.5.1/crtbeginS.o
Hi, the issue was fixed: I didn't define PREFERRED_PROVIDER and PROVIDES properly.

I'll resend the new pull request soon.
 
Thanks,
-- Dexuan

Re: [PATCH 2/2] libc-package.bbclass: should not rm scsi/*.h

[Tom Rini]

On 01/15/2011 04:50 AM, Cui, Dexuan wrote:
> Koen Kooi wrote:
>> Op 15 jan 2011, om 12:23 heeft Dexuan Cui het volgende geschreven:
>>
>>> {e}glibc should install the scsi/*.h files, which are needed by hal.
>>> Currently hal can build because eglibc-initial (which has its own
>>> do_install) installs the files. In future eglibc will have its own
>>> sysroot, so hal
>>> won't build.

Unrelated, is it on the roadmap already to upgrade things to use 
devicekit rather than hal?

>>> BTW: in OE side, eglibc's do_install also doesn't remove the files.
>>
>> As some background info: There's a conflict between
>> linux-libc-headers-dev and libc-dev when installing on the target. In
>> OE we do this instead:
>>
>> koen@dominion:/OE/org.openembedded.dev$ grep scsi
>> recipes/linux-libc-headers/ -rn
>> recipes/linux-libc-headers/linux-libc-headers_2.6.32.bb:23:     rm -f
>> ${D}${exec_prefix}/include/scsi/scsi.h
>> recipes/linux-libc-headers/linux-libc-headers_2.6.31.bb:23:     rm -f
>> ${D}${exec_prefix}/include/scsi/scsi.h
>> recipes/linux-libc-headers/linux-libc-headers_2.6.34.bb:42:     rm -f
>> ${D}${exec_prefix}/include/scsi/scsi.h
> My understanding is:
> Linux kernel should not export these files: in OE side see 91d3d92a acked by you. :-)
> So {e}glibc should supply the files -- previously poky did supply, but 7379ee77 removed the files -- I think this is incorrect.
>
> BTW: in poky, we can see linux-libc-headers_2.6.36.bb also correctly removes the file.

Correct.  The kernel (incorrectly) re-introduced exporting <scsi/scsi.h>.

-- 
Tom Rini
Mentor Graphics Corporation