Subject: Re: gcc-ada/gnat for Sparc64 ?
To: Mehul Sanghvi <mehul.sanghvi@gmail.com>
From: Seth Kurtzberg <seth@cql.com>
List: port-sparc64
Date: 02/11/2005 18:57:15
Mehul Sanghvi wrote:

>On Thu, 10 Feb 2005 20:09:19 -0700, Seth Kurtzberg <seth@cql.com> wrote:
>  
>
>>Hopefully you can find what you are looking for in binary form.
>>Certainly, if it weren't for the Ada requirement, you would find them
>>easily.  In case you can't find the binaries you need, the following
>>information may be helpful.
>>
>>    
>>
>
>So far I haven't found any binaries for NetBSD-2.0/sparc64.  I might have
>to tap you for that information on cross-compiling.
>
>  
>
>>First, one caution, gcc-3.4 had at that time (which was a few months
>>ago) some serious problems.  There was a minor release to gcc-4 that
>>fixed a lot, but not all, of the problems.  If you do have to jump
>>through these hoops to get a working compiler that includes ada, I would
>>work with gcc 3.3.3.  Then, you can always use gcc-3.3.3 with ada
>>support to build gcc-3.4.x.
>>
>>    
>>
>
>Actually I don't care which version of gcc-3 it is.  What I'm trying to do
>is make use of an U2 system that I have, by utilising it for doing gcc-4 builds
>from the gcc cvs tree.  At least something "unofficial" for now, and once I am
>familiar with things enough make it a contribution to the GCC folks as well
>as the NetBSD pkgsrc folks.
>
>Looking in pkgsrc, the dependencies for gcc3-ada and gcc34-ada are completely
>wrong.  According to those dependencies, all you need is gcc and glibc.  There
>is no dependency on gnat/Ada itself.  Of course I know better :)
>
> 
>  
>
>>Ada support is a PITA (as you've obviously discovered) because you have
>>to use the native version of gnat, and the cross compiled version of
>>gnat, and to do that requires some monkeying around with the execution
>>search path to use the version of gnat that gets you where you need to
>>go.  It isn't really difficult, it is just poorly documented.
>>
>>    
>>
>
>So you compile on some other platform (a NetBSD platform obviously), creating
>a whole cross-compiling toolchain, then using the cross-compiling toolchain,
>you build the compilers, move them over to target system (netbsd-sparc64),
>and then probably just for kicks, use the cross-compiled binaries to generate
>the native binaries.  Did I get the jist of it correct ? 
>  
>
Yes, except that you don't even have to be on a NetBSD system during the 
cross compiling phase.  Any *NIX will do.  The specification of the 
target environment is independent of the machine on which you are cross 
compiling.  There is no implicit assumption that you are building for 
the same O/S but for a different processor.  If you already have NetBSD 
on x86, then I would use it, because I've used it in the past and I know 
it works.

The thing that messes you up, just to make sure we are both thinking the 
same thing, is that you need the native version of gnat to build the Ada 
compiler, because parts of the Ada compiler are written in Ada.  
However, again for obvious reasons, the native version of gnat produces 
native code, which isn't what you need; that's why there has to be an 
extra round of cross-compilation.

It is always possible that someone built the entire compiler suite, 
including Ada.  If so, you can copy the gnat executable to a directory 
in the search path, and use it.  If you do this, you have to make sure 
that after the cross-compilation version of gnat is created, it is 
used.  If you don't use full path specifications, this can get nasty, 
since all the common shells hash the locations of executables.  So you 
may need to do a hash -r (for a ksh style shell) to make sure that the 
newly created gnat is used during the next part of the compilation process.

If the "make bootstrap" target worked properly with Ada, there wouldn't 
be a problem (or at least the problem wouldn't be so annoying).  
Unfortunately, the bootstrap target ignores Ada.  Frankly, I ignore Ada 
myself whenever possible.  :)

The bootstrap target in the makefile is useful if you also have to build 
a native glibc, but that shouldn't be necessary.  Once you have your 
working compiler, you can build glibc on the native machine without 
having to jump through any hoops.

>I've not cross-compiled before, but could I build on a solaris-sparc system
>so that I can run on a netbsd-sparc64 system ?  I don't have any other
>netbsd-sparc64 systems nor any other netbsd systems.
>  
>
You can build a cross compiler on any platform that can run gcc.  You 
need the header files for the target environment.  With the headers, it 
is possible to build the entire toolchain on any system.  Solaris-sparc 
is a logical choice, and the header files are likely to be correct, but 
if you run into problems there you can build in an x86 environment, as 
long as the correct header files are used.

Hopefully things will go smoothly in solaris, but I have seen gcc hickup 
there on occasion.  Not recently, but then all my sparc machines are 
running NetBSD, and I don't think I've tried to cross compile from 
solaris since 2.6.2, or thereabouts.

>  
>
>>If you are unable to get there the easy way (by finding some binaries
>>that have already been created, including Ada support) I have a
>>reasonably detailed procedure that can be used to get where you need to
>>go.  Since it is lengthy I won't eat up list bandwidth for it;  should
>>you need it, drop me an email and I'll send the procedure to you.  (Or
>>to anyone else, of course, burdened with Ada.)  Hopefully the binaries
>>you need will be available.
>>
>>    
>>
>
>I'll ping you and let you know whether I need it or not.  It sure as heck
>would make life easier if gnat was written in C :)  It could then go to any
>platform that GCC goes to without worrying about anything too much.
>  
>
Indeed.  I have thought more than once that it might be quicker to 
rewrite the damn code than to get the compiler working.

As I said before, though, it really isn't difficult to get the cross 
compiler built, it is just poorly documented, and it does require at 
least one more round of compilation than (logically) it should.

>
>cheers,
>
>      mehul
>
>  
>