[poky] [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