This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
> 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 \
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*?
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |