upgrade libc-package.bbclass; add libgcc

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.

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

Quoted 4 lines

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

Quoted 8 lines

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...

Quoted 3 lines

meta/recipes-devtools/gcc/libgcc_4.5.1.bb +0 -0

meta/recipes-devtools/gcc/libgcc_4.5.1.bb line 31

Quoted 5 lines

meta/recipes-devtools/gcc/libgcc_4.5.1.bb +5 -0

+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.

Quoted 20 lines · Koen Kooi

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

Quoted 4 lines

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

Quoted 8 lines

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...

Quoted 3 lines

meta/recipes-devtools/gcc/libgcc_4.5.1.bb +0 -0

Quoted 10 lines

meta/recipes-devtools/gcc/libgcc_4.5.1.bb line 31

Quoted 5 lines

meta/recipes-devtools/gcc/libgcc_4.5.1.bb +5 -0

+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. :-)

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

Quoted 31 lines

Quoted 30 lines · Koen Kooi

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

Quoted 4 lines

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

Quoted 8 lines

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...

meta/recipes-devtools/gcc/libgcc_4.5.1.bb line 31

Quoted 8 lines

meta/recipes-devtools/gcc/libgcc_4.5.1.bb +5 -0

 
+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.

Quoted 3 lines

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.

Quoted 37 lines · Koen Kooi

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

Quoted 29 lines

Quoted 17 lines · Koen Kooi

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

Quoted 9 lines

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...

Quoted 3 lines

meta/recipes-devtools/gcc/libgcc_4.5.1.bb +0 -0

Quoted 11 lines

Quoted 6 lines

meta/recipes-devtools/gcc/libgcc_4.5.1.bb +5 -0

+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.

Quoted 5 lines

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. :-)

Quoted 3 lines

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.

Quoted 3 lines

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

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

{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.

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

Quoted 7 lines

{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   

Quoted 7 lines · Koen Kooi

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

Quoted 5 lines

{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.

Quoted 6 lines

Quoted 1 line

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:

Quoted 8 lines

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.