2011-01-30 23:03:56     Problems / Questions regarding BuildToolChain script & CHOST...

Document created by Aaronwu Employee on Oct 16, 2013
Version 1Show Document
  • View in full screen mode

2011-01-30 23:03:56     Problems / Questions regarding BuildToolChain script & CHOST...

Robert Cochran (UNITED STATES)

Message: 97799   

 

I'm working with a trunk toolchain (r 5168) on Ubuntu Linux x86_64 .

 

I was digging into why expat is always rebuilt when I execute the BuildToolChain script even though I already have it installed.  Note, I'm just passing the basic flags when executing BuildToolChain: -s, -k, -u, -b.

 

I determined that the result of a binutils-xxx/config.guess produces an apparent bad guess (x86_64-unknown-linux-gnu), and this is assigned to my CHOST variable and subsequently used as a prefix to gcc inside check_lib() to see whether the expat library exists.

 

Since I don't have a x86_64-unknown-linux-gnu-gcc compiler, expat is flagged as not being installed.  This is done in the check_lib() func inside buildscript/lib/prereqs.sh.  The CHOST prefix is passed as the second parameter of check_lib().

 

If I try to set CHOST myself using the -H flag, then I get problems in scrub_path.  It seems that the logic in that function is determined to flag an error believing that I'm trying to cross compile a cross compile.

 

So, I'm thinking there are 2 potential bugs:

 

i)  The call to check_lib() inside build_expat(), build_curses(), etc. shouldn't be passed a guessed prefix.

 

ii) Flagging a set CHOST as an error inside scrub_path() just because it's set and no bfin toolchain exists seems to be bad logic.

 

Thanks,

 

Bob

 

P.S.   Functions like build_curses() never gets to call check_lib() since it first tests whether CHOST==CBUILD (a cross compile test?).  Perhaps that's the way to fix build_expat()?

 

QuoteReplyEditDelete

 

 

2011-01-30 23:34:06     Re: Problems / Questions regarding BuildToolChain script & CHOST...

Mike Frysinger (UNITED STATES)

Message: 97800   

 

check_lib is supposed to be testing the full tuple.  further, we want the behavior of building against a local expect so that it is linked in statically.  this avoids SONAME issues when we distribute binaries.

 

use '-S expat' for your own local builds.

QuoteReplyEditDelete

 

 

2011-01-31 08:30:19     Re: Problems / Questions regarding BuildToolChain script & CHOST...

Robert Cochran (UNITED STATES)

Message: 97809   

 

Thanks for the reply & suggestion Mike.

 

I'm still thinking there are some inconsistencies here.

 

When testing for the full tuple (pkg, lib, & headers) during check_source_packages, check_source_group() subsequently calls check_lib() without passing a gcc prefix.  I'm wondering why no prefix is passed in this case but is later passed when testing for only the presence of a lib in the case of build_expat or build_curses.

 

I'm also wondering why there is a if [ "${CBUILD}" = "${CHOST}" ] || check_lib for build_curses, build_pthreads, and

build_zlib but not for build_expat (it just blindly calls check_lib() without the test).

 

Thanks,

 

Bob

QuoteReplyEditDelete

 

 

2011-02-01 03:42:02     Re: Problems / Questions regarding BuildToolChain script & CHOST...

Mike Frysinger (UNITED STATES)

Message: 97838   

 

check_source_packages is designed as a sanity check for common user mistakes.  that is it.

 

all the build_xxx are designed to build up commonly missing packages required for a toolchain release.  if the package is checking for cbuild/chost, it means it is a "core" enough package that every distro out there will have it and thus we can safely dynamically require it.  we only spend time building it up when targeting a non-linux system (and thus are not building it natively).

 

if it doesnt check things, then it is too much of a hassle to dynamically require it in the end users' systems, and thus we want to force a local build of it.

 

yes, the code is probably a bit idiosyncratic as you describe, but it is working in the ways we desire currently.  i imagine this isnt in the way you'd like though, but "-S expat" should provide for your immediate needs.

Attachments

    Outcomes