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] |
Other format: | [Raw text] |
윤형수 wrote: > the following item is ommited.. > --with-local--prefix=$PREFIX/$TARGET/bin > > The item of above is include rs6000-ibm-aix4.3-as, ar, ld.... The build should succeed without this because the $PREFIX/$TARGET/bin will be searched always automatically, and before going to search 'as', 'ld' etc. from PATH. GCC NEVER uses those '$target-<tool>' files, they are for humans meanwhile GCC is not yet an program with AI like features like HAL. If it would be that, it would be called as FBB (a step forwards from GCC), and being an abbreviation for "FSF's Bad Boy", always telling weird jokes like "C compiler cannot create executables" when the stupid user coming from the Windoze world yet doesn't know what a C compiler should do or shouldn't do -- everyone knows that a C compiler doesn't ever create executables, the linker called as 'ld' does this task. Hmmm, but it already tells stupid jokes like this, so after all the code added to it in order to get more intelligency into its optimizations and such... Huh... But originally GCC was only a stupid program and used only other tools with their base names :-) Thinking GCC being just as human as one is, and therefore using the toolnames one uses, is a quite common misunderstanding. A sure way to be released from this bullshitism and to learn how things are working is to use the well-known command (applied to this case) : rs6000-ibm-aix-gcc -print-search-dirs and seeing that the '$prefix/bin' isn't in these paths. It may be in PATH but who would put alien 'as', 'ld', 'nm', 'ar', 'ranlib' etc. in their base names into one's '$prefix/bin'? >> I'm trying to build a cross-compiler for aix4-3../configure --host=$HOST >> --target=$TARGET --prefix=$PREFIX --enable-languages=c >> --with-headers=$PREFIX/$TARGET/include --with-libs=$PREFIX/$TARGET/lib >> --without-threads >> >> and I have an error. Here are the last lines: >> >> -I -I. -I./ -I./../include -mcpu=power -DL_divdi3 -c >> ./libgcc2.c -fexceptions -fnon-call-exceptions -o libgcc/power/_divdi3.o >> /tmp/ccL8Ds3R.s: Assembler messages: >> /tmp/ccL8Ds3R.s:661: Error: Unrecognized opcode: `mfcr' I told this privately to Costinel but haven't got any reply or seen a bug report or questions in the gcc@gcc.gnu.org list, so maybe someone here knows something about this... As seen the '-mcpu=power' is used when trying to produce libgcc for the POWER/RIOS1 (RS/6000) variation. The default is the '-mcpu=common'. The GCC build tries also always create a multilib using '-pthread' which should clash with the used '--without-threads', this option defines '-D_THREAD_SAFE' and such, so it could be wrong to build this multilib if not needing threads. The second multilib then is for the '-mcpu=power', then comes '-mcpu=powerpc' and last '-maix64'. Maybe nothing of these will be required. And trying to build to the second crashes with the 'mfcr' opcode not approved by the GNU as when getting the option '-mpwr' (create code for POWER/RIOS1). Either this opcode should be accepted by the assember (bug there), or GCC shouldn't create it with '-mcpu=power' (bug there). The earlier gcc-3.3.5 release creates it too, not only the gcc-3.4 used in this case, for curiousness I tried them both... Anyone seen anything about this? Should the 'mfcr' be accepted by the assembler as being a legal opcode for POWER? Or are somewhere patches for GCC (3.3 and 3.4) which will disable generating it with '-mcpu=power'? The assembler I tried was from the brand new 'Linux binutils-2.15.94.0.2.2'... When not having those original AIX 4.3 C libraries, I substituted them with the newlib headers and so became aware about the problem with the '-pthread' too, #including the 'gcc/gthr-posix.h' instead of 'gcc/gthr-single.h' expects the target's own 'pthread.h' to define types which the newlib one doesn't have... Of course the original 'pthread.h' in the AIX 4.3 headers defines these but still generating 'thread support' with '--without-threads' sounds being wrong. Generally the 'rs6000-ibm-aix4.3' target may require editing the target Makefile-fragment, 'gcc/config/rs6000/t-aix43', in order to set what multilibs one wants and doesn't want. I removed those for '-pthread' and '-mcpu=power' and then the rest succeeded ('-mcpu=powerpc', '-maix64'). ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |