[ELDK] Building ELDK from scratch

[Wolfgang Denk]

In message <1208798748.28519.35.camel at pterry-fc6.micromemory.com> you wrote:
> I'm trying to build ELDK (head from git) for a project I'm working on.
> 
> I'm using a Mandriva 2007 Spring laptop and a Fedora 6 desktop. The
> former is my preferred machine and the latter is to try and use an ELDK
> supported host system.
> 
> I'm seeing build problems on both machines. I'm trying to work my way
> through them but the type of things which are happening raise a few
> questions for me.

Such problems are to be expected. There are two tested and  known  to
be  working host environments at the moment: RedHat 7.3 (which we use
for production builds, as this guarantees the best compatibility even
with older Linux distributions like RHEL etc.), and Fedora Core  5  -
both with all available updates installed.

> First, I had rpm problems. Mandriva uses version 4.4.6 which seems not
> to allow non-root users to use the chroot option heavily used by ELDK so

ELDK does not use chroot at all. No part of the build process requires
to use chroot.

> 1. You must set MAKEINFO environment variable to makeinfo for the eldt
> make build (eldt.4) to work.

This is not needed in the environments mentioned above.

> 2. You need a base set of packages available on your host:
> 	flex for crosstools
> 	binutils-devel for libiberty in ldd
> 	and I'm sure I'll find more...

Currently we don't have documentation about which poackages  have  to
be  installed  -  both  build  systems were just "install everything"
machines.

If you come up with such a list, it  would  be  great  if  you  could
document  this  -  please feel free to open a section for this in the
DULG wiki.

> 3. My system has xemacs instead of emacs installed so autoconf won't
> install correctly without patching the SPEC file.

Note that this comes from a  standard  Fedora  RPM.  There  are  many
unfortunate dependencies in these RPMs.

> 4. The trg gcc build fails because of a locale issue to do with de_DE.
> The localedef invocation (occurs on my mandriva build but not on the
> Fedora 6 build) fails because ISO-8859-1 is not found in the charset
> directory /usr/share/i18n/charset which is not present on the work cross
> build. If I run the localdef of my host (after installing
> glibc-i18ndata) it works fine but the cross_tool path localdef
> (installed from elocaldef build eldt.17) fails. So I patched out the
> de_DE check in the spec file to get past this... don't know what the
> correct solution should be.

You probably have not installed all required language packets (EN + DE
should be all that's needed).

> On the Fedora 6 none of this happens.

This is because ELDK is an offspring of Fedora.

> So I have installed gtk-doc on my Mandriva and my Fedora box is running
> a local apache web server...

No web server is needed to be running for ELDK builds.

> So what I'm questioning is why is the ELDK build process so sensitive to
> host development system configuration and user options (I'm not allowed
> to use xemacs or run a webserver!) when it goes to such great lengths to

Thisis not intentional, but a result of the complexity of all the
included packages itself.

For an experiment, you can try to just take the Fedora 8 source  RPMs
and  try  to  build  Fedora 8 from scratch. This should be realtively
easy, as it avoids the additional complexity of cross compiling.  But
try it out yourself, and you will find that it is extremely difficult
if you don't have a pretty complete installation of at least Fedora 6
or 7, and even then it requires several iterations and manual control
to work around for example cyclic build depencencies etc.

ELDK inherits allt ehse problems, plus it hjas to face the additional
complexity of cross-building.

It is only guys like you who tried to rebuild allt his  from  scratch
who  get an (initial) understanding of all the effort to put the ELDK
together.

Improvements are more than welcome, of course.

> compile a cross compile system and set the paths explicitly. Shouldn't
> it be "jailed" in its own eldt/trg constraints, ie it builds all the
> tools it needs first and then uses only those tools to build its target.

Yes, it should. But we live in a real world, and the "tools it  needs
first"  include  extremely complex items like gcc, glibc or binutils.
And these change quite frequently, so any changes you make will  have
to  be done frequently. We tried to come up with a configuration that
works reliably in a few restricted build environments. The  currently
available  "install  everywhere  -  build  only  on  a  few  systems"
situation may  be  not  perfect,  but  extending  this  to  a  "build
everywhere"  system is probably beyond the manpower we have avalaible
for this. Contributions from the community are more than welcome.

> Have I misunderstood something or configured something wrong or missed
> some step in the build process?

I don't think so. Maybe you underestimated the complexity of the task
a bit.

> By the way, as I'm rerunning builds so frequently I do have a patched
> version of ELDK_BUILD which reruns a build from the failed step so you
> can tryout fixes without running halfday builds for crosstools! I'll
> post the patch if anyone's interested (adds a couple of environment
> variable DEV_BUILD and DEV_BUILD_STEP to preserve the old build tree and
> rerun stage DEV_BUILD step DEV_BUILD_STEP, behaviour is standard if
> these variables aren't set)

Sure. Please post your patches, these any others that may follow.

Thanks in advance.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I knew then (in 1970) that a 4-kbyte minicomputer would cost as much
as a house. So I reasoned  that  after  college,  I'd  have  to  live
cheaply in an apartment and put all my money into owning a computer."
      - Apple co-founder Steve Wozniak, EE Times, June 6, 1988, pg 45