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]

Re: Re : Fw: building cross-compiler for aix4.3


윤형수 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]