Re: Simple question

Re: Simple question

[Desmond Cheung]

>> after I have got the gcc port for our own processor,
>> do I need binutils and newlib installed for this
>> processor as well? if yes, does that mean I have to
>> write the ports for them?
>
>Yep
>
>-- 
>Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
>Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
>CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
>Free Software Evangelist    *Please* write to mailing lists, not to me

Thanks.

Where can I get help for writing new ports for binutils/newlib?

Desmond

Re: simple question

[Andreas Tobler]

Ramin NIkaeen wrote:

> --------------------------------------------------------------------------------------------
> COMPILER OUTPUT
> --------------------------------------------------------------------------------------------
> jupiter.goldline.net:/home/rnikaeen/test>gcc c.cpp
> 

How about g++ c.cpp ?

Andreas

Re: simple question

[Gabriel Dos Reis]

"Ramin NIkaeen" <Rnikaeen@goldline.net> writes:

| jupiter.goldline.net:/home/rnikaeen/test>gcc c.cpp

The GNU C++ compiler is named "g++".  Try g++ c.cpp.

-- Gaby

simple question

[Ramin NIkaeen]

Valued Colleagues,

I have built and installed gcc-3.3 on RedHat linux 7.2 but I am having 
problems with the compiler. For several days I have been trying to
figure out the cause of the problem but I have not had much success.

Below is a small sample program and the compiler error that I get.

If someone can give me any pointers as to the cause of the problem,
I will be very thankful.

best regards

ramin


--------------------------------------------------------------------------------------------
TEST PROGRAM
--------------------------------------------------------------------------------------------
jupiter.goldline.net:/home/rnikaeen/test>more c.cpp

#include <iostream>
#include <string>
using namespace std;

int main()
{
    cerr << "Enter your name ";

    return 0;
}

--------------------------------------------------------------------------------------------
COMPILER OUTPUT
--------------------------------------------------------------------------------------------
jupiter.goldline.net:/home/rnikaeen/test>gcc c.cpp
/tmp/cc5AisQc.o: In function `main':
/tmp/cc5AisQc.o(.text+0x1b): undefined reference to `std::cerr'
/tmp/cc5AisQc.o(.text+0x20): undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)'
/tmp/cc5AisQc.o: In function `__static_initialization_and_destruction_0(int, int)':
/tmp/cc5AisQc.o(.text+0x49): undefined reference to `std::ios_base::Init::Init[in-charge]()'
/tmp/cc5AisQc.o(.text+0x64): undefined reference to `std::ios_base::Init::~Init [in-charge]()'
/tmp/cc5AisQc.o(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
collect2: ld returned 1 exit status

--------------------------------------------------------------------------------------------
gcc VERSION
--------------------------------------------------------------------------------------------
jupiter.goldline.net:/home/rnikaeen/test>which gcc 
/usr/local/bin/gcc


jupiter.goldline.net:/home/rnikaeen/test>gcc -v
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3/specs
Configured with: ./configure 
Thread model: posix
gcc version 3.3

--------------------------------------------------------------------------------------------
RedHat Linux VERSION
--------------------------------------------------------------------------------------------
jupiter.goldline.net:/usr/local/publicVoiceXML/speech_tools-1.2.3>uname -v
#1 Thu May 29 08:32:50 EDT 2003
jupiter.goldline.net:/usr/local/publicVoiceXML/speech_tools-1.2.3>uname -a
Linux jupiter.goldline.net 2.4.20-18.7 #1 Thu May 29 08:32:50 EDT 2003 i686 unknown
jupiter.goldline.net:/usr/local/publicVoiceXML/speech_tools-1.2.3>

Re: simple question

[cowen]

Sorry -- this is an inappropriate list for this question.

I'll take it to gcc-help.

Again, my apologies.

C.

At 09:51 AM 11/27/2002 -0800, cowen wrote:
>Hello all.
>
>This is perhaps a stupid newbie question. I'm implementing gammln, one of 
>the numerical recipes
>(available from 
>http://www.ulib.org/webRoot/Books/Numerical_Recipes/bookcpdf.html, chapter 6).
>
>gammln computes the natural log of the gamma function, which should allow 
>one to compute
>interesting things, like factorials.
>
>Here's the code:
>
>***************** utils.h **************************************
>
>#ifndef UTILS_H
>#define UTILS_H
>
>double gammln ( double xx );
>
>#endif // UTILS_H
>
>**************** utils.c **************************************
>
>#include <math.h>
>
>double gammln ( double xx )
>{
>         int j;
>         double x,y,tmp,ser;
>         static double cof[6] = {
>                 76.18009172947146,
>                 -86.50532032941677,
>                 24.01409824083091,
>                 -1.231739572450155,
>                 0.1208650973866179e-2,
>                 -0.5395239384953e-5
>         };
>
>         y = x = xx;
>         tmp  = x + 5.5;
>         tmp -= ( x + 0.5 ) * log( tmp );
>         ser = 1.000000000190015;
>
>         for ( j = 0; j <= 5; j++ )
>                 ser += cof[j]/++y;
>
>         return -tmp + log( 2.5066282746310005 * ser/x );
>}
>
>**************************** test.c 
>*******************************************
>#include <stdio.h>
>#include <math.h>
>#include "utils.h"
>
>int main ()
>{
>     int i;
>     for ( i = 1; i <= 20; i++ ) {
>         printf( "%3d!: %.0f\n", i, exp( gammln(  i + 1.0 ) ) );
>     }
>     return 0;
>}
>
>Here's the output:
>
>   1!: 1
>   2!: 2
>   3!: 6
>   4!: 24
>   5!: 120
>   6!: 720
>   7!: 5040
>   8!: 40320
>   9!: 362880
>  10!: 3628800
>  11!: 39916800
>  12!: 479001600
>  13!: 6227020800
>  14!: 87178291200
>  15!: 1307674368006
>  16!: 20922789888126
>  17!: 355687428098601
>  18!: 6402373705783494
>  19!: 121645100410059440
>  20!: 2432902008204834800
>
>
>**********************************************************
>
>This is obviously wrong. (15! is evidence enough.)
>
>The algorithm, however, is correct -- I lifted it
>directly from the numerical recipe, and I'm fairly confident that
>the authors have not made an error. I've built and run the example
>on different platforms. The result is always the same.
>
>Here is a primitive Makefile:
>
>all: utils.o test.o test.exe
>
>%.o: %.c
>         gcc -c -g -Wall -o $@ $^
>
>test.exe:
>         gcc -o $@ -g -Wall utils.o test.o
>
>
>Any suggestions would be most helpful.
>
>Thanks in advance,
>
>Charles.
>
>

simple question

[cowen]

Hello all.

This is perhaps a stupid newbie question. I'm implementing gammln, one of 
the numerical recipes
(available from 
http://www.ulib.org/webRoot/Books/Numerical_Recipes/bookcpdf.html, chapter 6).

gammln computes the natural log of the gamma function, which should allow 
one to compute
interesting things, like factorials.

Here's the code:

***************** utils.h **************************************

#ifndef UTILS_H
#define UTILS_H

double gammln ( double xx );

#endif // UTILS_H

**************** utils.c **************************************

#include <math.h>

double gammln ( double xx )
{
         int j;
         double x,y,tmp,ser;
         static double cof[6] = {
                 76.18009172947146,
                 -86.50532032941677,
                 24.01409824083091,
                 -1.231739572450155,
                 0.1208650973866179e-2,
                 -0.5395239384953e-5
         };

         y = x = xx;
         tmp  = x + 5.5;
         tmp -= ( x + 0.5 ) * log( tmp );
         ser = 1.000000000190015;

         for ( j = 0; j <= 5; j++ )
                 ser += cof[j]/++y;

         return -tmp + log( 2.5066282746310005 * ser/x );
}

**************************** test.c *******************************************
#include <stdio.h>
#include <math.h>
#include "utils.h"

int main ()
{
     int i;
     for ( i = 1; i <= 20; i++ ) {
         printf( "%3d!: %.0f\n", i, exp( gammln(  i + 1.0 ) ) );
     }
     return 0;
}

Here's the output:

   1!: 1
   2!: 2
   3!: 6
   4!: 24
   5!: 120
   6!: 720
   7!: 5040
   8!: 40320
   9!: 362880
  10!: 3628800
  11!: 39916800
  12!: 479001600
  13!: 6227020800
  14!: 87178291200
  15!: 1307674368006
  16!: 20922789888126
  17!: 355687428098601
  18!: 6402373705783494
  19!: 121645100410059440
  20!: 2432902008204834800


**********************************************************

This is obviously wrong. (15! is evidence enough.)

The algorithm, however, is correct -- I lifted it
directly from the numerical recipe, and I'm fairly confident that
the authors have not made an error. I've built and run the example
on different platforms. The result is always the same.

Here is a primitive Makefile:

all: utils.o test.o test.exe

%.o: %.c
	gcc -c -g -Wall -o $@ $^

test.exe:
	gcc -o $@ -g -Wall utils.o test.o


Any suggestions would be most helpful.

Thanks in advance,

Charles.

simple question

[cowen]

Hello all.

This is perhaps a stupid newbie question. I'm implementing gammln, one of 
the numerical recipes
(available from 
http://www.ulib.org/webRoot/Books/Numerical_Recipes/bookcpdf.html, chapter 6).

gammln computes the natural log of the gamma function, which should allow 
one to compute
interesting things, like factorials.

Here's the code:

***************** utils.h **************************************

#ifndef UTILS_H
#define UTILS_H

double gammln ( double xx );

#endif // UTILS_H

**************** utils.c **************************************

#include <math.h>

double gammln ( double xx )
{
         int j;
         double x,y,tmp,ser;
         static double cof[6] = {
                 76.18009172947146,
                 -86.50532032941677,
                 24.01409824083091,
                 -1.231739572450155,
                 0.1208650973866179e-2,
                 -0.5395239384953e-5
         };

         y = x = xx;
         tmp  = x + 5.5;
         tmp -= ( x + 0.5 ) * log( tmp );
         ser = 1.000000000190015;

         for ( j = 0; j <= 5; j++ )
                 ser += cof[j]/++y;

         return -tmp + log( 2.5066282746310005 * ser/x );
}

**************************** test.c *******************************************
#include <stdio.h>
#include <math.h>
#include "utils.h"

int main ()
{
     int i;
     for ( i = 1; i <= 20; i++ ) {
         printf( "%3d!: %.0f\n", i, exp( gammln(  i + 1.0 ) ) );
     }
     return 0;
}

Here's the output:

   1!: 1
   2!: 2
   3!: 6
   4!: 24
   5!: 120
   6!: 720
   7!: 5040
   8!: 40320
   9!: 362880
  10!: 3628800
  11!: 39916800
  12!: 479001600
  13!: 6227020800
  14!: 87178291200
  15!: 1307674368006
  16!: 20922789888126
  17!: 355687428098601
  18!: 6402373705783494
  19!: 121645100410059440
  20!: 2432902008204834800


**********************************************************

This is obviously wrong. (15! is evidence enough.)

The algorithm, however, is correct -- I lifted it
directly from the numerical recipe, and I'm fairly confident that
the authors have not made an error. I've built and run the example
on different platforms. The result is always the same.

Here is a primitive Makefile:

all: utils.o test.o test.exe

%.o: %.c
	gcc -c -g -Wall -o $@ $^

test.exe:
	gcc -o $@ -g -Wall utils.o test.o


Any suggestions would be most helpful.

Thanks in advance,

Charles.

Re: Simple question.

[Sir Ace]

Actually I have got it built working already, the --build flag was my
problem.

Thanks.


On Tue, 8 Jan 2002, M. R. Brown wrote:

> * Sir Ace <chandleg@wizardsworks.org> on Wed, Jan 02, 2002:
> 
> > 
> >   I am having a very rough time trying to figure out something do to the
> > poor documentation on gcc.  What I need to do is build a native compiler
> > with a cross compiler.
> > My host platform is x86, the target is Hitachi sh-4.
> > 
> > I have built and tested the cross compiler, it works great.
> > I can not get the damn thing to build a native compiler for the sh-4
> > it keeps failing when it tries to execute things during the make.
> > 
> > Here is what I am doing, Can you please tell me where I am messing up?:
> > 
> > export TARGET=sh4-linux;export PREFIX=/daydream/usr/local/; \
> > export PATH=${PATH}:${PREFIX}/bin;export ROOT=/daydream; \
> > export CC=sh4-linux-gcc;export CXX=sh4-linux-gcc
> > 
> > cd /usr/src/dreamcast/
> > mkdir build-gcc
> > cd build-gcc
> > 
> > ../gcc-3.0.1/configure --target=$TARGET --prefix=$PREFIX \
> > --disable-shared --host=$TARGET --enable-languages=
> > 
> 
> --host isn't supposed to be there.
> 
> Is this the bootstrap compiler (used to build glibc or another C library),
> or the final C/C++ compiler?
> 
> Do the instructions at http://linuxdevices.com/articles/AT7466555948.html
> clarify things a bit?
> 
> M. R.
> 

Re: Simple question.

[M. R. Brown]

[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]

* Sir Ace <chandleg@wizardsworks.org> on Wed, Jan 02, 2002:

> 
>   I am having a very rough time trying to figure out something do to the
> poor documentation on gcc.  What I need to do is build a native compiler
> with a cross compiler.
> My host platform is x86, the target is Hitachi sh-4.
> 
> I have built and tested the cross compiler, it works great.
> I can not get the damn thing to build a native compiler for the sh-4
> it keeps failing when it tries to execute things during the make.
> 
> Here is what I am doing, Can you please tell me where I am messing up?:
> 
> export TARGET=sh4-linux;export PREFIX=/daydream/usr/local/; \
> export PATH=${PATH}:${PREFIX}/bin;export ROOT=/daydream; \
> export CC=sh4-linux-gcc;export CXX=sh4-linux-gcc
> 
> cd /usr/src/dreamcast/
> mkdir build-gcc
> cd build-gcc
> 
> ../gcc-3.0.1/configure --target=$TARGET --prefix=$PREFIX \
> --disable-shared --host=$TARGET --enable-languages=
> 

--host isn't supposed to be there.

Is this the bootstrap compiler (used to build glibc or another C library),
or the final C/C++ compiler?

Do the instructions at http://linuxdevices.com/articles/AT7466555948.html
clarify things a bit?

M. R.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Simple question.

[Alexandre Oliva]

On Jan  2, 2002, Sir Ace <chandleg@wizardsworks.org> wrote:

> ../gcc-3.0.1/configure --target=$TARGET --prefix=$PREFIX \
> --disable-shared --host=$TARGET --enable-languages=c

You failed to specify --build here, and --build defaults to --host, so
configure doesn't know you want to build a native (host-x-host)
compiler on a machine other than host.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Simple question.

[Sergey Ostrovsky]

mike stump wrote:

> > Date: Wed, 2 Jan 2002 15:06:43 -0800 (PST)
> > From: Sir Ace <chandleg@wizardsworks.org>
> > To: gcc@gnu.org
>
> > I am having a very rough time trying to figure out something do to
> > the poor documentation on gcc.  What I need to do is build a native
> > compiler with a cross compiler.  My host platform is x86, the target
> > is Hitachi sh-4.
>
> > I have built and tested the cross compiler, it works great.
> > I can not get the damn thing to build a native compiler for the sh-4
> > it keeps failing when it tries to execute things during the make.
>
> > Here is what I am doing, Can you please tell me where I am messing up?:
>
> > ../gcc-3.0.1/configure --target=$TARGET --prefix=$PREFIX \
> > --disable-shared --host=$TARGET --enable-languages=c
>
> What part of the doc (I'll quote it below) was unclear?  I think you
> missed the --build flag.
>
> You either need that, or you need an a.out sh executor/emulator
> strapped into your OS (yes, you can do this on linux).
>
> @section Configure Terms and History
> @cindex configure terms
> @cindex canadian
>
> This section is not instructions for building GCC.  If you are trying to
> do a build, you should first read @uref{http://gcc.gnu.org/install/} or
> whatever installation instructions came with your source package.
>
> The configure and build process has a long and colorful history, and can
> be confusing to anyone who doesn't know why things are the way they are.
> While there are other documents which describe the configuration process
> in detail, here are a few things that everyone working on GCC should
> know.
>
> There are three system names that the build knows about: the machine you
> are building on (@dfn{build}), the machine that you are building for
> (@dfn{host}), and the machine that GCC will produce code for
> (@dfn{target}).  When you configure GCC, you specify these with
> @option{--build=}, @option{--host=}, and @option{--target=}.
>
> Specifying the host without specifying the build should be avoided, as
> @command{configure} may (and once did) assume that the host you specify
> is also the build, which may not be true.
>
> If build, host, and target are all the same, this is called a
> @dfn{native}.  If build and host are the same but target is different,
> this is called a @dfn{cross}.  If build, host, and target are all
> different this is called a @dfn{canadian} (for obscure reasons dealing
> with Canada's political party and the background of the person working
> on the build at that time).  If host and target are the same, but build
> is different, you are using a cross-compiler to build a native for a
> different system.  Some people call this a @dfn{host-x-host},
> @dfn{crossed native}, or @dfn{cross-built native}.  If build and target
> are the same, but host is different, you are using a cross compiler to
> build a cross compiler that produces code for the machine you're
> building on.  This is rare, so there is no common way of describing it
> (although I propose calling it a @dfn{crossback}).
>
> If build and host are the same, the GCC you are building will also be
> used to build the target libraries (like @code{libstdc++}).  If build and host
> are different, you must have already build and installed a cross
> compiler that will be used to build the target libraries (if you
> configured with @option{--target=foo-bar}, this compiler will be called
> @command{foo-bar-gcc}).
>
> In the case of target libraries, the machine you're building for is the
> machine you specified with @option{--target}.  So, build is the machine
> you're building on (no change there), host is the machine you're
> building for (the target libraries are built for the target, so host is
> the target you specified), and target doesn't apply (because you're not
> building a compiler, you're building libraries).  The configure/make
> process will adjust these variables as needed.  It also sets
> @code{$with_cross_host} to the original @option{--host} value in case you
> need it.

Man, it worth to read _every_ message on this list just to spot a gem like this
one !
Thanks !

Re: Simple question.

[Sir Ace]

It only took forever and a day to get to today, but thanks to you guys:

../gcc-3.0.1/configure --target=$TARGET --prefix=$PREFIX --disable-shared
--host=$TARGET -build=i386-slackware-linux --enable-languages=c,cpp
--disable-shared

{edit makefile for staticness} 

make
make install

root@meteor:/usr/src/dreamcast/build-gcc# !file
file /daydream/usr/local/bin/gcc
/daydream/usr/local/bin/gcc: ELF 32-bit LSB executable, Hitachi SH,
version 1, statically linked, not stripped
root@meteor:/usr/src/dreamcast/build-gcc#

Thanks a ton!!!!

Re: Simple question.

[Sir Ace]

I swear, I never saw this before.....

Ever...   really.
{grin}

> What part of the doc (I'll quote it below) was unclear?  I think you
> missed the --build flag.
> 
> You either need that, or you need an a.out sh executor/emulator
> strapped into your OS (yes, you can do this on linux).
> 
> 
> @section Configure Terms and History
> @cindex configure terms
> @cindex canadian
> 
> This section is not instructions for building GCC.  If you are trying to
> do a build, you should first read @uref{http://gcc.gnu.org/install/} or
> whatever installation instructions came with your source package.
> 
> The configure and build process has a long and colorful history, and can
> be confusing to anyone who doesn't know why things are the way they are.
> While there are other documents which describe the configuration process
> in detail, here are a few things that everyone working on GCC should
> know.
> 
> There are three system names that the build knows about: the machine you
> are building on (@dfn{build}), the machine that you are building for
> (@dfn{host}), and the machine that GCC will produce code for
> (@dfn{target}).  When you configure GCC, you specify these with
> @option{--build=}, @option{--host=}, and @option{--target=}.
> 
> Specifying the host without specifying the build should be avoided, as
> @command{configure} may (and once did) assume that the host you specify
> is also the build, which may not be true.
> 
> If build, host, and target are all the same, this is called a
> @dfn{native}.  If build and host are the same but target is different,
> this is called a @dfn{cross}.  If build, host, and target are all
> different this is called a @dfn{canadian} (for obscure reasons dealing
> with Canada's political party and the background of the person working
> on the build at that time).  If host and target are the same, but build
> is different, you are using a cross-compiler to build a native for a
> different system.  Some people call this a @dfn{host-x-host},
> @dfn{crossed native}, or @dfn{cross-built native}.  If build and target
> are the same, but host is different, you are using a cross compiler to
> build a cross compiler that produces code for the machine you're
> building on.  This is rare, so there is no common way of describing it
> (although I propose calling it a @dfn{crossback}).
> 
> If build and host are the same, the GCC you are building will also be
> used to build the target libraries (like @code{libstdc++}).  If build and host
> are different, you must have already build and installed a cross
> compiler that will be used to build the target libraries (if you
> configured with @option{--target=foo-bar}, this compiler will be called
> @command{foo-bar-gcc}).
> 
> In the case of target libraries, the machine you're building for is the
> machine you specified with @option{--target}.  So, build is the machine
> you're building on (no change there), host is the machine you're
> building for (the target libraries are built for the target, so host is
> the target you specified), and target doesn't apply (because you're not
> building a compiler, you're building libraries).  The configure/make
> process will adjust these variables as needed.  It also sets
> @code{$with_cross_host} to the original @option{--host} value in case you
> need it.
> 

Re: Simple question.

[mike stump]

> Date: Wed, 2 Jan 2002 15:06:43 -0800 (PST)
> From: Sir Ace <chandleg@wizardsworks.org>
> To: gcc@gnu.org


> I am having a very rough time trying to figure out something do to
> the poor documentation on gcc.  What I need to do is build a native
> compiler with a cross compiler.  My host platform is x86, the target
> is Hitachi sh-4.

> I have built and tested the cross compiler, it works great.
> I can not get the damn thing to build a native compiler for the sh-4
> it keeps failing when it tries to execute things during the make.

> Here is what I am doing, Can you please tell me where I am messing up?:

> ../gcc-3.0.1/configure --target=$TARGET --prefix=$PREFIX \
> --disable-shared --host=$TARGET --enable-languages=c

What part of the doc (I'll quote it below) was unclear?  I think you
missed the --build flag.

You either need that, or you need an a.out sh executor/emulator
strapped into your OS (yes, you can do this on linux).


@section Configure Terms and History
@cindex configure terms
@cindex canadian

This section is not instructions for building GCC.  If you are trying to
do a build, you should first read @uref{http://gcc.gnu.org/install/} or
whatever installation instructions came with your source package.

The configure and build process has a long and colorful history, and can
be confusing to anyone who doesn't know why things are the way they are.
While there are other documents which describe the configuration process
in detail, here are a few things that everyone working on GCC should
know.

There are three system names that the build knows about: the machine you
are building on (@dfn{build}), the machine that you are building for
(@dfn{host}), and the machine that GCC will produce code for
(@dfn{target}).  When you configure GCC, you specify these with
@option{--build=}, @option{--host=}, and @option{--target=}.

Specifying the host without specifying the build should be avoided, as
@command{configure} may (and once did) assume that the host you specify
is also the build, which may not be true.

If build, host, and target are all the same, this is called a
@dfn{native}.  If build and host are the same but target is different,
this is called a @dfn{cross}.  If build, host, and target are all
different this is called a @dfn{canadian} (for obscure reasons dealing
with Canada's political party and the background of the person working
on the build at that time).  If host and target are the same, but build
is different, you are using a cross-compiler to build a native for a
different system.  Some people call this a @dfn{host-x-host},
@dfn{crossed native}, or @dfn{cross-built native}.  If build and target
are the same, but host is different, you are using a cross compiler to
build a cross compiler that produces code for the machine you're
building on.  This is rare, so there is no common way of describing it
(although I propose calling it a @dfn{crossback}).

If build and host are the same, the GCC you are building will also be
used to build the target libraries (like @code{libstdc++}).  If build and host
are different, you must have already build and installed a cross
compiler that will be used to build the target libraries (if you
configured with @option{--target=foo-bar}, this compiler will be called
@command{foo-bar-gcc}).

In the case of target libraries, the machine you're building for is the
machine you specified with @option{--target}.  So, build is the machine
you're building on (no change there), host is the machine you're
building for (the target libraries are built for the target, so host is
the target you specified), and target doesn't apply (because you're not
building a compiler, you're building libraries).  The configure/make
process will adjust these variables as needed.  It also sets
@code{$with_cross_host} to the original @option{--host} value in case you
need it.

Re: Simple question.

[Craig Rodrigues]

On Wed, Jan 02, 2002 at 03:06:43PM -0800, Sir Ace wrote:
> 
>   I am having a very rough time trying to figure out something do to the
> poor documentation on gcc.  What I need to do is build a native compiler
> with a cross compiler.
> My host platform is x86, the target is Hitachi sh-4.


You should probably ask the people at the GNU/Linux on
SuperH Project for help:
http://www.m17n.org/linux-sh/

They have made some changes to GCC so that an SH-4
cross-compiler will work, and not all of their changes
have been incorporated into the mainline GCC.
-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@mediaone.net          

Re: Simple question.

[Carlo Wood]

On Wed, Jan 02, 2002 at 03:06:43PM -0800, Sir Ace wrote:
> 
>   I am having a very rough time trying to figure out something do to the
> poor documentation on gcc.  What I need to do is build a native compiler
> with a cross compiler.
> /bin/sh: ./gengenrtl: cannot execute binary file

I have no clue actually - never used a cross compiler.
But after looking at gengenrtl in the Makefiles, I'd guess
that it is build with the cross compiler and thus won't
run on the box that is compiling the new compiler.

They use HOST_CC for that.  When HOST_CC is not set,
it is set to the value of CC.  So I suppose you need to
set HOST_CC somehow.  Maybe setting an environment variable
would work, not sure if then make will use that value.

Hope this helps.

-- 
Carlo Wood <carlo@alinoe.com>

Simple question.

[Sir Ace]

  I am having a very rough time trying to figure out something do to the
poor documentation on gcc.  What I need to do is build a native compiler
with a cross compiler.
My host platform is x86, the target is Hitachi sh-4.

I have built and tested the cross compiler, it works great.
I can not get the damn thing to build a native compiler for the sh-4
it keeps failing when it tries to execute things during the make.

Here is what I am doing, Can you please tell me where I am messing up?:

export TARGET=sh4-linux;export PREFIX=/daydream/usr/local/; \
export PATH=${PATH}:${PREFIX}/bin;export ROOT=/daydream; \
export CC=sh4-linux-gcc;export CXX=sh4-linux-gcc

cd /usr/src/dreamcast/
mkdir build-gcc
cd build-gcc

../gcc-3.0.1/configure --target=$TARGET --prefix=$PREFIX \
--disable-shared --host=$TARGET --enable-languages=c

make

{spew}
 ` ` case "" in ?*) echo  ;; esac ` ` case "" in ?*) echo  ;; esac ` 
./gengenrtl -h >tmp-genrtl.h
/bin/sh: ./gengenrtl: cannot execute binary file
make[1]: *** [s-genrtl] Error 126
make[1]: Leaving directory `/usr/src/dreamcast/build-gcc/gcc'
make: *** [all-gcc] Error 2
root@meteor:/usr/src/dreamcast/build-gcc#

Re: Simple question

[Alexandre Oliva]

On Aug  3, 2000, Desmond Cheung <dycheung@cs.sfu.ca> wrote:

> after I have got the gcc port for our own processor,
> do I need binutils and newlib installed for this
> processor as well? if yes, does that mean I have to
> write the ports for them?

Yep

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Simple question

[Desmond Cheung]

Hi,

after I have got the gcc port for our own processor,
do I need binutils and newlib installed for this
processor as well? if yes, does that mean I have to
write the ports for them?

Thanks

Desmond

Re: simple question

[Michael Meissner]

On Fri, Oct 15, 1999 at 03:34:22AM -0500, Lynn Winebarger wrote:
> 
>    How are 48-bit pointers for the i386 represented in RTL?  If they're
> never generated by gcc, how _would_ they look? (I'm looking at
> disassembled code to translate to RTL)

GCC on the 386 only represents pointers as 32-bit quantities.  It assumes the
code segment == data segment == stack segment.

-- 
Michael Meissner, Cygnus Solutions
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886
email: meissner@cygnus.com	phone: 978-486-9304	fax: 978-692-4482

Re: simple question

[Mike Stump]

> Date: Fri, 15 Oct 1999 03:34:22 -0500 (EST)
> From: Lynn Winebarger <owinebar@free-expression.org>

> How are 48-bit pointers for the i386 represented in RTL?  If they're
> never generated by gcc, how _would_ they look? (I'm looking at
> disassembled code to translate to RTL)

A simple question, ha!  Say you have:

es = x;
ax = y;
[es:ax] = z;

In RTL this is:

(set (reg 1) (mem (symref x)))
(set (reg 2) (mem (symref y)))
(set (mem (plus (shiftl (reg 1) (const_int <whatever>))
		(reg 2)))
     (mem (symref z)))

and you realize that Pmode is 64 bits now.  You have to crack the rtl
down to valid operands and so forth, but you get the idea.  When you
do analysis on the memory addresses, you should be able to regenerate
the 32 bit values (if the code came from a compiler).

I look forward to seeing the GNU (de)re-compiler!

simple question

[Lynn Winebarger]

   How are 48-bit pointers for the i386 represented in RTL?  If they're
never generated by gcc, how _would_ they look? (I'm looking at
disassembled code to translate to RTL)

Thanks,
Lynn

Re: simple question

[Mike Stump]

> Date: Fri, 15 Oct 1999 03:34:22 -0500 (EST)
> From: Lynn Winebarger <owinebar@free-expression.org>

> How are 48-bit pointers for the i386 represented in RTL?  If they're
> never generated by gcc, how _would_ they look? (I'm looking at
> disassembled code to translate to RTL)

A simple question, ha!  Say you have:

es = x;
ax = y;
[es:ax] = z;

In RTL this is:

(set (reg 1) (mem (symref x)))
(set (reg 2) (mem (symref y)))
(set (mem (plus (shiftl (reg 1) (const_int <whatever>))
		(reg 2)))
     (mem (symref z)))

and you realize that Pmode is 64 bits now.  You have to crack the rtl
down to valid operands and so forth, but you get the idea.  When you
do analysis on the memory addresses, you should be able to regenerate
the 32 bit values (if the code came from a compiler).

I look forward to seeing the GNU (de)re-compiler!

Re: simple question

[Michael Meissner]

On Fri, Oct 15, 1999 at 03:34:22AM -0500, Lynn Winebarger wrote:
> 
>    How are 48-bit pointers for the i386 represented in RTL?  If they're
> never generated by gcc, how _would_ they look? (I'm looking at
> disassembled code to translate to RTL)

GCC on the 386 only represents pointers as 32-bit quantities.  It assumes the
code segment == data segment == stack segment.

-- 
Michael Meissner, Cygnus Solutions
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886
email: meissner@cygnus.com	phone: 978-486-9304	fax: 978-692-4482

simple question

[Lynn Winebarger]

   How are 48-bit pointers for the i386 represented in RTL?  If they're
never generated by gcc, how _would_ they look? (I'm looking at
disassembled code to translate to RTL)

Thanks,
Lynn

Re: Simple question

[Toon Moene]

>  Do anybody know if it is possible to compile EGCS on Cray
>  (ymp-cray-unicos, j90-cray-unicos) ?

Unfortunately, it is not.  This isn't so much a problem in the  
UNICOS setup (I've compiled various GNU packages on these systems),  
but due to the fact that the gcc/egcs compiler has no notion of  
computer architectures which don't have byte-addressability.

I'm sorry,
Toon.

Re: Simple question

[Jeffrey A Law]

  In message < Pine.SGI.3.95.981028105051.3412A-100000@rose.man.poznan.pl >you wr
ite:
  > I have one simple question:
  > Do anybody know if it is possible to compile EGCS on Cray
  > (ymp-cray-unicos, j90-cray-unicos) ?
  > 
  > It is realy important for me.
I don't think there's much of a chance for a native compiler on a ymp.  You
might be able to use it to host a cross compiler of some kind, but I doubt
it's going to "just work", you'll probably need to hack on it a little.

I don't know about the j90.

jeff

Simple question

[Juliusz Pukacki]

I have one simple question:
Do anybody know if it is possible to compile EGCS on Cray
(ymp-cray-unicos, j90-cray-unicos) ?

It is realy important for me.

************************************************************
*Juliusz Pukacki                    pukacki@man.poznan.pl  * 
*      Poznan Supercomputing and Networking Center         * 
*tel.(+48 61) 852-85-03 x.264       fax.(+48 61) 852-59-54 *
************************************************************