Re: Re: cross compile for powerpc-eabi problem.

[Liu Wensheng <wenshengliu at 263 dot net>]

hi,

i have make a complete toolchain works using cygwin on win2000, targeting to 
powerpc, thanks for your kindly help.:-)

>Liu Wensheng wrote:
>> 
>> i use a cygwin1.3.5 on win2000 to build a toolchain for powerpc target.
>> on host i use :
>
> My opinion has always been that RedHat has a much better and much more
>Unix-like build environment for producing Cygwin-binaries on a PC : their
>"Redhat Linux", provided with a Linux-x-Cygwin cross-toolset. So helping
>people "to shoot into their own legs" by couraging them to use Cygwin as
>the build system is not a bright idea... Some tasks become very hard in
>a system which for instance cannot see a difference between 'Gnu.java'
>and 'gnu.java'. The GNU tools are thought to be built under a real Unix-
>system...
>
> The speed differences between Linux and NT/Cygwin on the same PC are
>about 4 - 8 fold, so a one-hour build under Linux may become a build
>lasting the whole workday. If trying to get any productivity (4 or more
>toolsets per day), not using Cygwin is a must...
this is really a problem. Surely, Redhat Linux is preferable in nearly every
aspects compared to cygwin. But my initial intention is for the eas of 
host side embedded developer. the target is aimed at not too many platform.
for example PPC. so i can group the tools together to run on windows host.
just as users use Visual C. do you think this is applicable? and give me
some suggestions.
My next job is to port eCos to my 8240 boards. As my wish to bring convenience 
to developer mentioned above, i should do all this work on win2000 .(if you want to 
let others to go this way, why not you cut the way out first? :-) ....).
but i have met problem when compiling eCos1.3.1. It alerts me that i will meet
many similar questions, i am stubbed into these questions, i will gradually 
lost the target of "Porting Ecos" task. so i want to change to Redhat platform.
>
> And when understanding to use for instance Linux as the 'Unix-like'
>build-system, not using Cygwin even as the run-time system comes easily
>into one's mind. The Mingw-alternative which uses the native CRTDLL.DLL
>or MSVCRT.DLL run-time C-libraries may then be the better and more
>Windows-like environment. Even Win3.1x/Win32s is then possible as the
>run-time host for GUI-only apps like Insight-GDB... Windows is the best
>Windows, a real Unix the best Unix...
cygwin , Mingw, you think which is more suitbable for my needs?
>
> So I advice you to ask from the Windows-nerds about the peculiarities of
>the 'Cygwin-Unix' on the Cygwin-maillist, if needing any help with Cygwin
>as a build system...
>
> Your problems here however are quite generic, so...
>
>> the source file is :
>> binutils-2.11.2
binutils-2.10.1
>> gcc-2.95.1
>> newlib-1.9.0
>> gdb-5.0
>> 
>> after setting up the target and prefix environment variables,
>
> Why any extra permanent environment settings?  Only a
>
> .../configure --prefix=my_prefix --host=my_host --target=my_target
>
>should be enough...
>
>> i do as the instructions.
>
> What instructions?
>
>> after i successfully make and install the binutils,
the binutils's version is must up to date, i can cause problem.
my successful version is changed to binutils2.10.1 . 
gcc2.95.3--  newlib1.9.0 --gdb5.1
>
> The target headers, where are they now?
>
> The official 'instructions' in the Stallman's "Using and Porting the GNU
>Compiler Collection (GCC)", ie. the 'GCC Manual', clearly say that the
>target headers and libs (if available) should be preinstalled into the
>'/usr/local/$target/include' and '.../lib', when using the default $prefix,
>'/usr/local' (ie. not defining any kind of own $prefix). A simple logic
>then says that the '$prefix/$target/include' is the preinstall place for
>the target headers... ("Installation / Cross-Compiler")
>
>The newlib-1.9.0 sources definitely have the target headers in the:
>
>   newlib/libc/include
>
>and it is a 'piece of cake' to copy them with a single command into their
>final place. No prebuilt libs of cources, but after doing the
>
>  make all-gcc ; make install-gcc
this is the stage of making "bootstrap gcc" as explained in the link.
http://crossgcc.billgatliff.com/crossgccfaq/t1.html

>
>in order to build and install GCC, building and installing newlib is
>possible. Then the extra 'libiberty' and 'libstdc++' libs in the GCC
>sources can be tried...
>
> Although you have a GCC, perhaps you have thought that the GCC-manual is
>unnecessary. But it isn't... A SAQ ("Seldom Asked Question") is the "Where
>in the hell is the GCC Manual?"... I have always wondered why the manual is
>not interesting... I have a WinHelp-one, produced with 'makertf' and 'HC31.EXE'
>from the source 'gcc.texi', partly under Linux, partly under Windows, and
>used under Windows, but the net is full of PDF, PS, HTML etc. versions...
>The GNUPro-docs (PDF) from RedHat are quite popular for the GNU tools.
>
>  http://www.redhat.com/support/manuals
>
>> i go on to second step to compile gcc. but when compiling, the following
>> error messages occurs:
>> 
>> _muldi3
>> /../gcc-2.95.1/gcc/libgcc2.c:41 stdlib.h: No such file or directory
>> /../gcc-2.95.1/gcc/libgcc2.c:42 unistd.h: No such file or directory
>> 
>> when i examine the file libgcc2.c:
>> #ifndef inhibit_libc
>> /* fixproto guarantees these system headers exitst. */
>> #include <stdlib.h>
>> #include <unistd.h>
>> #endif
>
> The target headers are quite necessary for compiling 'libgcc.a' right, so the
>'inhibit_libc' doesn't help... Anyway there aren't problems in finding these
>headers in the newlib sources.
>
> Another issue then are the new 'relational search paths' in gcc-2.95.[123] and
>only the latest, gcc-2.95.3, handles them right, ie. precreating the install
>directory:
>
>   $prefix/lib/gcc-lib/$target/2.95.3
>
>The 2.95.1 and 2.95.2 don't precreate their equivalents, so this error comes
>whether the target headers are or are not in the 'search directory':
>
>   $prefix/lib/gcc-lib/$target/2.95.x/../../../../$target/include
>
>ie. in the
>
>   $prefix/$target/include
>
>While a human being sees these two being the same and can find the headers,
>although there are unexisting parts in the path, the C-function in 'cpp'
>cannot do this...
>
> If you look with the '.../gcc/xgcc -print-search-dirs', you will see the search paths
>for the target GCC...
>
>> probably this is the libc or glibc problem, what shall do. when compiling the source
>> , i think the header file needed is to the host(cygnus) not to the target(powerpc).
>> and the two file resides in /usr/include.
>
> Producing a library for the target of course needs the headers for the target, not
>for the host. The C-headers aren't 'generic', although newlib is the base library in
>Cygwin too...
>
>Cheers, Kai

Regards

diego.
            wenshengliu@263.net



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