All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Malkowski <eric@bvwireless.net>
To: buildroot@busybox.net
Subject: [Buildroot] Remove and Rebuild "project_build_arch/project/root" tree
Date: Wed, 11 Feb 2009 14:18:55 -0500	[thread overview]
Message-ID: <4993249F.5070502@bvwireless.net> (raw)

Hi everyone-

It's been since November, 2007 since I last grabbed a copy of buildroot 
for a project -- a lot is the same since then, but obviously a lot has 
changed too.

I'm creating a new project based off the tip of svn which is RC4 + 
r25295: gmp/mpfr use static since shared libs are gone -- Peter recently 
committed.  BTW: the unwanted rebuild of mpfr when make is called again 
appears to work fine for me having seen the issue w/ pure RC4 from 2 
days ago.

In the past I've built everything and then just called make to rebuild 
stuff and when things look good, I would use a small script to clean out 
the rootfs and call make to just populate w/ shared libs and binaries by 
having the "make install" portion of everything take care of re-creating 
the rootfs tree under project_build_$(ARCH)/project/root.  This is very 
handy when making wholesale changes to a customized target skeleton so I 
can be confident there's no stale stuff hanging around in the final 
rootfs filesystem.  The script is called "rebuild_root.sh" and looked 
like this:

  #!/bin/sh

  set -x

  rm -f build_i486/grub-0.97/.installed
  rm -f toolchain_build_i486/gcc-4.2.1-final/.libs_installed

  rm -rf project_build_i486/wireless/root
  rm -f project_build_i486/wireless/.root
  rm -f build_i486/staging_dir/.fakeroot.00000

  make

On past projects the above worked great.  With the latest buildroot I'm 
finding after a complete build of everything from scratch, calling 
rebuild_root.sh would rebuild (unwantingly) the uClibc 0.9.30 static and 
shared libs and install those -- that's not too bad -- it would then 
carry on and just install busybox binaries and various packages 
rebuilding my rootfs from a fresh target_skeleton.

But -- calling rebuild_root.sh a second time would cause a bunch of 
additional toolchain related stuff (gcc final) and busybox itself to be 
recompiled, but NOT uClibc -- it's not consistent.  Calling it a third 
time is like the first time -- rebuild just uClibc 0.9.30 and then just 
install busybox, other packages etc.

In tracing this a bit, first rebuild causes uClibc to call "make 
install_runtime" and it recompiles the libs, installs in TARGET_DIR -- 
everything else just installs, nothing else rebuilds
The second rebuild causes uClibc to call "make install_runtime 
install_dev" which skips compling uclibc like the first rebuild, but 
some headers are re-created which causes a call to just "make 
install_runtime", that skips compiling uClibc -- fine, but 
gcc-4.3.2-final would run configure and make and rebuild libiberty -- 
recompiling all of that.  That then causes busybox to recompile 
everything due to some dependency on gcc/uclibc being partially rebuilt 
(I think).  The remaining stuff after busybox installs fine w/o rebuilds.
Do a third rebuild, it behaves like the first rebuild and the pattern 
repeats.

My goal is to be able to somehow remove 
project_build_$(ARCH)/$(PROJECT)/root and call make to re-populate while 
minimizing stuff from being rebuilt -- just allow the various "make 
installs" to re-populate.  Does anyone have any suggestions / 
alternatives to meet my goal?  I'm open for other approaches -- perhaps 
what I'm doing is overkill?

If my approach seems doable -- can anyone advise what files to remove or 
touch so I can re-build the root from empty and let genxt2fs create my 
compressed rootfs -- it's very handy when trying to just re-build 
add-ons to the base buildroot toolchain + packages and re-create the 
rootfs.

If the toolchain is just too inter-twined with dependencies on things 
under project_build_$(ARCH)/$(PROJECT)/root, then I will try to work 
around it -- I guess I can get everything working w/o removing the 
rootfs wholesale or perhaps not remove the various .so files placed in 
there by gcc/uclibc/toolchain related "make install" stuff, but 
suggestions are appreciated.

On another note -- the OpenSSL and OpenSSH packages for whatever reason 
don't re-build or re-install their binaries in the rootfs when doing 
this.  In the past they did and the only package I had to force into 
re-populating it's binaries was grub as seen above along with the 
gcc-4.2.1-final libgcc shared libs by removing .libs_installed -- I've 
noticed .libs_installed is no longer, grub doesn't install it's 
binaries, and OpenSSL / OpenSSH similar to grub don't install their 
binaries upon trying to rebuild root.

Sorry to be so long winded -- any ideas appreciated.

Thanks,

-Eric Malkowski

             reply	other threads:[~2009-02-11 19:18 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-11 19:18 Eric Malkowski [this message]
2009-02-11 21:29 ` [Buildroot] Remove and Rebuild "project_build_arch/project/root" tree Eric Malkowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4993249F.5070502@bvwireless.net \
    --to=eric@bvwireless.net \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.