Mailing List ArchiveSupport open source code!
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]Re: Targetting sparc
- To: tlug@example.com
- Subject: Re: Targetting sparc
- From: turnbull@example.com (Stephen J. Turnbull)
- Date: Wed, 26 Jun 96 12:18 JST
- Cc: tlug@example.com
- In-Reply-To: <19960626011800680.AAB195@example.com> (darren@example.com)
- Reply-To: tlug@example.com
- Sender: owner-tlug@example.com
>>>>> "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.
- References:
- Targetting sparc
- From: darren@example.com (Darren Cook)
Home | Main Index | Thread Index
- Prev by Date: Re: Documentation
- Next by Date: PPP still not up
- Prev by thread: Targetting sparc
- Next by thread: Documentation
- Index(es):
Home Page Mailing List Linux and Japan TLUG Members Links