striking out at the eabi

[Michael K. Edwards]

On 5/8/06, Martin Guy <martinwguy@gmail.com> wrote:
> > The patch attached to "More crosstool-0.42-glibc-2.4-gcc-4.1.0-nptl"
> > works around this by adding a "GLIBC_FAKE_CROSS_ARGS" parameter to
> > crosstool.

Incidentally, I don't consider my patch fit for application to
mainline crosstool; I just thought it might help Mike get past the
"old headers" problem while elegant solutions are sought for the
individual problems it addresses.

> True, but that version includes many unrelated extra twiddles here and
> there, such as the mysterious
>
> -    ${GCC_CORE_DIR}/configure $CANADIAN_BUILD --target=$TARGET
> --host=$GCC_HOST --prefix=$CORE_PREFIX \
> +    eval ${GCC_CORE_DIR}/configure $CANADIAN_BUILD --target=$TARGET
> --host=$GCC_HOST --prefix=$CORE_PREFIX \

The "eval" undoes a level of quoting; it's the only thing I could come
up with that makes passing multiple flags to --enable-cxx-flags work. 
Sorry, I should have connected the two when I posted it.  The other
mysterious change I made (removing curly braces in ${GCC_EXTRA_CONFIG}
probably has no effect and can be undone, as can the removal of the
attempt at active FTP in getandpatch.sh.

The files added in the top level (earm.{config,dat} and
latest.{dat,sh}) should probably be renamed to join the other demos
once the result is properly tested.  The other files I introduced are
patches to binutils 2.16.92 (build breakage fix from Daniel
Jacobowitz) and glibc 2.4 (--with-tls=force to work around another
problem bootstrapping linux headers with the host compiler). 
--with-tls=force hits a spot in your patch; otherwise I think I've
preserved your approach to TLS/NPTL, which seems good to me.

> and creates extra files.  Working on distilling its essence into an
> independent patch, it turns out there are (now) four different
> variables to include extra cc flags in the glibc build:
> 1) TARGET_CFLAGS applied everywhere we build binaries for the target
> 2) GLIBC_FAKE_CROSS_ARGS passed in making the headers
> 3) GLIBC_EXTRA_CC_ARGS passed to glibc configure as "CC=... $G_E_C_A"
> 4) EXTRA_TARGET_CFLAGS passed to glibc configure as "CFLAGS=... $E_T_C"
>
> I understand the reason for TARGET* and EXTRA_TARGET*: it is so you
> can set one in <cpu>.dat and the other in <gcc-glibc>.dat
>
> A couple of questions:
>
> Is there actually any operational difference between 3) and 4) or can
> the unused G_E_C_A be dropped?

CFLAGS only gets applied during compiling steps; in principle it
shouldn't affect preprocessing-only steps (that would be CPPFLAGS) or
the use of gcc as a linker driver.  I don't know whether the
particular flags we are passing could just as easily be in CFLAGS, but
anything that is needed when linking would probably need to be
shoehorned into configure using GLIBC_EXTRA_CC_ARGS.

> If we simply apply TARGET_CFLAGS and EXTRA_TARGET_CFLAGS also in the
> glibc header building phase, doesn't that achieve the effect of
> *FAKE*?

Well, __ARM_EABI__ is automagically defined by the compiler; it's not
in *TARGET_CFLAGS at all.  Setting it on the command line of the
cross-compiler probably isn't the Right Thing; for all I know the
compiler gives it a non-trivial value and it's used elsewhere. 
Besides, it's quite possible for TARGET_CFLAGS and EXTRA_TARGET_CFLAGS
to contain flags that the host gcc doesn't know about; so I don't
think we want to use them in the header bootstrapping step.

I wanted to isolate my change to the step that is known to be kind of
cheating anyway (using the host gcc as if it were the cross-compiler
just long enough to adapt the glibc and linux headers to one another
during ./configure).  GLIBC_FAKE_CROSS_ARGS seemed like as good a name
as any.

Cheers,
- Michael

--
For unsubscribe information see http://sourceware.org/lists.html#faq