ltib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltib] Issue when changing toolchains in a build


From: Stuart Hughes
Subject: Re: [Ltib] Issue when changing toolchains in a build
Date: Thu, 04 Oct 2012 19:47:50 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0

Hi Peter,

I cooked something up on the train home. It's not really been tested, but seems to work.

The main issue I see with this is that until now, if you switched toolchains and you had a cached version of a package rpm that matched the new toolchain options, it would just install (not rebuild) that package.

With this change in place, any unpacked package (in rpm/BUILD) will have "make distclean" run on it, this will change the source tree and so force a rebuild of that package, even if ultimately there is not difference relative to the cached rpm. This only affects unpacked packages, the others should just install without a build.

Please take a look and feel free to suggest improvements. Let me know if there are any unwanted other side-effects I can't think of.

Regards, Stuart

On 04/10/12 15:50, Stuart Hughes wrote:
Okay, got it now. I think I can come up with something to do this. Will look into it.

On 04/10/12 15:07, Peter Barada wrote:
On 10/04/2012 08:13 AM, Peter Barada wrote:
It's other packages...
To be specific, its _any_ prepped package that was built using the older
toolchain.  Yes, I see how the kernel handles this case.  I *could* add
into every .spec file's %build stanza a test for ${LTIB_FULL_REBUILD}
and if set then do "make distclean", but since LTIB already has code in
place to remove all the packages I figured it would be easier during the
RPM removal to see if the builddir existed and if so execute "make
distclean" to clean it out (ignoring the result of make in cases where
they package doesn't have a proper distclean make stanza).
Splat-fingered from my iPhone

On Oct 4, 2012, at 2:29 AM, "Stuart Hughes"<address@hidden>  wrote:

On 03/10/12 17:45, Peter Barada wrote:
On 10/03/2012 12:08 PM, Stuart Hughes wrote:
On 03/10/12 16:46, Peter Barada wrote:
Stuart,

If I have a build where the kernel source is needed to build another module, (or some other package source is needed for another package to build), then the package is built and the source/object files are in
rpm/BUILD.  If I then do "./ltib -c" and change the toolchain, LTIB
properly de-installs all the packages, and then builds the packages
again using the new toolchain, including the source that was left behind
from the previous build.

So far so good, but if the new toolchain default (on ARM for example) causes incompatible object files (i.e. using hard vs soft float ABI on ARM), then the package source that was previously built will fail to
build/link due to the incompatibility.

I think the right way to fix this is to execute a "distclean" on package source that exist, triggered by ${LTIB_FULL_REBUILD} before rebuilding, but so far I haven't quite figured out the path to get this to happen. I'm more than happy to tackle it but need a pointer that makes the code
flow clear.

Thanks in advance!

Hi Peter,

I agree with your analysis.  Again I need to go off and think about
this dark corner of LTIB.  Once I've refreshed my memory, I'll get
back to you.
Thanks!

Hi Peter,

In the case of kernels, they should already do a full clean if a
LTIB_FULL_REBUILD is set.  If you look in
./dist/lfs-5.1/kernel/kernel-common.tmpl line 114, you'll see:

#
# Check for ltib full rebuilds (e.g. change of toolchain) if so
# force a build from scratch
#

if [ -n "$LTIB_FULL_REBUILD" ]
then
     make ARCH=$LINTARCH HOSTCC="$BUILDCC" mrproper
fi

Is this causing a problem/not working, or is it other packages that you
need to distclean?

Regards, Stuart




_______________________________________________
LTIB home page: http://ltib.org

Ltib mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/ltib

Attachment: ltib-clean-src.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]