Mailing List Archive

Support open source code!


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Targetting sparc



>>>>> "Darren" == Darren Cook <darren@example.com> writes:

    Darren> everything it offered. Everything works so far, though I
    Darren> think I installed about half a dozen X servers before I
    Darren> realized what it was asking, so I may have problems when I
    Darren> get round to setting X up.

Ask yourself a question:  What is my video card?  Then either the X
setup process will ask you this, and fix it, or when you are ready to
try to run X you simply do

ln -sf XF86_Mach32 /usr/X11R6/bin/X

(of course you substitute the appropriate card name for "Mach32"), and 
then you can delete everything XF86_* (except of course the server
that you just made the link to).  You could even do a 'mv', but then
it's a little harder to figure out which server you're using.

    Darren> I noticed when going through the man pages for gcc, that
    Darren> it can target Sparc machines. Did I misunderstand this, or
    Darren> does it mean I can make a binary for a Sun machine on my
    Darren> Linux machine?  Has anyone tried this - is it really just
    Darren> as simple as adding -mSparc (or whatever the option was)
    Darren> to the cc command?

Yes and no.  GCC is a retargetable development system, yes.  However,
it needs to be built for that purpose.  Building a cross-compiler is
relatively hairy.  About 2/3 of the GCC suite is target independent,
but eventually you have to emit machine code.  What happens is that 
GCC builds a hierarchy of the following sort:

/usr/lib/gcc-lib/                # GCC's library area
            |
            +-- i486-linux/      # GCC's native i486 linux target
            |       |
            |       +-- 2.6.3/   # version 2.6.3 compilers & libraries
            |       |
            |       +-- 2.7.2/   # version 2.7.2     "     "     "
            |
            +-- i486-linuxaout/  # GCC's native i486 linux (a.out) target
            |       |
            |       +-- 2.6.3/   # version 2.6.3     "     "     "
            |       |
            |       +-- 2.7.2/   # version 2.7.2     "     "     "
            |
            +-- sparc-solaris/   # GCC's cross to SPARC Solaris target
                    |
                    +-- 2.6.3/   # version 2.6.3     "     "     "

These lowest level directories contain binaries and system-specific
libraries.  On linux, the libraries include libgcc.a (helper functions
that are not part of libc) and libobjc.a but not libc.a or libm.a
because these are provided as part of the linux runtime system as
DSOs.  Most current linux systems include both the i486-linux (ELF)
target and the i486-linuxaout (old linker formet) target, so you can
see how it works.

On DOS (DJGPP) everything is statically linked so in principle you
might find libc.a and libm.a there (if I remember the theory
correctly).  I believe the exact behavior in this case is controlled by
the specs file in that directory.

Now, for the SPARC target, you would need to have appropriate jump
tables to link to the DSOs on the actual SPARC machine (an alternative 
would be to FTP the object files across, perhaps as an ar library and
do the link step there).

Probably someone has done all this.  I know that there was a
DOS-to-HPUX cross compiler advertised on the DJGPP mailing list a
couple of years ago.  But it is surely not included in your GCC
distribution; you'll have to go looking around for it.

Once you have the relevant cross-compilation system installed, yes,
it's as easy as "gcc -m sparc".  DJGPP developers often use Linux (or
*BSD) for their development system, and use a Un*x-based
cross-compilation environment, they only use DOS/Windowze for testing.



Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links