Re: Targetting Sparc/Solaris

[Sam Brightman <samghost at mpx dot net>]

Nathan Kidd wrote:
> Sam Brightman wrote:
> > Nathan Kidd wrote:
> > > If you want your binary to run on Solaris 2.9 you can't link with a
> > > libc from e.g. 2.11.  Newer libc symbols will get referenced in
> > > your app that won't resolve on an older libc.
> > I realised that this may be an issue, but is it a show-stopper? Since
> >  the whole idea is to cross-compile (i.e. could well be doing this
> > from Linux/Cygwin), the 2.9 libraries won't be available natively.
> > And Sun have said that they have no intention of open sourcing
> > Solaris before version 10. That would suggest the only way to get the
> > libraries may be to have the client send 200MB of files, probably not
> > an option. Our app is quite simple by the way, only using C++
> > standard libraries, no threading.
>
> If you have no sparc box at all, then in my opinion, the only sane
> approach is to go to ebay, pick up an older sparc box with solaris 9 for
> a few hundred bucks and then you can a) get your native headers/libs and
> b) actually be able to test!

Are we/you then not back with the original problem of depending on the 
old Sparc box in several years time?

Since our app is simple, it's not a problem for the client to run an 
updated version against the old version to check that everything works. 
However, asking them to mess around with system configuration and tar up 
half their system is another matter, hence the approach of "just get it 
working with minimum fuss".

If we can't build the cross-compiler with x86 Solaris libs, it does look 
like eBay is going to be the answer in the end (thanks for that link). 
As a final attempt - is there any reason why a statically compiled 
version of our app built with crosstools targetting Sparc shouldn't 
work? All the code is built targetting Sparc, and surely and glibc etc. 
functionality is in the binary?

--
sam brightman

--
For unsubscribe information see http://sourceware.org/lists.html#faq