This is the mail archive of the crossgcc@sources.redhat.com 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]

RE: More MIPS Compiling Problems...


>-----Original Message-----
>From: David Morris [mailto:lists@morris-clan.net]
>Sent: 23 May 2001 17:31

>On Wed, 23 May 2001, David Korn wrote:
>>   Do you have plans to use any C library at all?  I assume from your
>> comment about putting the entire code in the cache that you probably
>> don't want any of the stdlib functions, but you'd still need to build
>> the compiler with a library, and then just not have it linked in by
>> not using any of the functions....
>
>If I don't include the "--with-headers=/usr/include" line, the compile
>fails saying it cannot find "stdlib.h" and a couple of others....that
>was the only way to continue the compile.....if you have a better
>suggestion, please put it forward.  Perhaps there is a different
>set of headers I should point it to in order to keep compilation from
>failing?  (I can provide the exact error if you like....just have to
>re-compile without the headers and that takes awhile).

  Yes indeed so.  But you can't just choose any old random headers!  Let
me explain what's going on here.

  There's a library that comes with the compiler called libgcc.a; it
contains some very low-level support functions for things like long long
maths (on targets that don't have suitable 64-bit maths operations built
in), exception handling, and a few other bits and pieces.

  Since this library is built for the target system, it's effectively
a program being cross-compiled for the target CPU.  In particular, it
needs to know about the sizes of the natural datatypes on the target
CPU and who knows what else.  The point is, it's a target program, so
it needs the headers that are appropriate for the target machine.  Try and
use the headers from your own machine and well, you might or might not
get away with it for building the compiler, but those same headers will
then be used as the standard system includes by the cross compiler you
end up with, and that would definitely be wrong.

  So what you actually need is the headers that belong with the standard
C library that you will be using on the target machine.  There are two
major possibilities here:  Gnu glibc works on workstation sized machines,
things that have full MMUs and virtual memory etc., whereas the Cygnus
newlib package does the job for embedded systems.  I'd guess you want to
use newlib; you can find it at http://sources.redhat.com/newlib/

  Now, there's still a hitch.  It is possible to build the core of the 
GCC system - the C compiler itself - without any need for a C library.
But it won't be able to build any programs, because the C library has all
the necessary bits of startup and exit code for your program, not to 
mention all those functions that you'd expect to see in stdlib.h, stdio.h,
strings.h, and so on.  And a consequence of that is that you end up not
being able to build the C++ standard library, which means that you cannot
build the C++ part of the compiler until you've first built the standard
C library.

  The way to deal with this problem is to build the compiler in two 
stages, first the C part only, then all the rest (C++ / fortran / java /
etc.), and to build the standard C library in between, using the C-only
compiler from the first stage to do so.

  So the steps look like this:

  - configure gcc using --with-includes pointing to the header files from
the C library you're planning on using with the finished crosscompiler,
and using the option --enable-languages=c, in order only to build the 
core C compiler.

  - build and install the core C compiler, using a make command that uses
the LANGUAGES environment variable to also specify C only.  (This is
allegedly redundant in 2.95.3 but I think it may not be, so it does no
harm to use both).  Your command line will be something like
       make LANGUAGES="c" all install

  - Now you go through the configure, build and install process for the
C library, in a separate build directory, according to the instructions
for the particular library you've chosen.  In the case of newlib, this
would probably be pretty much as simple as doing 

       /path/to/newlib/source/configure --target=mips-elf \
          --prefix=<must be the same as you used for gcc and binutils>
       make all install

  - Finally change back into the gcc build directory; reconfigure gcc,
this time without the --enable-languages option, and re-run the make all
install, without the LANGUAGES= option.

  And that's it; you now have a compiler and a working C library for
your target.

>> >   ld: warning: file libcpp.a ignored: unable to locate 
>archive symbol 
>> 
>>   What *exactly* is your $PATH setting?  It may be picking 
>up the wrong
>> binutils here.
>
>Here is my path:
>
>/usr/gnu/binutils-mips-elf/bin:/usr/gnu/binutils-mips-elf/mips-
>elf/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local
>/sbin:/usr/dt/bin:/usr/openwin/bin

  AHA!!!!!!

>The first entry in the path (...binutils-mips-elf/bin) is required to
>get the version mips-elf-* version of binutils.  The second entry
>(...binutils-mips-elf/mips-elf/bin) is to fix the problem mentioned in
>my first post where it was complaining about not finding the "-G"
>option to as.  Why it isn't looking for mips-elf-as, I don't know, but
>that is what it seems to be requiring.  I have tried specifying the
>target assembler on the make command line ("make AS_FOR_TARGET=..."),
>and that makes no difference.

  As you've noticed, there are indeed two versions of the cross binutils,
one with the prefix mips-elf-*, and one that lives under a mips-elf/bin
subdirectory and doesn't have any prefixes.

  Now the gcc build process does know about this.  It *will* use the
prefixed versions of the programs as long as they're in the path 
somewhere.  It doesn't need to be right at the start, as long as there
isn't anything on your system called mips-elf-as that isn't a mips cross
assembler!

  However, it's with the second part that things went wrong.  That
directory ($prefix/$target/bin) contains the cross binutils without any
prefixes.  So what's going to happen when your *native* Gcc is trying to
compile and assemble your *cross* gcc?  You got it: it's going to look
for the first file in the $PATH called 'as', which it supposes to be the
name of the native assembler, and it gets the mips cross assembler itself.
You then end up trying to assemble the cross compiler with a mips
assembler!

  The right solution is just to add the $prefix/bin dir, with the 
mips-elf-* versions of the binutils, into your path, and preferably at
the end, although it shouldn't make a difference unless you start putting
other things in there.  Although your first attempt seemed to fix the
problem, it just put it off for later.  So if you'd tried your second
fix first, and not tried the first fix at all, everything would have 
been OK.

>BTW, we are not using any OS in the system....our program runs
>directly out of cache, and is loaded by means of S-Records through the
>PMON if that makes any difference in config options we choose.

  OK; but the C standard library is not the OS, it is where the functions
like strcpy and memcmp and all those things live.  So you *do* need one,
and newlib is the one for your situation I reckon.  

  And there's one last thing I haven't told you yet (sorry!)

  When using binutils, there's a couple of little kludges you need to do
to get around some minor brokenness in the build procedure:

 1)  Add the --with-newlib option to your Gcc configure command.
 2)  Create two softlinks in the gcc-2.95.3 top level source directory,
    called 'newlib' and 'libgloss', that point at the correspondingly
    named directories in the newlib-1.9.0 source directory.

  So:

  Sort out your path by removing /usr/gnu/binutils-mips-elf/mips-
elf/bin, and moving /usr/gnu/binutils-mips-elf/bin to the end.

  Download and unpack the newlib archive.

  Create the softlinks in the gcc top level source directory.

  Configure gcc using "--with-newlib",  "--with-headers=/path/to/newlib-
1.9.0/include", and "--enable-languages=c" in addition to the other
options you are using.

  Make and install gcc using LANGUAGES=c

  Configure newlib, make and install it, using the same options as for
gcc.  (Apparently, if you were using glibc, you'd have to use --host for
the cross target rather than --target, but that's not relevant right now,
I'm only mentioning it for completeness).

  Go back to your Gcc build directory, re-run the configure command, this
time without --enable-languages, and re-run "make all install" without 
the LANGUAGES= option.


  That will either work, or it will bring you new and interesting problems
to report back here!

    cheers,
       DaveK
-- 
*** RIP: Douglas Adams. So long, and thanks for all the books. ***



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]