24test11 menuconfig problem

24test11 menuconfig problem

[Marshall, Hunter]

I am new to this endeavor, forgive my naivete. I have many problems, but
only 2 of which I'll bring up  :-)

 1) With a stock 2.4test11 kernel, I succesfully applied the
patch-2.4.0-test11-rmk1.gz file. When I do "make menuconfig", I get a brief
flash of alternate character set (as if a I was cat'ing a binary file) and
then the config screen. Choosing "System Type" causes the program to crash.
"make xconfig" seems to work, but I am unsure whether to proceed with
confidence.

I am not sure of the point of this, since I am not knowledgeable with the
config process of the linux kernel (but will probably need that info in the
future). Is "make dep" sufficient to put the headers in the correct state?

 2) I tried to make the gcc (2.95.2) build aware of the glibc headers by
doing 
"../gcc2.95.2/configure --target=arm-linux
--with-headers=/usr/local/src/glibc-2.1.3/include". This got me farther
(further?) than I had gotten on my previous attempt (i THINK), but still
failed as shown below. What is the right way to do this?

I forgot, I have an additional problem. I can post to the list, but do not
receive it. I have an email in to crossgcc-owner, but for now, replies will
have to come to directly.

Thanks. I wish I had something more esoteric to contribute.  :-(

	hunter

================== LAST SECTION OF FAILED "MAKE LANGUAGES=C"
for name in _muldi3 _divdi3 _moddi3 _udivdi3 _umoddi3 _negdi2 _lshrdi3
_ashldi3 _ashrdi3 _ffsdi2 _udiv_w_sdiv _udivmoddi4 _cmpdi2 _ucmpdi2
_floatdidf _floatdisf _fixunsdfsi _fixunssfsi _fixunsdfdi _fixdfdi
_fixunssfdi _fixsfdi _fixxfdi _fixunsxfdi _floatdixf _fixunsxfsi _fixtfdi
_fixunstfdi _floatditf __gcc_bcmp _varargs __dummy _eprintf _bb _shtab
_clear_cache _trampoline __main _exit _ctors _pure; \
do \
  echo ${name}; \
  /usr/local/src/gcc-2.95.2.build.arm/gcc/xgcc
-B/usr/local/src/gcc-2.95.2.build.arm/gcc/ -B/usr/local/arm-linux/bin/
-I/usr/local/arm-linux/include -O2  -DCROSS_COMPILE -DIN_GCC     -g -O2
-I./include  -fomit-frame-pointer -fPIC -g0 -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED    -I. -I../../gcc-2.95.2/gcc
-I../../gcc-2.95.2/gcc/config -I../../gcc-2.95.2/gcc/../include -c
-DL${name} \
       ../../gcc-2.95.2/gcc/libgcc2.c -o ${name}.o; \
  if [ $? -eq 0 ] ; then true; else exit 1; fi; \
  arm-linux-ar rc tmplibgcc2.a ${name}.o; \
  rm -f ${name}.o; \
done
_muldi3
In file included from ../../gcc-2.95.2/gcc/libgcc2.c:41:
/usr/local/lib/gcc-lib/arm-linux/2.95.2/../../../../arm-linux/sys-include/st
dlib.h:7: stdlib/stdlib.h: No such file or directory
In file included from ../../gcc-2.95.2/gcc/libgcc2.c:42:
/usr/local/lib/gcc-lib/arm-linux/2.95.2/../../../../arm-linux/sys-include/un
istd.h:2: posix/unistd.h: No such file or directory
make[3]: *** [libgcc2.a] Error 1
make[3]: Leaving directory `/usr/local/src/gcc-2.95.2.build.arm/gcc'
make[2]: *** [stmp-multilib-sub] Error 2
make[2]: Leaving directory `/usr/local/src/gcc-2.95.2.build.arm/gcc'
make[1]: *** [stmp-multilib] Error 1
make[1]: Leaving directory `/usr/local/src/gcc-2.95.2.build.arm/gcc'
make: *** [all-gcc] Error 2

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: 24test11 menuconfig problem

[Jani Monoses]

On Tue, 12 Dec 2000, Marshall, Hunter wrote:

> I am new to this endeavor, forgive my naivete. I have many problems, but
> only 2 of which I'll bring up  :-)
> 
>  1) With a stock 2.4test11 kernel, I succesfully applied the
> patch-2.4.0-test11-rmk1.gz file. When I do "make menuconfig", I get a brief

for this one the remedy is putting an 'endmenu' at line 106 in
arch/arm/config.in or picking up the appropriate patch form the
armlinux site.

Can't help with problem #2 :(

Jani.



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: 24test11 menuconfig problem

[Kai Ruottu]

"Marshall, Hunter" wrote:
> 
>  2) I tried to make the gcc (2.95.2) build aware of the glibc headers by
> doing
> "../gcc2.95.2/configure --target=arm-linux
> --with-headers=/usr/local/src/glibc-2.1.3/include". This got me farther
> (further?) than I had gotten on my previous attempt (i THINK), but still
> failed as shown below. What is the right way to do this?

 The generic instructions for a cross-compiler are:

 1. Get the target headers and libs, if available, then preinstall them
    into $prefix/$target/include and $prefix/$target/lib

 2. Build binutils for the target and install them into $prefix/bin and
    $prefix/$target/bin (the 'make install' does this)

 3. Build GCC using the same values for $prefix and $target as with
    binutils (and when preinstalling the target headers and libs)

 There may be bugs preventing everything to work while building, but this
is just the 'official' way described in the GCC manual. For gcc-2.95.2 the
pre-creation of the '$prefix/lib/gcc-lib/$target/2.95.2' may be necessary
because all the search paths to the target stuff go through it... This is
the reason for many problems and toying with the '--with-headers=...' for
the purpose of finding the standard C headers for the target.

 The use of '--with-headers' is recommended to be used for the Linux
kernel headers while building glibc, but using it while configuring GCC is
questionable. Although the important 'the' is missing from the 'www.gnu.org'
instructions for 'configure', this has mislead quite many to think that the
standard headers are talked about, while 'headers' without 'the' should say
that 'some unspecified headers' can be pointed to and fixed for GCC using the
'--with-headers' or preinstalling them into the $prefix/$target/sys-include'.
Ok here is the original purpose for the 'sys-include', taken from the GCC
manual:

-------------------------- clip ------------------------------------------
SYSTEM_INCLUDE_DIR
  Define this macro as a C string constant if you wish to specify a system-
  specific directory to search for header files before the standard directory.
  SYSTEM_INCLUDE_DIR comes before STANDARD_INCLUDE_DIR in the search order.
-------------------------- clip ------------------------------------------

 The standard C headers in the STANDARD_INCLUDE_DIR, '$prefix/$target/include',
could be meaned if there would be a 'the headers' in the gnu.org instructions.

 BTW, seeing the gnu.org description for the '--with-newlib', will help everyone
the 'eprintf' hates...

 Ok, back to the subject...

 For the 'arm-linux' case this means that some prebuilt glibc-2.1.x stuff
is preferred for the 'target headers and libs' for the 1st stage bootstrap
compiler, but even using the newlib headers may succeed... If building under
Linux/x86 with glibc-2.1.x, copying the native headers from '/usr/include'
for the Linux/ARM toolset will be fine after some fixes to the copies, like
changing the 'asm' symlink to '/usr/src/linux/include/asm-arm' from its
original '.../include/asm-x86'. Then the '.../include/bits' might have had
some differences between x86 and ARM... I used this method for my 'arm-linux'
toolset...

 Some 'arm-linux' glibc-2.1.x distribution, like the HardHat (www.mvista.com),
searching via ' http://www.arm.linux.org.uk ' etc. should lead to some prebuilt
glibc...  Then building even a full GCC with libiberty and libstdc++ may
succeed (but for using the toolset mainly with the prebuilt glibc-2.1.x).

 Having only some suitable headers enables one to build only GCC (make all-gcc)
in the '.../gcc' subdirectory.

 Perhaps it isn't clear for everybody, but GCC is really built and ready
when the 'gcc' subdirectory has been handled!!!! The 'libiberty', 'libobjc',
'libf2c', 'libstdc++' etc. are just extra stuff and can be built after both
GCC and the C library, glibc in this case, have been built and they work...

 When the 'bootstrap-GCC', built with some headers which enable it to be built,
is ready and installed, building glibc-2.1.3 (or the new '2.2' ?) for 'arm-linux'
with it should succeed.

 After the new glibc for 'arm-linux' has been built and installed, rebuilding
the 'libgcc.a' and continuing to build the 'libiberty' etc. should succeed.
Forcing to rebuild 'libgcc.a' happens by removing the stamps 'libgcc2.ready'
and 'stmp-multilib' in the 'gcc' subdir.

 The target headers don't have any influence to the resulted 'arm-linux' target
compiler, only to the libraries it creates, so only rebuilding 'libgcc.a' and
all the other libs after it is necessary.

 The rules for all Linux targets are quite the same, so the 'www.penguinppc.org'
Mini-FAQ about cross-compiling for Linux/PPC will be fine for Linux/ARM too. The
main principles only, not taking everything as written (the Mini-FAQ has bugs too
in the kernel-headers symlink commands...)

Cheers, Kai


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com