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] |
Angel Manchado wrote: > > That is what I'm trying to do in order to build gcc for arc-elf, > and I don't succeed either. > > > If you build from the FSF-sources, keep them separated until > > you have checked that the 'utils'-stuff (libiberty, bfd, opcodes, > > include, readline, intl etc.) doesn't differ too much. > > How do you do that? Using a different --prefix option, perhaps? I meaned that trying to combine the binutils-2.11 and gcc-2.95.3 sources shouldn't be done. However I have found out that binutils and GDB are normally quite well in sync, so combining the snapshots from the near dates shouldn't be a problem... Perhaps the GCC snapshots could also be combined with the binutils and GDB when they are dated closely, but nobody shouldn't assume this working always, ie. the libiberty, readline, bfd, intl, mmalloc subdirs being 'frozen' in the FSF sources (because their last releases can be years old in the GNU-sites...) > > I had no troubles at all when testing the build from the untouched > > binutils-2.11 sources for the 'arc-elf' target.... > > Whith which version of gcc? When binutils is in question, no target compiler is involved so you must mean the host-compiler... So I used the 'production compiler' in RedHat 6.2, the 'egcs-1.1.2'. I could try the same with gcc-2.95.3 but the host compiler really isn't the problem. I built my 'arc-elf' tools last October, and I thought I used binutils-2.10.1 then, and didn't remember any problems in the build... However I had a dim memory about some bug report on 'gnu.utils.bug' or something, so it might have been possible that I had installed fixes to 2.10.1, then patched the sources to 2.11 and now could think that I have 'untouched' sources... But I had the 2.10.1 sources still and couldn't find any fixes for ARC there... Anyway I was stupid and replaced the working binutils with the 2.11 version, expecting them to works just as well... > While trying to build gcc-2.95.3 for arc-elf with binutils-2.11, When I looked my '/usr/local/lib/gcc-lib/arc-elf', I saw the dirs '2.9-edk1.0' and '2.97' there, ie. I built the tools from the RedHat EDK and the GCC-snapshots in October... This seemed to show there being something wrong with 2.95.x... If not, I would probably have built also the '2.95.2' version then... > Therefore, I can imagine that you didn't use gcc-2.95.3 You seem to be absolutely right... So I checked gcc-2.95.3 now and the build crashed when trying to compile the 'lib1funcs.asm', ie. 'libgcc1.S', line 40, saying: undefined pseudo op '.cpu' It really was undefined in the new 'as'... I had built the previous binutils in October, (remembering it being the 2.10.1) and now the update to 2.11 had broken something, the new 'as' didn't recognize this any more. So my decision was to go back to use binutils-2.10.1... When trying to build these, the build gave warnings from LITTLE_ENDIAN and BIG_ENDIAN redefinitions in 'gas/config/tc-arc.h', then crashed in 'gas/config/tc-arc.c'... This showed that I really hadn't used 2.10.1 and it proved out that I had used the 'fixed binutils-2.10', ie. the '20000704'-snapshots (when comparing this to 2.10, I found several useful bugfixes done but generally it was 'binutils-2.10', and even the 2.10.1 release missed some of these bugfixes...). Attached are the diffs between 2.10.1 and 20000704 for the 'tc-arc'- stuff in 'gas/config'. When patching with these, I then got 'binutils-2.10.1' built for 'arc-elf'... The 2.11 seemed to differ radically from 2.10.1/20000704 what becomes to the 'gas/config/tc-arc.*', and when the 'pseudo op .cpu' problem still existed, I decided to use the 20000704-patched binutils-2.10.1 when continuing to try the gcc-2.95.3 build... Angel, you must have met the '.cpu' problem when using binutils-2.11, but is there somewhere a solution to this? Then I met the same "junk at end of line: 'ld blink,[fp,4]'" problem but found a different solution to this... The same file in the 'gcc-2.9-edk-20000221'-sources had seemingly a fix installed, the gcc-3.0 snapshots too, the diff is also attached here... After having met this many bugs in binutils-2.1[01] and gcc-2.95.3, I would strongly consider building at least one GCC more, I myself tried also the current '20010521' gcc-3.0 prerelease/snapshots... They had the '.cpu' pseudo op in the 'lib1funcs.asm' and crashed with something else with binutils-2.10.1... So the problem seems to be uncompatability in larger scale, the GCC- sources need binutils which understands the ARC-asm parts in the sources. I would see two possible 'in sync' solutions: 1. To use gcc-2.95.3 and the patched binutils-2.10.1. The binutils-2.11 will crash with the '.cpu'-pseudo op the compiler generates and which is present in the 'lib1funcs.asm'. But perhaps there is a solution and binutils-2.11 can be used. 2. To use the gcc-3.0 snapshots and the binutils snapshots (I will check this combination), hoping that they have added the '.cpu' recognition back... > On the other hand, please, can you tell me exactly which configure > options you used, or what is wrong with the following? > > --host=i686-pc-linux-gnu \ > --target=arc-unknown-elf \ The only 'cosmetic' issues are these: The Unix-idea is to use short names and 'arc-elf' would fit into this, while the 'arc-unknown-elf' doesn't. If I don't know what to put to the 'manufacturer', I (normally don't and) leave it out, for me 'nothing' means the 'unknown'. The 'unknown' could be replaced with a name which tells about the default target... If there were a evaluation board named 'archie' or 'bunker' and the toolset would produce executables for it as default, a target name like 'arc-archie-elf' or 'arc-bunker-elf' could then be proper... Anyway the purpose for the target name is to fit into the templates in various 'configure*' or 'config.*' files... The second issue is that if you are going to run the tools on Pentium-I's, AMDs etc., the 'i686' may cause the tools being compiled for only Pentium-II or newer hosts and they will not run elsewhere... Using the 'i586' nowadays doesn't forget those 'poor cousins' having 120 - 233 MHz Pentiums still... The RedHat-EDK distribution had as its 'x86' library a Pentium-II optimized glibc and someone then accused RedHat being a liar when talking about 'x86-support', after vainly trying the generated executables on a i486/Linux target board... Someone recently also wondered why Cygwin doesn't work on AMD Duron's, and the 'i686' in the current host name in the Cygwin- distribution came first into my mind... Should the AMD Durons be i686/PentiumPro/Pentium-II-compatible ? Is Cygwin really this much in the Wintel-wagons? (I remember the message being in the 'gnu.gcc.help'-newsgroup) If you really use the toolset only in your own 'i686', this CPU- name isn't a problem... When a Sun-server crashes mystically, the phenomen can always be explained by the 'sunspots' causing it, but what it is when Cygwin crashes mystically on AMD Duron ? Amd or Intel, Duron or Sextium - that's the big question... > Finally, in an earlier mail to the crossgcc mailing list I have explained > that the error messages for me now seem to be related with inexistent C > library headers. Any idea on this? If you use newlib and have preinstalled the headers from 'newlib/libc/include' into your '$prefix/$target/include' following the instructions in the "Using and Porting the GNU Compiler Collection (GCC)", which you surely have already installed into your system with the native GCC binaries, and have the manual sources in the '.texi'- files and possibly also preprocessed '.info' files in the 'gcc' subdir, there shouldn't be any problems with finding the headers. The 'gcc/INSTALL' should also have this same info. After reading these and if not understanding something or having troubles in something, the Cross-GCC FAQ is there to help. It is important to get the basic GCC docs to be ok first, and they really could be better, the GCC manual still talks about things which were some limits years ago (like that 'libgcc.a' for MIPS can be produced only a MIPS-system...), the $prefix is not mentioned but the '/usr/local' is used and so on... The Chapter/section for the cross-gcc instructions is (can this be a surprise?) the "Installation / Cross-Compiler". This is how I have made cross-gccs for years, but someone could try to convert me to copy the target headers first into some temporary directory, then to point to them using the '--with-headers=', then after the installation to copy them from the 3rd-party '$prefix/$target/sys-include' into the final '$prefix/$target/include'. As hard I have tried this new 'recommendation', this kind of 'support the entropy' hasn't yet gone into my stupid head... On the contrary, I have fixed the main 'Makefile.in' or/and the 'gcc/cross-make' to look into the '$prefix/$target/include' for the headers to fix, just as the GCC-manual says the GCC-build does... (Please see the definition for GCC_INCLUDE_DIR in the GCC-manual) IMHO the jobs to be done before starting to build GCC are the critical ones in avoiding problems during the build ("Be smart, never start"), the target headers really will be needed for libgcc, so they must be preinstalled ... But if you find out that you forgot to do this, just do it when the error messages arrive, it is not too late even then, just install the headers and start the make again and be happy... So the obvious reason for the missing headers normally is that they really (and surprisingly!) are missing from $prefix/$target/include, this may sound really weird but such things happen all the time, just follow this list... BTW, the 'make all-gcc' is the command to get GCC built, not 'make'. If you want to produce only the C and C++ compilers, then write: make all-gcc LANGUAGES="c c++" and then make install-gcc LANGUAGES="c c++" to install the C and C++ compilers, then build newlib with the installed GCC. And finally continue with the libiberty and libstdc++ builds. Please note that this was generic info, the ARC-support doesn't include any startup-routine (crt0.o) or any other target board support (glue lib) in newlib, so getting libiberty and libstdc++ built for 'arc-elf' may be tough... Ok, my question is: Is there any example target board support stuff available for ARC? Anyone implementing simulator for it and for GDB? Having at least some kind of dummy startup would enable one to build libiberty and libstdc++ too... Richard Kenner seems to be the maintainer of the GCC/ARC-port, but Peter Targett, <peter.targett@arccores.com> seems to have maintained the 'gas' port in binutils... The latter could know something about ARC-assembly and could already have some 'dummy' crt0.S for ARC... Has anyone asked him? Cheers, Kai
*** initfini.c Wed Jan 27 03:43:01 1999 --- /home2/src/gcc-2.9-edk1.0/gcc/config/arc/initfini.c Wed Oct 11 17:39:08 2000 *************** *** 10,15 **** --- 10,24 ---- the Free Software Foundation; either version 2, or (at your option) any later version. + In addition to the permissions in the GNU General Public License, the + Free Software Foundation gives you unlimited permission to link the + compiled version of this file into combinations with other programs, + and to distribute those combinations without any restriction coming + from the use of this file. (The General Public License restrictions + do apply in other respects; for example, they cover modification of + the file, and distribution when not linked into a combine + executable.) + GNU CC is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the *************** *** 20,31 **** the Free Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ - /* As a special exception, if you link this file with files - compiled with GCC to produce an executable, this does not cause - the resulting executable to be covered by the GNU General Public License. - This exception does not however invalidate any other reasons why - the executable file might be covered by the GNU General Public License. */ - /* Declare a pointer to void function type. */ typedef void (*func_ptr) (void); --- 29,34 ---- *************** *** 138,144 **** asm ("\n\ .section .init\n\ ! bl.nd __do_global_ctors\ ld blink,[fp,4]\n\ j.d blink\n\ ld.a fp,[sp,16]\n\ --- 141,147 ---- asm ("\n\ .section .init\n\ ! bl.nd __do_global_ctors\n\ ld blink,[fp,4]\n\ j.d blink\n\ ld.a fp,[sp,16]\n\
------ 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] |