RE: Trying to build a cross compiler from linux to netbsd...

RE: Trying to build a cross compiler from linux to netbsd...

[David Korn]

>-----Original Message-----
>From: Kai Ruottu [ mailto:kai.ruottu@luukku.com ]
>Sent: 03 January 2001 11:09


>---------------------- clip --------------------------------
>"Some options which only apply to building cross compilers:
>
>--with-headers=dir -- Specifies a directory which has target include
>    files. This options is required when building a cross compiler, if
>    ${prefix}/${target}/sys-include doesn't pre-exist. These include
>    files will be copied into the gcc install directory. Fixincludes
>    will be run on these files to make them compatible with gcc. "
>---------------------- clip --------------------------------
>
>can cause thoughts like (from Dave Korn):
>
>>  The words 'REQUIRED when building a cross compiler" and
>>"if $prefix/$target/sys-include doesn't exist" makes it seem like you
>>*must* use --with-headers, or put the headers into sys-include.
>
> When using my "bad English", the missing "the" in the clause would
>say clearly that the "target include files" cannot mean the standard
>C headers for the target, only some 'unspecified headers for the target'
>which need some fixing and must either be preinstalled into
>'${prefix}/${target}/sys-include', or pointed with '--with-headers'.

  Kai, your English is excellent! I think it's simply a matter of the
word 'the' being omitted/elided/implicit in that sentence; it's a somewhat
colloquial/slang kind of english usage. We tend to be a bit imprecise
with our definite articles. Of course, I cannot know for sure the intent
behind the original phrasing; this is just how I interpret it.

> My understanding for the purpose of the 'sys-include' is that it is
>the equivalent of '/usr/local/include' for a native compiler, ie. it
>was aimed for the system-specific or 3rd-party headers, searched before
>the standard C-headers (the 'sys-' comes from the 'system-specific').

  Surely unfixed headers are of no use at all ?

  There seems to be an awful lot of include directories around. I find (in
order of search path)

     $prefix/lib/gcc-lib/$target/$version/include
        - contains  fixinc'ed headers after 'make install'
     $prefix/$target/sys-include
        - contains original target headers
     $prefix/$target/include
        - nothing gets put here by gcc build/install at all.

 Now, I don't understand why we need this many directories.  It seems that
the documentation has not been kept up to date with the way things work.

> But for the 'universal case', I wouldn't suggest anybody to use the
>'--with-headers=' before the question "Why?" has been answered. There
>must be some sane reason to try to fix the standard C-headers for the
>target...

  Because libgcc needs to be built with fixed headers during the build
process before install has taken place ? 

       DaveK

-- 
The Boulder Pledge: "Under no circumstances will I ever purchase anything 
offered to me as the result of an unsolicited email message. Nor will I 
forward chain letters, petitions, mass mailings, or virus warnings to large 
numbers of others. This is my contribution to the survival of the online
community."


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

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

RE: Trying to build a cross compiler from linux to netbsd...

[David Korn]

>-----Original Message-----
>From: Kai Ruottu [ mailto:kai.ruottu@luukku.com ]
>Sent: 03 January 2001 11:09


>---------------------- clip --------------------------------
>"Some options which only apply to building cross compilers:
>
>--with-headers=dir -- Specifies a directory which has target include
>    files. This options is required when building a cross compiler, if
>    ${prefix}/${target}/sys-include doesn't pre-exist. These include
>    files will be copied into the gcc install directory. Fixincludes
>    will be run on these files to make them compatible with gcc. "
>---------------------- clip --------------------------------
>
>can cause thoughts like (from Dave Korn):
>
>>  The words 'REQUIRED when building a cross compiler" and
>>"if $prefix/$target/sys-include doesn't exist" makes it seem like you
>>*must* use --with-headers, or put the headers into sys-include.
>
> When using my "bad English", the missing "the" in the clause would
>say clearly that the "target include files" cannot mean the standard
>C headers for the target, only some 'unspecified headers for the target'
>which need some fixing and must either be preinstalled into
>'${prefix}/${target}/sys-include', or pointed with '--with-headers'.

  Kai, your English is excellent! I think it's simply a matter of the
word 'the' being omitted/elided/implicit in that sentence; it's a somewhat
colloquial/slang kind of english usage. We tend to be a bit imprecise
with our definite articles. Of course, I cannot know for sure the intent
behind the original phrasing; this is just how I interpret it.

> My understanding for the purpose of the 'sys-include' is that it is
>the equivalent of '/usr/local/include' for a native compiler, ie. it
>was aimed for the system-specific or 3rd-party headers, searched before
>the standard C-headers (the 'sys-' comes from the 'system-specific').

  Surely unfixed headers are of no use at all ?

  There seems to be an awful lot of include directories around. I find (in
order of search path)

     $prefix/lib/gcc-lib/$target/$version/include
        - contains  fixinc'ed headers after 'make install'
     $prefix/$target/sys-include
        - contains original target headers
     $prefix/$target/include
        - nothing gets put here by gcc build/install at all.

 Now, I don't understand why we need this many directories.  It seems that
the documentation has not been kept up to date with the way things work.

> But for the 'universal case', I wouldn't suggest anybody to use the
>'--with-headers=' before the question "Why?" has been answered. There
>must be some sane reason to try to fix the standard C-headers for the
>target...

  Because libgcc needs to be built with fixed headers during the build
process before install has taken place ? 

       DaveK

-- 
The Boulder Pledge: "Under no circumstances will I ever purchase anything 
offered to me as the result of an unsolicited email message. Nor will I 
forward chain letters, petitions, mass mailings, or virus warnings to large 
numbers of others. This is my contribution to the survival of the online
community."


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

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

RE: Trying to build a cross compiler from linux to netbsd...

[David Korn]

>-----Original Message-----
>From: Rod Stewart [ mailto:stewart@nexus.carleton.ca ]
>Sent: 03 January 2001 02:58

  [snip entire body of letter]

>-Rms


  :) You may cause some confusion signing your name this way when talking
about gcc <vbg>

        DaveK
-- 
The Boulder Pledge: "Under no circumstances will I ever purchase anything 
offered to me as the result of an unsolicited email message. Nor will I 
forward chain letters, petitions, mass mailings, or virus warnings to large 
numbers of others. This is my contribution to the survival of the online
community." 


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

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

RE: Trying to build a cross compiler from linux to netbsd...

[David Korn]

>-----Original Message-----
>From: Rod Stewart [ mailto:stewart@nexus.carleton.ca ]
>Sent: 03 January 2001 02:58

  [snip entire body of letter]

>-Rms


  :) You may cause some confusion signing your name this way when talking
about gcc <vbg>

        DaveK
-- 
The Boulder Pledge: "Under no circumstances will I ever purchase anything 
offered to me as the result of an unsolicited email message. Nor will I 
forward chain letters, petitions, mass mailings, or virus warnings to large 
numbers of others. This is my contribution to the survival of the online
community." 


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

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

Trying to build a cross compiler from linux to netbsd...

[Dick Munroe]

using egcs 1.0.3a (other compilers aren't an option, unfortunately, the
vendor says that this is the only one guaranteed to work).  Anyway, we
have Linux boxes and need to cross compile to Netbsd (more particularly,
i386 a.out format executables).  The following is one attempt:

Binutils builds with:

../binutils-2.10.1/configure --host=i686-pc-linux-gnu --target=i386-aout
--prefix=/home/usr/local

so that much of the cross compiler tools seems to work fine (the tools
may not, but that's for later).

Trying to build egcs 1.0.3a with:

../egcs-1.0.3a/configure --host=i686-pc-linux-gnu --target=i386-aout
--prefix=/home/usr/local

Which ultimately generates the following error:

ln collect2 ld
/home/egcs/gcc/xgcc -B/home/egcs/gcc/ -DCROSS_COMPILE -DIN_GCC    -g -O2

-I./include  -I. -I../../egcs-1.0.3a/gcc -I../../egcs-1.0.3a/gcc/config
\
-c ../../egcs-1.0.3a/gcc/objc/hash.c -o objc/hash.o
In file included from ../../egcs-1.0.3a/gcc/objc/hash.c:31:
../../egcs-1.0.3a/gcc/objc/runtime.h:31: stdio.h: No such file or
directory
../../egcs-1.0.3a/gcc/objc/runtime.h:32: ctype.h: No such file or
directory
In file included from ../../egcs-1.0.3a/gcc/objc/runtime.h:38,
                 from ../../egcs-1.0.3a/gcc/objc/hash.c:31:
include/objc/objc-api.h:33: stdio.h: No such file or directory
make[1]: *** [objc/hash.o] Error 1
make[1]: Leaving directory `/home/egcs/gcc'
make: *** [all-gcc] Error 2

and checking objc-api.h, it requires stdio.h and ctype.h and, equally
obviously it's not finding them.  configure.in and makefile.in are a
second (more like sixth) language to me so I'm having problems figuring
out exactly what's going on here, but it looks as if xgcc isn't picking
up the system include files and hasn't supplied links to the needed ones
during the initial configure phase and I can't figure out how to get the
-idirafter (which was my initial thought on fixing the problem) put in
the right place.

I've tried a couple other things with no success, specifically:

../egcs-1.0.3a/configure --host=I386-unknown-linux-gnu
--target=i386-unknown-netbsd --prefix=/home/usr/local

Which generates a different error but related in the sense that there is
no include file for machine/ansi.h (required for all netbsd-like
compiles).

cp ../../egcs-1.0.3a/gcc/README-fixinc include/README
chmod a+r include/README
touch stmp-int-hdrs
rm -f SYSCALLS.c tmp-SYSCALLS.s
cat ../../egcs-1.0.3a/gcc/sys-types.h ../../egcs-1.0.3a/gcc/sys-protos.h
> SYSCALLS.c
/home/egcs/gcc/xgcc -B/home/egcs/gcc/ -DCROSS_COMPILE -DIN_GCC    -g -O2
-I./include     -I. -I../../egcs-1.0.3a/gcc -I../../egcs-1.
0.3a/gcc/config \
  -aux-info SYSCALLS.c.X -S -o tmp-SYSCALLS.s SYSCALLS.c
In file included from SYSCALLS.c:86:
include/stddef.h:28: machine/ansi.h: No such file or directory
make[1]: *** [SYSCALLS.c.X] Error 1
make[1]: Leaving directory `/home/egcs/gcc'
make: *** [all-gcc] Error 2

So clearly I'm missing the boat on something and what is the question.

Any and all help will be appreciated.

TIA

Dick Munroe






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

Re: Trying to build a cross compiler from linux to netbsd...

[Rod Stewart]

On Tue, 2 Jan 2001, Dick Munroe wrote:
[...]
> ../egcs-1.0.3a/configure --host=i686-pc-linux-gnu --target=i386-aout
> --prefix=/home/usr/local
> 
> Which ultimately generates the following error:
> 
> ln collect2 ld
> /home/egcs/gcc/xgcc -B/home/egcs/gcc/ -DCROSS_COMPILE -DIN_GCC    -g -O2
> 
> -I./include  -I. -I../../egcs-1.0.3a/gcc -I../../egcs-1.0.3a/gcc/config
> \
> -c ../../egcs-1.0.3a/gcc/objc/hash.c -o objc/hash.o
> In file included from ../../egcs-1.0.3a/gcc/objc/hash.c:31:
> ../../egcs-1.0.3a/gcc/objc/runtime.h:31: stdio.h: No such file or
> directory
> ../../egcs-1.0.3a/gcc/objc/runtime.h:32: ctype.h: No such file or
> directory
> In file included from ../../egcs-1.0.3a/gcc/objc/runtime.h:38,
>                  from ../../egcs-1.0.3a/gcc/objc/hash.c:31:
> include/objc/objc-api.h:33: stdio.h: No such file or directory
> make[1]: *** [objc/hash.o] Error 1
> make[1]: Leaving directory `/home/egcs/gcc'
> make: *** [all-gcc] Error 2

You need to install libc headers files and libraries for your target
system.  Ie. the NetBSD ones.

-Rms


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

Re: Trying to build a cross compiler from linux to netbsd...

[Rod Stewart]

On Tue, 2 Jan 2001, Dick Munroe wrote:
[...]
> ../egcs-1.0.3a/configure --host=i686-pc-linux-gnu --target=i386-aout
> --prefix=/home/usr/local
> 
> Which ultimately generates the following error:
> 
> ln collect2 ld
> /home/egcs/gcc/xgcc -B/home/egcs/gcc/ -DCROSS_COMPILE -DIN_GCC    -g -O2
> 
> -I./include  -I. -I../../egcs-1.0.3a/gcc -I../../egcs-1.0.3a/gcc/config
> \
> -c ../../egcs-1.0.3a/gcc/objc/hash.c -o objc/hash.o
> In file included from ../../egcs-1.0.3a/gcc/objc/hash.c:31:
> ../../egcs-1.0.3a/gcc/objc/runtime.h:31: stdio.h: No such file or
> directory
> ../../egcs-1.0.3a/gcc/objc/runtime.h:32: ctype.h: No such file or
> directory
> In file included from ../../egcs-1.0.3a/gcc/objc/runtime.h:38,
>                  from ../../egcs-1.0.3a/gcc/objc/hash.c:31:
> include/objc/objc-api.h:33: stdio.h: No such file or directory
> make[1]: *** [objc/hash.o] Error 1
> make[1]: Leaving directory `/home/egcs/gcc'
> make: *** [all-gcc] Error 2

You need to install libc headers files and libraries for your target
system.  Ie. the NetBSD ones.

-Rms


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

Re: Trying to build a cross compiler from linux to netbsd...

[Alexandre Oliva]

On Jan  3, 2001, Dick Munroe <munroe@csworks.com> wrote:

> ../../egcs-1.0.3a/gcc/objc/runtime.h:31: stdio.h: No such file or
> directory
> ../../egcs-1.0.3a/gcc/objc/runtime.h:32: ctype.h: No such file or
> directory

You must have a copy of the C library headers of the target machine in
order to build GCC.  You should have pointed to them with the
configure flag --with-headers.

-- 
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

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

Re: Trying to build a cross compiler from linux to netbsd...

[Kai Ruottu]

Alexandre Oliva wrote:
> 
> On Jan  3, 2001, Dick Munroe <munroe@csworks.com> wrote:
> 
> > ../../egcs-1.0.3a/gcc/objc/runtime.h:31: stdio.h: No such file or
> > directory
> > ../../egcs-1.0.3a/gcc/objc/runtime.h:32: ctype.h: No such file or
> > directory
> 
> You must have a copy of the C library headers of the target machine in
> order to build GCC.  You should have pointed to them with the
> configure flag --with-headers.

 Doing like Sinuhe the Egyptian, I would ask "Why?"  As I have understood
after a long research of this mess, the '--with-headers=something" is
meaned to point to headers which need some fixing for GCC. The NetBSD
headers can be non-ANSI and non-standard ones and need fixing, so this
advice can be valid here. But the "why" is missing and can cause people
to think this using of the '--with-headers=' being and universal CRC-
spray to get the car go on...

 AFAIK, the glibc-2.x headers used in Linux, the newlib headers, the
Solaris2 headers, SVR4 headers etc. don't need any fixing. So the
'--with-headers=' should never be used for them. "Don't fix if it
ain't broken"...

 The current "Using and Porting the GNU Compiler Collection" by RMS
(made from the latest snapshots) still says that the target libs and
headers should be preinstalled into their final place, into

  $prefix/$target/lib
and
  $prefix/$target/include

where $prefix and $target are the values given to '--prefix=' and
'--target=' while configuring.  Also the 'gcc/INSTALL' used to give
the same instructions for "How to Install a Cross-Compiler".  This
is the idea, although the default $prefix, '/usr/local', is used in
the texts...

 The GCC-manual is available for everyone who has the GCC-sources,
and can be downloaded as a prebuilt '.ps' or '.pdf' or '.html' etc.
formats from the net. Normally the 'gcc.info' will be built while
building GCC and can be browsed with the GNU info. All those having
a native GCC should have the 'gcc.info' already and have no problems
in finding the "Installation / Cross-Compiler" in it.  For a cross-
compiler builder reading this section from the GCC manual sounds
quite natural, but quite many fail to do this...

 The text from http://www.gnu.org/software/gcc/install/configure.html

---------------------- clip --------------------------------
"Some options which only apply to building cross compilers:

--with-headers=dir -- Specifies a directory which has target include
    files. This options is required when building a cross compiler, if
    ${prefix}/${target}/sys-include doesn't pre-exist. These include
    files will be copied into the gcc install directory. Fixincludes
    will be run on these files to make them compatible with gcc. "
---------------------- clip --------------------------------

can cause thoughts like (from Dave Korn):

>  The words 'REQUIRED when building a cross compiler" and
>"if $prefix/$target/sys-include doesn't exist" makes it seem like you
>*must* use --with-headers, or put the headers into sys-include.

 When using my "bad English", the missing "the" in the clause would
say clearly that the "target include files" cannot mean the standard
C headers for the target, only some 'unspecified headers for the target'
which need some fixing and must either be preinstalled into
'${prefix}/${target}/sys-include', or pointed with '--with-headers'.

 My understanding for the purpose of the 'sys-include' is that it is
the equivalent of '/usr/local/include' for a native compiler, ie. it
was aimed for the system-specific or 3rd-party headers, searched before
the standard C-headers (the 'sys-' comes from the 'system-specific').

 Okeydokey, my advice for cross-NetBSD build would be to either copy
the NetBSD standard system headers into '$prefix/$target/sys-include'
or into some temporary place and point to them using '--with-headers='
while running configure, start the build and see what happens...

 How well the 'fixincludes' in egcs-1.0.3 then handles the NetBSD
standard C headers is another problem... I would prefer to check
myself the fixed headers in '.../gcc/include', doing a 'diff -c'
for every fixed header and seeing what was added/changed, and if
there was any sanity at all...

 But for the 'universal case', I wouldn't suggest anybody to use the
'--with-headers=' before the question "Why?" has been answered. There
must be some sane reason to try to fix the standard C-headers for the
target...

Cheers, Kai



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

Re: Trying to build a cross compiler from linux to netbsd...

[Alexandre Oliva]

On Jan  3, 2001, Kai Ruottu <kai.ruottu@luukku.com> wrote:

>  Doing like Sinuhe the Egyptian, I would ask "Why?"

GCC needs the target headers to be able to compile anything for the
target.  It's not just about fixing, it's about having declarations,
macro definitions, etc, that are compatible with the actual C library
of the target system.

-- 
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

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

Re: Trying to build a cross compiler from linux to netbsd...

[Kai Ruottu]

Alexandre Oliva wrote:
> 
> On Jan  3, 2001, Kai Ruottu <kai.ruottu@luukku.com> wrote:
> 
> >  Doing like Sinuhe the Egyptian, I would ask "Why?"
> 
> GCC needs the target headers to be able to compile anything for the
> target.  It's not just about fixing, it's about having declarations,
> macro definitions, etc, that are compatible with the actual C library
> of the target system.

 But why they must now be preinstalled into the 'sys-include', not into
the 'include' as done during the last ten or so years?  Are all the 1000
or more cross-compilers I have built during all these years used the wrong
directory for the target headers?

Cheers, Kai

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

Re: Trying to build a cross compiler from linux to netbsd...

[Alexandre Oliva]

On Jan  3, 2001, Kai Ruottu <kai.ruottu@luukku.com> wrote:

>  But why they must now be preinstalled into the 'sys-include', not into
> the 'include' as done during the last ten or so years?

Because GCC's include directory contains GCC's own files, and possibly
fixincluded versions of files in sys-include, and we don't want to
overwrite them.

-- 
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

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

Re: Trying to build a cross compiler from linux to netbsd...

[Kai Ruottu]

Alexandre Oliva wrote:
> 
> On Jan  3, 2001, Kai Ruottu <kai.ruottu@luukku.com> wrote:
> 
> >  But why they must now be preinstalled into the 'sys-include', not into
> > the 'include' as done during the last ten or so years?
> 
> Because GCC's include directory contains GCC's own files, and possibly
> fixincluded versions of files in sys-include, and we don't want to
> overwrite them.

 I didn't really ask about the '.../gcc/include', but about the $prefix/$target/include
versus the $prefix/$target/sys-include... Here are the related instructions from a quite
recent GCC manual (for 2.96 snapshots):

------------------------------- clip -------------------------------------------------- 
  Cross-Compilers and Header Files

  If you are cross-compiling a standalone program or a program for an embedded system,
  then you may not need any header files except the few that are part of GNU CC (and
  those of your program).  However, if you intend to link your program with a standard
  C library such as libc.a, then you probably need to compile with the header files
  that go with the library you use.

  The GNU C compiler does not come with these files, because (1) they are system-specific,
  and (2) they belong in a C library, not in a compiler.

  If the GNU C library supports your target machine, then you can get the header files
  from there (assuming you actually use the GNU library when you link your program).

  If your target machine comes with a C compiler, it probably comes with suitable header
  files also.  If you make these files accessible from the host machine, the cross-compiler
  can use them also.

  Otherwise, you're on your own in finding header files to use when cross-compiling.

  When you have found suitable header files, put them in the directory
  /usr/local/target/include, before building the cross compiler.  Then installation will
  run fixincludes properly and install the corrected versions of the header files where
  the compiler will use them.

  Provide the header files before you build the cross-compiler, because the build stage
  actually runs the cross-compiler to produce parts of libgcc.a.  (These are the parts
  that can be compiled with GNU CC.)  Some of them need suitable header files.
----------------------------- clip -------------------------------------------------- 

 As seen, no mention about 'sys-include'. But when one uses the '--with-headers=',
the standard C headers will be copied into the '$prefix/$target/sys-include' and
left there.

 More about this headers-mess, the 'sys-include' is carried with the name
CROSS_INCLUDE_DIR and the 'include' with the name TOOL_INCLUDE_DIR, and the GCC
manual says about these: 

----------------- clip -------------------------------------------------- 
  Standard Header File Directories

 <snip>

  CROSS_INCLUDE_DIR is used only for a cross compiler.  GNU CC doesn't install
  anything there.

  TOOL_INCLUDE_DIR is used for both native and cross compilers.  It is the place
  for other packages to install header files that GNU CC will use.  For a cross-
  compiler, this is the equivalent of /usr/include.  When you build a cross-compiler,
  fixincludes processes any header files in this directory.
----------------- clip -------------------------------------------------- 

 So nothing should be installed by GCC into the 'sys-include' while the 'include'
is "the equivalent of /usr/include" for a cross-compiler... And the words "For a
native compiler" seem to be missing before the words "It is the place for other
packages..." (meaning that a native compiler may have 3rd-party headers there).

 A cross-compiler cannot put both the standard C headers and the 3rd party headers
in the same directory, at least mixing all the headers into the same soup shouldn't
be recommended... Of course using those '-I' etc. options for gcc and cpp:

E:\usr\local\lib\gcc-lib\i486-linux-gnu\2_95.1>cpp --help
Usage: cpp [switches] input output
Switches:
  -include <file>           Include the contents of <file> before other files
  -imacros <file>           Accept definition of marcos in <file>
  -iprefix <path>           Specify <path> as a prefix for next two options
  -iwithprefix <dir>        Add <dir> to the end of the system include paths
  -iwithprefixbefore <dir>  Add <dir> to the end of the main include paths
  -isystem <dir>            Add <dir> to the start of the system include paths
  -idirafter <dir>          Add <dir> to the end of the system include paths
  -I <dir>                  Add <dir> to the end of the main include paths

may help, but someone may want to put the 3rd party ones into a nice package...

 And the words about fixincludes processing files in TOOL_INCLUDE_DIR aren't valid
any more (since 2.95.2? 2.96 ?), because it is now the CROSS_INCLUDE_DIR in GCC
Makefiles.

 My humble wish is that these things could be told a little more clearer in the
GCC documentation. But who has the courage to correct the RMS words... I'm quite
sure that after reading the previous description about the CROSS_INCLUDE_DIR
(the 'sys-include'), nobody can say what is the purpose for it with a cross-
compiler... My interpretation between the lines is that it was aimed for the 3rd
party headers for a cross-compiler, for the simple reason that where else they
could be put?

 I haven't mentioned the CrossGCC-FAQ, because the instructions should be as
clear as possible in the GCC docs first, when describing the generic case. The
FAQ could then elaborate some specific cases and the workarounds for them. Not
as it done now that the FAQ is taken as describing the generic case and the
workarounds there taken as generic instructions for building a cross-compiler.
 
Cheers, Kai


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

Re: Trying to build a cross compiler from linux to netbsd...

[Kai Ruottu]

Alexandre Oliva wrote:
> 
> On Jan  3, 2001, Kai Ruottu <kai.ruottu@luukku.com> wrote:
> 
> >  But why they must now be preinstalled into the 'sys-include', not into
> > the 'include' as done during the last ten or so years?
> 
> Because GCC's include directory contains GCC's own files, and possibly
> fixincluded versions of files in sys-include, and we don't want to
> overwrite them.

 I didn't really ask about the '.../gcc/include', but about the $prefix/$target/include
versus the $prefix/$target/sys-include... Here are the related instructions from a quite
recent GCC manual (for 2.96 snapshots):

------------------------------- clip -------------------------------------------------- 
  Cross-Compilers and Header Files

  If you are cross-compiling a standalone program or a program for an embedded system,
  then you may not need any header files except the few that are part of GNU CC (and
  those of your program).  However, if you intend to link your program with a standard
  C library such as libc.a, then you probably need to compile with the header files
  that go with the library you use.

  The GNU C compiler does not come with these files, because (1) they are system-specific,
  and (2) they belong in a C library, not in a compiler.

  If the GNU C library supports your target machine, then you can get the header files
  from there (assuming you actually use the GNU library when you link your program).

  If your target machine comes with a C compiler, it probably comes with suitable header
  files also.  If you make these files accessible from the host machine, the cross-compiler
  can use them also.

  Otherwise, you're on your own in finding header files to use when cross-compiling.

  When you have found suitable header files, put them in the directory
  /usr/local/target/include, before building the cross compiler.  Then installation will
  run fixincludes properly and install the corrected versions of the header files where
  the compiler will use them.

  Provide the header files before you build the cross-compiler, because the build stage
  actually runs the cross-compiler to produce parts of libgcc.a.  (These are the parts
  that can be compiled with GNU CC.)  Some of them need suitable header files.
----------------------------- clip -------------------------------------------------- 

 As seen, no mention about 'sys-include'. But when one uses the '--with-headers=',
the standard C headers will be copied into the '$prefix/$target/sys-include' and
left there.

 More about this headers-mess, the 'sys-include' is carried with the name
CROSS_INCLUDE_DIR and the 'include' with the name TOOL_INCLUDE_DIR, and the GCC
manual says about these: 

----------------- clip -------------------------------------------------- 
  Standard Header File Directories

 <snip>

  CROSS_INCLUDE_DIR is used only for a cross compiler.  GNU CC doesn't install
  anything there.

  TOOL_INCLUDE_DIR is used for both native and cross compilers.  It is the place
  for other packages to install header files that GNU CC will use.  For a cross-
  compiler, this is the equivalent of /usr/include.  When you build a cross-compiler,
  fixincludes processes any header files in this directory.
----------------- clip -------------------------------------------------- 

 So nothing should be installed by GCC into the 'sys-include' while the 'include'
is "the equivalent of /usr/include" for a cross-compiler... And the words "For a
native compiler" seem to be missing before the words "It is the place for other
packages..." (meaning that a native compiler may have 3rd-party headers there).

 A cross-compiler cannot put both the standard C headers and the 3rd party headers
in the same directory, at least mixing all the headers into the same soup shouldn't
be recommended... Of course using those '-I' etc. options for gcc and cpp:

E:\usr\local\lib\gcc-lib\i486-linux-gnu\2_95.1>cpp --help
Usage: cpp [switches] input output
Switches:
  -include <file>           Include the contents of <file> before other files
  -imacros <file>           Accept definition of marcos in <file>
  -iprefix <path>           Specify <path> as a prefix for next two options
  -iwithprefix <dir>        Add <dir> to the end of the system include paths
  -iwithprefixbefore <dir>  Add <dir> to the end of the main include paths
  -isystem <dir>            Add <dir> to the start of the system include paths
  -idirafter <dir>          Add <dir> to the end of the system include paths
  -I <dir>                  Add <dir> to the end of the main include paths

may help, but someone may want to put the 3rd party ones into a nice package...

 And the words about fixincludes processing files in TOOL_INCLUDE_DIR aren't valid
any more (since 2.95.2? 2.96 ?), because it is now the CROSS_INCLUDE_DIR in GCC
Makefiles.

 My humble wish is that these things could be told a little more clearer in the
GCC documentation. But who has the courage to correct the RMS words... I'm quite
sure that after reading the previous description about the CROSS_INCLUDE_DIR
(the 'sys-include'), nobody can say what is the purpose for it with a cross-
compiler... My interpretation between the lines is that it was aimed for the 3rd
party headers for a cross-compiler, for the simple reason that where else they
could be put?

 I haven't mentioned the CrossGCC-FAQ, because the instructions should be as
clear as possible in the GCC docs first, when describing the generic case. The
FAQ could then elaborate some specific cases and the workarounds for them. Not
as it done now that the FAQ is taken as describing the generic case and the
workarounds there taken as generic instructions for building a cross-compiler.
 
Cheers, Kai


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

Re: Trying to build a cross compiler from linux to netbsd...

[Alexandre Oliva]

On Jan  3, 2001, Kai Ruottu <kai.ruottu@luukku.com> wrote:

>  But why they must now be preinstalled into the 'sys-include', not into
> the 'include' as done during the last ten or so years?

Because GCC's include directory contains GCC's own files, and possibly
fixincluded versions of files in sys-include, and we don't want to
overwrite them.

-- 
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

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

Re: Trying to build a cross compiler from linux to netbsd...

[Kai Ruottu]

Alexandre Oliva wrote:
> 
> On Jan  3, 2001, Kai Ruottu <kai.ruottu@luukku.com> wrote:
> 
> >  Doing like Sinuhe the Egyptian, I would ask "Why?"
> 
> GCC needs the target headers to be able to compile anything for the
> target.  It's not just about fixing, it's about having declarations,
> macro definitions, etc, that are compatible with the actual C library
> of the target system.

 But why they must now be preinstalled into the 'sys-include', not into
the 'include' as done during the last ten or so years?  Are all the 1000
or more cross-compilers I have built during all these years used the wrong
directory for the target headers?

Cheers, Kai

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

Re: Trying to build a cross compiler from linux to netbsd...

[Alexandre Oliva]

On Jan  3, 2001, Kai Ruottu <kai.ruottu@luukku.com> wrote:

>  Doing like Sinuhe the Egyptian, I would ask "Why?"

GCC needs the target headers to be able to compile anything for the
target.  It's not just about fixing, it's about having declarations,
macro definitions, etc, that are compatible with the actual C library
of the target system.

-- 
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

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

Re: Trying to build a cross compiler from linux to netbsd...

[Kai Ruottu]

Alexandre Oliva wrote:
> 
> On Jan  3, 2001, Dick Munroe <munroe@csworks.com> wrote:
> 
> > ../../egcs-1.0.3a/gcc/objc/runtime.h:31: stdio.h: No such file or
> > directory
> > ../../egcs-1.0.3a/gcc/objc/runtime.h:32: ctype.h: No such file or
> > directory
> 
> You must have a copy of the C library headers of the target machine in
> order to build GCC.  You should have pointed to them with the
> configure flag --with-headers.

 Doing like Sinuhe the Egyptian, I would ask "Why?"  As I have understood
after a long research of this mess, the '--with-headers=something" is
meaned to point to headers which need some fixing for GCC. The NetBSD
headers can be non-ANSI and non-standard ones and need fixing, so this
advice can be valid here. But the "why" is missing and can cause people
to think this using of the '--with-headers=' being and universal CRC-
spray to get the car go on...

 AFAIK, the glibc-2.x headers used in Linux, the newlib headers, the
Solaris2 headers, SVR4 headers etc. don't need any fixing. So the
'--with-headers=' should never be used for them. "Don't fix if it
ain't broken"...

 The current "Using and Porting the GNU Compiler Collection" by RMS
(made from the latest snapshots) still says that the target libs and
headers should be preinstalled into their final place, into

  $prefix/$target/lib
and
  $prefix/$target/include

where $prefix and $target are the values given to '--prefix=' and
'--target=' while configuring.  Also the 'gcc/INSTALL' used to give
the same instructions for "How to Install a Cross-Compiler".  This
is the idea, although the default $prefix, '/usr/local', is used in
the texts...

 The GCC-manual is available for everyone who has the GCC-sources,
and can be downloaded as a prebuilt '.ps' or '.pdf' or '.html' etc.
formats from the net. Normally the 'gcc.info' will be built while
building GCC and can be browsed with the GNU info. All those having
a native GCC should have the 'gcc.info' already and have no problems
in finding the "Installation / Cross-Compiler" in it.  For a cross-
compiler builder reading this section from the GCC manual sounds
quite natural, but quite many fail to do this...

 The text from http://www.gnu.org/software/gcc/install/configure.html

---------------------- clip --------------------------------
"Some options which only apply to building cross compilers:

--with-headers=dir -- Specifies a directory which has target include
    files. This options is required when building a cross compiler, if
    ${prefix}/${target}/sys-include doesn't pre-exist. These include
    files will be copied into the gcc install directory. Fixincludes
    will be run on these files to make them compatible with gcc. "
---------------------- clip --------------------------------

can cause thoughts like (from Dave Korn):

>  The words 'REQUIRED when building a cross compiler" and
>"if $prefix/$target/sys-include doesn't exist" makes it seem like you
>*must* use --with-headers, or put the headers into sys-include.

 When using my "bad English", the missing "the" in the clause would
say clearly that the "target include files" cannot mean the standard
C headers for the target, only some 'unspecified headers for the target'
which need some fixing and must either be preinstalled into
'${prefix}/${target}/sys-include', or pointed with '--with-headers'.

 My understanding for the purpose of the 'sys-include' is that it is
the equivalent of '/usr/local/include' for a native compiler, ie. it
was aimed for the system-specific or 3rd-party headers, searched before
the standard C-headers (the 'sys-' comes from the 'system-specific').

 Okeydokey, my advice for cross-NetBSD build would be to either copy
the NetBSD standard system headers into '$prefix/$target/sys-include'
or into some temporary place and point to them using '--with-headers='
while running configure, start the build and see what happens...

 How well the 'fixincludes' in egcs-1.0.3 then handles the NetBSD
standard C headers is another problem... I would prefer to check
myself the fixed headers in '.../gcc/include', doing a 'diff -c'
for every fixed header and seeing what was added/changed, and if
there was any sanity at all...

 But for the 'universal case', I wouldn't suggest anybody to use the
'--with-headers=' before the question "Why?" has been answered. There
must be some sane reason to try to fix the standard C-headers for the
target...

Cheers, Kai



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

Re: Trying to build a cross compiler from linux to netbsd...

[Dick Munroe]

At 1:03 AM -0200 1/3/01, Alexandre Oliva wrote:
>On Jan  3, 2001, Dick Munroe <munroe@csworks.com> wrote:
>
>> ../../egcs-1.0.3a/gcc/objc/runtime.h:31: stdio.h: No such file or
>> directory
>> ../../egcs-1.0.3a/gcc/objc/runtime.h:32: ctype.h: No such file or
>> directory
>
>You must have a copy of the C library headers of the target machine in
>order to build GCC.  You should have pointed to them with the
>configure flag --with-headers.

Thanks for the pointer, that's helped a lot.  I grabbed the NETBSD 
compile tar from their distribution, use with-headers and with-libs 
and have gotten farther, except that when building GCC, I get pretty 
much through the compiler build procedure and get the following:

loading site script /dev/null
loading cache ./config.cache
checking for gcc... /home/egcs/gcc/xgcc -B/home/egcs/gcc/
checking whether the C compiler (/home/egcs/gcc/xgcc 
-B/home/egcs/gcc/ -g -O2 ) works... no
configure: error: installation or configuration problem: C compiler 
cannot create executables.
make[1]: *** [stmp-f2c.h] Error 1
make[1]: Leaving directory `/home/egcs/gcc'
make: *** [all-gcc] Error 2

So I try the compiler on a Hello world program and discover:

[root@linux egcs]# /home/egcs/gcc/xgcc -B/home/egcs/gcc/ -g -O2 foo.c
/home/usr/local/i386-unknown-netbsd/lib/crt0.o: file not recognized: 
File format not recognized
collect2: ld returned 1 exit status
[root@linux egcs]# file /home/usr/local/i386-unknown-netbsd/lib/crt0.o
/home/usr/local/i386-unknown-netbsd/lib/crt0.o: ELF 32-bit LSB 
relocatable, Intel 80386, version 1, not stripped

which would seem a little weird since the cross compiler ought to 
know about the ELF stuff (or does EGCS 1.0.3 predate the ELF format? 
In which case I'll have to go back to an earlier version of the 
NetBSD release to get my libraries).

Anyway, I'm trying for a.out format under NetBSD and clearly this 
isn't happening at the moment.

Any suggestions?

Dick Munroe
--
Dick Munroe			(E) mailto:munroe@csworks.com
Cottage Software Works, Inc.	(O) 617 901 9052
PMB 361				(F) 617 489 0328
464 Common St.			(W) http://www.acornsw.com/
Belmont, Ma. 02478

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

Re: Trying to build a cross compiler from linux to netbsd...

[Kai Ruottu]

Dick Munroe wrote:
> 
> [root@linux egcs]# /home/egcs/gcc/xgcc -B/home/egcs/gcc/ -g -O2 foo.c
> /home/usr/local/i386-unknown-netbsd/lib/crt0.o: file not recognized:
> File format not recognized
> collect2: ld returned 1 exit status
> [root@linux egcs]# file /home/usr/local/i386-unknown-netbsd/lib/crt0.o
> /home/usr/local/i386-unknown-netbsd/lib/crt0.o: ELF 32-bit LSB
> relocatable, Intel 80386, version 1, not stripped

The version 1.5 of NetBSD seems to have switched to ELF from the earlier
a.out... A clip from the NetBSD/x86 FAQ at 'www.netbsd.org':

--------------------- clip ---------------------------------
Other sources of information

     XFree86 FAQ - for problems with installing or configuring X. 
     NetBSD 1.5 install notes - supported hardware and how to install. 
     The NetBSD ELF FAQ. As of NetBSD 1.5, the i386 port uses ELF instead
     of a.out.           ================================================
     =========
--------------------- clip ---------------------------------

The previous 1.4 version seems to have used aout in x86...

> which would seem a little weird since the cross compiler ought to
> know about the ELF stuff (or does EGCS 1.0.3 predate the ELF format?

 The egcs-1.0.3a knows only the 'aout' format for NetBSD...

> In which case I'll have to go back to an earlier version of the
> NetBSD release to get my libraries).

 Yes... The decision depends on which version the target machines are
running, it is expected that 1.4 binaries may have troubles when tried
under 1.3.2 machines, but not vice versa...
 
> Anyway, I'm trying for a.out format under NetBSD and clearly this
> isn't happening at the moment.
> 
> Any suggestions?

 Please check your current NetBSD binutils, they seem to be for aout
as the error hints and then they are ok... And your compiler is ok...
Just get the proper aout libs and headers for them and run, almost...

 If you look at the entry for NetBSD/x86 in 'gcc/configure' :

  i[3456]86-*-netbsd*)
	tm_file=i386/netbsd.h
	xm_file=i386/xm-netbsd.h
	# On NetBSD, the headers are already okay, except for math.h.
	fixincludes=fixinc.math
	tmake_file=t-netbsd
	;;

you will see that only the 'math.h' in the standard C headers needs any
fixing.. The patch for the 'math.h' follows (for NetBSD 1.3.2) :

---------------------- clip -----------------------
*** math.h.orig	Wed May 20 22:52:33 1998
--- math.h	Wed Jan  3 21:26:44 2001
***************
*** 65,71 ****
--- 65,75 ----
  #define _XOPEN_ fdlibm_xopen
  #define _POSIX_ fdlibm_posix
  
+ #ifdef __cplusplus
+ struct math_exception {
+ #else
  struct exception {
+ #endif
  	int type;
  	char *name;
  	double arg1;
***************
*** 151,157 ****
--- 155,165 ----
  extern double remainder __P((double, double));
  extern double scalb __P((double, double));
  
+ #ifdef __cplusplus
+ extern int matherr __P((struct math_exception *));
+ #else
  extern int matherr __P((struct exception *));
+ #endif
  
  /*
   * IEEE Test Vector

---------------------- clip -----------------------

 Perhaps this is already fixed in the 1.4 headers...

 I had built my earlier GCC for NetBSD (1.3.2) target in Oct. 1998, so
perhaps it was the time to tolerate the same pain again. And when my
disgust against using the '--with-headers=' was strong, I increased my
pain by using it now, copying the already installed standard netbsd-headers
into a temporary directory, disabling the '/usr/local/i486-netbsd/include',
where the headers were, by renaming it... Then configuring, building and
installing it (using 'make install') proved my thoughts to be true, the
target headers were copied into the

  /usr/local/i486-netbsd/sys-include

just as the docs said and they were left there even after the installation.
But no header-fixing happened during the build. So I had to manually install
the given patch for 'math.h'. It is very well known and identical for all
Sun and SVR systems...

 I used the same egcs-1.0.3a sources in question... Ok, the '-v' option of GCC
shows the potential problem, if it exists at all. For most people it is
enough that the cross-compiler works, for some like me, it also must work in
the right way :

----------------------------- clip -----------------------------------------
GNU CPP version egcs-2.90.29 980515 (egcs-1.0.3 release) (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc-lib/i486-netbsd/egcs-2.90.29/include
 /usr/local/i486-netbsd/sys-include
 /usr/local/i486-netbsd/include
End of search list.
----------------------------- clip -----------------------------------------

 As shown, the GCC's own and the fixed headers will be found first, then the
(local) system-specific headers and last the standard C headers for the target.
This has been the arrangement during the last ten or so years and I haven't seen
it being changed to anything else yet...

 The standard C headers being in the 'sys-include' just don't fit into this model...
So my suggestion would be to move everything from the 'sys-include' to the 'include'
and keep the 'sys-include' as the place for additional 3rd-party headers (like ones
with Oracle, other DB-systems, tcl/tk,....) not belonging to the 'standard C headers'...

 There was only one issue I fixed while building... Somehow the 'tm.h' had:

	#define TARGET_CPU_DEFAULT 1
	#include "i386/netbsd.h"

while the 'gcc/config/i386/netbsd.h' had another definition for TARGET_CPU_DEFAULT,
which then would have caused a redefinition warning with almost every file compiled...
So my fix to this was to remove the first row in 'tm.h'... Why it appeared there
remained unsolved, but who does care...

 The definition in 'gcc/config/i386/netbsd.h' could be checked :

----------------------- clip --------------------------------------
  #define TARGET_CPU_DEFAULT 0400		/* TARGET_NO_FANCY_MATH_387 */
  
  /* This is tested by i386gas.h.  */
----------------------- clip --------------------------------------

 The '0400' sounds more sane than '1', but checking what these 'TARGET' bits
mean from the 'gcc/config/i386/i386.h' could be recommended. BTW, the 0400
means that it is a octal number... Checking the sanity of the selection can be
left to you as homework, perhaps the more recent NetBSDs have a fixed math-
emulator and the 0400 isn't suitable any more. Or nobody runs 386-PCs or
486SX-PCs (without a 387) any more.  Ok, it is only the default setting and
rebuilding the GCC because of this doesn't sound necessary...

 The 'make install' also did some stupid things... I haven't used it for
years, but using my own install-script-templates which do all things just as
I wish...

 Ok, the following stupid things happened:

 1. the *protoize and gcov were copied with their base names into $prefix/bin

 2. the _G_config.h was copied into $prefix/$target/include

 3. the libiberty.a and libstdc++.a were copied into $prefix/$target/lib

 The things in 1. are target-dependent, and at least the libstdc++.a in 3. is
version dependent... Newer versions of _G_config.h and libiberty.a may probably
only add more things, but the new GCC can sometimes be older than the already
installed GCC(s)... My previous GCC for NetBSD was egcs-1.1. 

 So the right place for the _G_config.h and the libs is under the
'$prefix/lib/gcc-lib/$target/$version' (the header going to the 'include' there).
Renaming the '*protoize' and 'gcov' to have the same exec-prefix ('i386-netbsd-')
as 'gcc', 'g++' and 'c++' is also suggested...

 If you try later GCC versions for the same target, these things will not be
overwritten if you also remember to rename the 'gcc', 'g++' etc. to have a postfix
'-o' (meaning '-old', for instance 'i386-netbsd-gcc-o') or something before
installing the new GCC... The version dependent stuff should always be installed
into its own subdir ('$prefix/lib/gcc-lib/$target/$version').

Cheers, Kai



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

Re: Trying to build a cross compiler from linux to netbsd...

[Kai Ruottu]

Corrections...

Kai Ruottu wrote:
> 
>  There was only one issue I fixed while building... Somehow the 'tm.h' had:
> 
>         #define TARGET_CPU_DEFAULT 1
>         #include "i386/netbsd.h"
> 
> while the 'gcc/config/i386/netbsd.h' had another definition for TARGET_CPU_DEFAULT,
>  The definition in 'gcc/config/i386/netbsd.h' could be checked :
>   #define TARGET_CPU_DEFAULT 0400               /* TARGET_NO_FANCY_MATH_387 */
> 
>  The '0400' sounds more sane than '1', but checking what these 'TARGET' bits
> mean from the 'gcc/config/i386/i386.h' could be recommended.

 I somehow mixed the TARGET_CPU_DEFAULT in my mind with the TARGET_DEFAULT bit-collection.
The '1' is sane and means that the default target-CPU will be '486', '0' is '386', '2' is
'586' or 'pentium' and so on... The '1' came because of my target name 'i486-netbsd'.

 The same error was made the port-maker, later GCCs have the 'netbsd.h' corrected by
removing the '#define TARGET_CPU_DEFAULT 0400' garbage. Also the 'freebsd.h' had the
same definition in egcs-1.0.3a and egcs-1.1.2 sources and removed from the later ones.

 Is it really sure that only egcs-1.0.3a can be used for NetBSD/aout ? Someone has
maintained the port in the newer GCCs and there are quite a lot fixes, not only that
for the TARGET_CPU_DEFAULT...

Cheers, Kai



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

Re: Trying to build a cross compiler from linux to netbsd...

[Kai Ruottu]

Corrections...

Kai Ruottu wrote:
> 
>  There was only one issue I fixed while building... Somehow the 'tm.h' had:
> 
>         #define TARGET_CPU_DEFAULT 1
>         #include "i386/netbsd.h"
> 
> while the 'gcc/config/i386/netbsd.h' had another definition for TARGET_CPU_DEFAULT,
>  The definition in 'gcc/config/i386/netbsd.h' could be checked :
>   #define TARGET_CPU_DEFAULT 0400               /* TARGET_NO_FANCY_MATH_387 */
> 
>  The '0400' sounds more sane than '1', but checking what these 'TARGET' bits
> mean from the 'gcc/config/i386/i386.h' could be recommended.

 I somehow mixed the TARGET_CPU_DEFAULT in my mind with the TARGET_DEFAULT bit-collection.
The '1' is sane and means that the default target-CPU will be '486', '0' is '386', '2' is
'586' or 'pentium' and so on... The '1' came because of my target name 'i486-netbsd'.

 The same error was made the port-maker, later GCCs have the 'netbsd.h' corrected by
removing the '#define TARGET_CPU_DEFAULT 0400' garbage. Also the 'freebsd.h' had the
same definition in egcs-1.0.3a and egcs-1.1.2 sources and removed from the later ones.

 Is it really sure that only egcs-1.0.3a can be used for NetBSD/aout ? Someone has
maintained the port in the newer GCCs and there are quite a lot fixes, not only that
for the TARGET_CPU_DEFAULT...

Cheers, Kai



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

Re: Trying to build a cross compiler from linux to netbsd...

[Kai Ruottu]

Dick Munroe wrote:
> 
> [root@linux egcs]# /home/egcs/gcc/xgcc -B/home/egcs/gcc/ -g -O2 foo.c
> /home/usr/local/i386-unknown-netbsd/lib/crt0.o: file not recognized:
> File format not recognized
> collect2: ld returned 1 exit status
> [root@linux egcs]# file /home/usr/local/i386-unknown-netbsd/lib/crt0.o
> /home/usr/local/i386-unknown-netbsd/lib/crt0.o: ELF 32-bit LSB
> relocatable, Intel 80386, version 1, not stripped

The version 1.5 of NetBSD seems to have switched to ELF from the earlier
a.out... A clip from the NetBSD/x86 FAQ at 'www.netbsd.org':

--------------------- clip ---------------------------------
Other sources of information

     XFree86 FAQ - for problems with installing or configuring X. 
     NetBSD 1.5 install notes - supported hardware and how to install. 
     The NetBSD ELF FAQ. As of NetBSD 1.5, the i386 port uses ELF instead
     of a.out.           ================================================
     =========
--------------------- clip ---------------------------------

The previous 1.4 version seems to have used aout in x86...

> which would seem a little weird since the cross compiler ought to
> know about the ELF stuff (or does EGCS 1.0.3 predate the ELF format?

 The egcs-1.0.3a knows only the 'aout' format for NetBSD...

> In which case I'll have to go back to an earlier version of the
> NetBSD release to get my libraries).

 Yes... The decision depends on which version the target machines are
running, it is expected that 1.4 binaries may have troubles when tried
under 1.3.2 machines, but not vice versa...
 
> Anyway, I'm trying for a.out format under NetBSD and clearly this
> isn't happening at the moment.
> 
> Any suggestions?

 Please check your current NetBSD binutils, they seem to be for aout
as the error hints and then they are ok... And your compiler is ok...
Just get the proper aout libs and headers for them and run, almost...

 If you look at the entry for NetBSD/x86 in 'gcc/configure' :

  i[3456]86-*-netbsd*)
	tm_file=i386/netbsd.h
	xm_file=i386/xm-netbsd.h
	# On NetBSD, the headers are already okay, except for math.h.
	fixincludes=fixinc.math
	tmake_file=t-netbsd
	;;

you will see that only the 'math.h' in the standard C headers needs any
fixing.. The patch for the 'math.h' follows (for NetBSD 1.3.2) :

---------------------- clip -----------------------
*** math.h.orig	Wed May 20 22:52:33 1998
--- math.h	Wed Jan  3 21:26:44 2001
***************
*** 65,71 ****
--- 65,75 ----
  #define _XOPEN_ fdlibm_xopen
  #define _POSIX_ fdlibm_posix
  
+ #ifdef __cplusplus
+ struct math_exception {
+ #else
  struct exception {
+ #endif
  	int type;
  	char *name;
  	double arg1;
***************
*** 151,157 ****
--- 155,165 ----
  extern double remainder __P((double, double));
  extern double scalb __P((double, double));
  
+ #ifdef __cplusplus
+ extern int matherr __P((struct math_exception *));
+ #else
  extern int matherr __P((struct exception *));
+ #endif
  
  /*
   * IEEE Test Vector

---------------------- clip -----------------------

 Perhaps this is already fixed in the 1.4 headers...

 I had built my earlier GCC for NetBSD (1.3.2) target in Oct. 1998, so
perhaps it was the time to tolerate the same pain again. And when my
disgust against using the '--with-headers=' was strong, I increased my
pain by using it now, copying the already installed standard netbsd-headers
into a temporary directory, disabling the '/usr/local/i486-netbsd/include',
where the headers were, by renaming it... Then configuring, building and
installing it (using 'make install') proved my thoughts to be true, the
target headers were copied into the

  /usr/local/i486-netbsd/sys-include

just as the docs said and they were left there even after the installation.
But no header-fixing happened during the build. So I had to manually install
the given patch for 'math.h'. It is very well known and identical for all
Sun and SVR systems...

 I used the same egcs-1.0.3a sources in question... Ok, the '-v' option of GCC
shows the potential problem, if it exists at all. For most people it is
enough that the cross-compiler works, for some like me, it also must work in
the right way :

----------------------------- clip -----------------------------------------
GNU CPP version egcs-2.90.29 980515 (egcs-1.0.3 release) (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc-lib/i486-netbsd/egcs-2.90.29/include
 /usr/local/i486-netbsd/sys-include
 /usr/local/i486-netbsd/include
End of search list.
----------------------------- clip -----------------------------------------

 As shown, the GCC's own and the fixed headers will be found first, then the
(local) system-specific headers and last the standard C headers for the target.
This has been the arrangement during the last ten or so years and I haven't seen
it being changed to anything else yet...

 The standard C headers being in the 'sys-include' just don't fit into this model...
So my suggestion would be to move everything from the 'sys-include' to the 'include'
and keep the 'sys-include' as the place for additional 3rd-party headers (like ones
with Oracle, other DB-systems, tcl/tk,....) not belonging to the 'standard C headers'...

 There was only one issue I fixed while building... Somehow the 'tm.h' had:

	#define TARGET_CPU_DEFAULT 1
	#include "i386/netbsd.h"

while the 'gcc/config/i386/netbsd.h' had another definition for TARGET_CPU_DEFAULT,
which then would have caused a redefinition warning with almost every file compiled...
So my fix to this was to remove the first row in 'tm.h'... Why it appeared there
remained unsolved, but who does care...

 The definition in 'gcc/config/i386/netbsd.h' could be checked :

----------------------- clip --------------------------------------
  #define TARGET_CPU_DEFAULT 0400		/* TARGET_NO_FANCY_MATH_387 */
  
  /* This is tested by i386gas.h.  */
----------------------- clip --------------------------------------

 The '0400' sounds more sane than '1', but checking what these 'TARGET' bits
mean from the 'gcc/config/i386/i386.h' could be recommended. BTW, the 0400
means that it is a octal number... Checking the sanity of the selection can be
left to you as homework, perhaps the more recent NetBSDs have a fixed math-
emulator and the 0400 isn't suitable any more. Or nobody runs 386-PCs or
486SX-PCs (without a 387) any more.  Ok, it is only the default setting and
rebuilding the GCC because of this doesn't sound necessary...

 The 'make install' also did some stupid things... I haven't used it for
years, but using my own install-script-templates which do all things just as
I wish...

 Ok, the following stupid things happened:

 1. the *protoize and gcov were copied with their base names into $prefix/bin

 2. the _G_config.h was copied into $prefix/$target/include

 3. the libiberty.a and libstdc++.a were copied into $prefix/$target/lib

 The things in 1. are target-dependent, and at least the libstdc++.a in 3. is
version dependent... Newer versions of _G_config.h and libiberty.a may probably
only add more things, but the new GCC can sometimes be older than the already
installed GCC(s)... My previous GCC for NetBSD was egcs-1.1. 

 So the right place for the _G_config.h and the libs is under the
'$prefix/lib/gcc-lib/$target/$version' (the header going to the 'include' there).
Renaming the '*protoize' and 'gcov' to have the same exec-prefix ('i386-netbsd-')
as 'gcc', 'g++' and 'c++' is also suggested...

 If you try later GCC versions for the same target, these things will not be
overwritten if you also remember to rename the 'gcc', 'g++' etc. to have a postfix
'-o' (meaning '-old', for instance 'i386-netbsd-gcc-o') or something before
installing the new GCC... The version dependent stuff should always be installed
into its own subdir ('$prefix/lib/gcc-lib/$target/$version').

Cheers, Kai



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

Re: Trying to build a cross compiler from linux to netbsd...

[Dick Munroe]

At 1:03 AM -0200 1/3/01, Alexandre Oliva wrote:
>On Jan  3, 2001, Dick Munroe <munroe@csworks.com> wrote:
>
>> ../../egcs-1.0.3a/gcc/objc/runtime.h:31: stdio.h: No such file or
>> directory
>> ../../egcs-1.0.3a/gcc/objc/runtime.h:32: ctype.h: No such file or
>> directory
>
>You must have a copy of the C library headers of the target machine in
>order to build GCC.  You should have pointed to them with the
>configure flag --with-headers.

Thanks for the pointer, that's helped a lot.  I grabbed the NETBSD 
compile tar from their distribution, use with-headers and with-libs 
and have gotten farther, except that when building GCC, I get pretty 
much through the compiler build procedure and get the following:

loading site script /dev/null
loading cache ./config.cache
checking for gcc... /home/egcs/gcc/xgcc -B/home/egcs/gcc/
checking whether the C compiler (/home/egcs/gcc/xgcc 
-B/home/egcs/gcc/ -g -O2 ) works... no
configure: error: installation or configuration problem: C compiler 
cannot create executables.
make[1]: *** [stmp-f2c.h] Error 1
make[1]: Leaving directory `/home/egcs/gcc'
make: *** [all-gcc] Error 2

So I try the compiler on a Hello world program and discover:

[root@linux egcs]# /home/egcs/gcc/xgcc -B/home/egcs/gcc/ -g -O2 foo.c
/home/usr/local/i386-unknown-netbsd/lib/crt0.o: file not recognized: 
File format not recognized
collect2: ld returned 1 exit status
[root@linux egcs]# file /home/usr/local/i386-unknown-netbsd/lib/crt0.o
/home/usr/local/i386-unknown-netbsd/lib/crt0.o: ELF 32-bit LSB 
relocatable, Intel 80386, version 1, not stripped

which would seem a little weird since the cross compiler ought to 
know about the ELF stuff (or does EGCS 1.0.3 predate the ELF format? 
In which case I'll have to go back to an earlier version of the 
NetBSD release to get my libraries).

Anyway, I'm trying for a.out format under NetBSD and clearly this 
isn't happening at the moment.

Any suggestions?

Dick Munroe
--
Dick Munroe			(E) mailto:munroe@csworks.com
Cottage Software Works, Inc.	(O) 617 901 9052
PMB 361				(F) 617 489 0328
464 Common St.			(W) http://www.acornsw.com/
Belmont, Ma. 02478

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

Re: Trying to build a cross compiler from linux to netbsd...

[Alexandre Oliva]

On Jan  3, 2001, Dick Munroe <munroe@csworks.com> wrote:

> ../../egcs-1.0.3a/gcc/objc/runtime.h:31: stdio.h: No such file or
> directory
> ../../egcs-1.0.3a/gcc/objc/runtime.h:32: ctype.h: No such file or
> directory

You must have a copy of the C library headers of the target machine in
order to build GCC.  You should have pointed to them with the
configure flag --with-headers.

-- 
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

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

Re: Trying to build a cross compiler from linux to netbsd...

[Kai Ruottu]

Dick Munroe wrote:
> 
> using egcs 1.0.3a (other compilers aren't an option, unfortunately, the
> vendor says that this is the only one guaranteed to work).  Anyway, we
> have Linux boxes and need to cross compile to Netbsd (more particularly,
> i386 a.out format executables).  The following is one attempt:
> 
> Binutils builds with:
> 
> ../binutils-2.10.1/configure --host=i686-pc-linux-gnu --target=i386-aout
> --prefix=/home/usr/local

 Why 'i386-aout' when your target is 'i386-netbsd' ?  The 'i386-aout' is
for a generic embedded system using the 'aout' object format and the format
used in the NetBSD libs most probably isn't the same...

------------------------- clip ----------------------------------
F:\usr\local\i486-netbsd\bin>ld -V
GNU ld version 2.9.1 (with BFD 2.9.1)
  Supported emulations:
   i386nbsd

F:\usr\local\i486-netbsd\bin>ld --help
Usage: ld [options] file...
  <snip>
ld: supported targets: a.out-i386-netbsd a.out-i386-bsd srec symbolsrec
tekhex binary ihex
ld: supported emulations: i386nbsd

F:\usr\local\i486-netbsd\lib>..\bin\nm crt0.o
         U __DYNAMIC
000007cc D ___progname
000007d0 D ___ps_strings
00000054 T ___start
         U _atexit
000006e8 T _dlclose
00000730 T _dlctl
00000770 T _dlerror
000006c4 T _dlopen
0000070c T _dlsym
00000004 C _environ
00000004 C _errno
         U _exit
         U _main
         U _strerror
00000000 T start
------------------------- clip ----------------------------------

 At least the shared libs, to which the '__DYNAMIC' in the startup hints,
can be totally unsupported with 'i386-aout'...
 
 So my primary suggestion would be to use the right target name... For how
to pre-install and handle the target libs & headers, I'll refer to my second
message about this subject.

Cheers, Kai



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

Re: Trying to build a cross compiler from linux to netbsd...

[Kai Ruottu]

Dick Munroe wrote:
> 
> using egcs 1.0.3a (other compilers aren't an option, unfortunately, the
> vendor says that this is the only one guaranteed to work).  Anyway, we
> have Linux boxes and need to cross compile to Netbsd (more particularly,
> i386 a.out format executables).  The following is one attempt:
> 
> Binutils builds with:
> 
> ../binutils-2.10.1/configure --host=i686-pc-linux-gnu --target=i386-aout
> --prefix=/home/usr/local

 Why 'i386-aout' when your target is 'i386-netbsd' ?  The 'i386-aout' is
for a generic embedded system using the 'aout' object format and the format
used in the NetBSD libs most probably isn't the same...

------------------------- clip ----------------------------------
F:\usr\local\i486-netbsd\bin>ld -V
GNU ld version 2.9.1 (with BFD 2.9.1)
  Supported emulations:
   i386nbsd

F:\usr\local\i486-netbsd\bin>ld --help
Usage: ld [options] file...
  <snip>
ld: supported targets: a.out-i386-netbsd a.out-i386-bsd srec symbolsrec
tekhex binary ihex
ld: supported emulations: i386nbsd

F:\usr\local\i486-netbsd\lib>..\bin\nm crt0.o
         U __DYNAMIC
000007cc D ___progname
000007d0 D ___ps_strings
00000054 T ___start
         U _atexit
000006e8 T _dlclose
00000730 T _dlctl
00000770 T _dlerror
000006c4 T _dlopen
0000070c T _dlsym
00000004 C _environ
00000004 C _errno
         U _exit
         U _main
         U _strerror
00000000 T start
------------------------- clip ----------------------------------

 At least the shared libs, to which the '__DYNAMIC' in the startup hints,
can be totally unsupported with 'i386-aout'...
 
 So my primary suggestion would be to use the right target name... For how
to pre-install and handle the target libs & headers, I'll refer to my second
message about this subject.

Cheers, Kai



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

Trying to build a cross compiler from linux to netbsd...

[Dick Munroe]

using egcs 1.0.3a (other compilers aren't an option, unfortunately, the
vendor says that this is the only one guaranteed to work).  Anyway, we
have Linux boxes and need to cross compile to Netbsd (more particularly,
i386 a.out format executables).  The following is one attempt:

Binutils builds with:

../binutils-2.10.1/configure --host=i686-pc-linux-gnu --target=i386-aout
--prefix=/home/usr/local

so that much of the cross compiler tools seems to work fine (the tools
may not, but that's for later).

Trying to build egcs 1.0.3a with:

../egcs-1.0.3a/configure --host=i686-pc-linux-gnu --target=i386-aout
--prefix=/home/usr/local

Which ultimately generates the following error:

ln collect2 ld
/home/egcs/gcc/xgcc -B/home/egcs/gcc/ -DCROSS_COMPILE -DIN_GCC    -g -O2

-I./include  -I. -I../../egcs-1.0.3a/gcc -I../../egcs-1.0.3a/gcc/config
\
-c ../../egcs-1.0.3a/gcc/objc/hash.c -o objc/hash.o
In file included from ../../egcs-1.0.3a/gcc/objc/hash.c:31:
../../egcs-1.0.3a/gcc/objc/runtime.h:31: stdio.h: No such file or
directory
../../egcs-1.0.3a/gcc/objc/runtime.h:32: ctype.h: No such file or
directory
In file included from ../../egcs-1.0.3a/gcc/objc/runtime.h:38,
                 from ../../egcs-1.0.3a/gcc/objc/hash.c:31:
include/objc/objc-api.h:33: stdio.h: No such file or directory
make[1]: *** [objc/hash.o] Error 1
make[1]: Leaving directory `/home/egcs/gcc'
make: *** [all-gcc] Error 2

and checking objc-api.h, it requires stdio.h and ctype.h and, equally
obviously it's not finding them.  configure.in and makefile.in are a
second (more like sixth) language to me so I'm having problems figuring
out exactly what's going on here, but it looks as if xgcc isn't picking
up the system include files and hasn't supplied links to the needed ones
during the initial configure phase and I can't figure out how to get the
-idirafter (which was my initial thought on fixing the problem) put in
the right place.

I've tried a couple other things with no success, specifically:

../egcs-1.0.3a/configure --host=I386-unknown-linux-gnu
--target=i386-unknown-netbsd --prefix=/home/usr/local

Which generates a different error but related in the sense that there is
no include file for machine/ansi.h (required for all netbsd-like
compiles).

cp ../../egcs-1.0.3a/gcc/README-fixinc include/README
chmod a+r include/README
touch stmp-int-hdrs
rm -f SYSCALLS.c tmp-SYSCALLS.s
cat ../../egcs-1.0.3a/gcc/sys-types.h ../../egcs-1.0.3a/gcc/sys-protos.h
> SYSCALLS.c
/home/egcs/gcc/xgcc -B/home/egcs/gcc/ -DCROSS_COMPILE -DIN_GCC    -g -O2
-I./include     -I. -I../../egcs-1.0.3a/gcc -I../../egcs-1.
0.3a/gcc/config \
  -aux-info SYSCALLS.c.X -S -o tmp-SYSCALLS.s SYSCALLS.c
In file included from SYSCALLS.c:86:
include/stddef.h:28: machine/ansi.h: No such file or directory
make[1]: *** [SYSCALLS.c.X] Error 1
make[1]: Leaving directory `/home/egcs/gcc'
make: *** [all-gcc] Error 2

So clearly I'm missing the boat on something and what is the question.

Any and all help will be appreciated.

TIA

Dick Munroe






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