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] |
>-----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] |