GCCSDK on Solaris/Sparc
david.marston at physics.org
Mon Jan 8 04:41:51 PST 2001
Nick Burrett wrote:
> David Marston <david.marston at physics.org> writes:
> > Nick Burrett wrote:
> > >
> > > David Marston <david.marston at physics.org> writes:
> > >
> > > > Error: File
> > > > '/home/riscos/gccsdk/arm-riscos-aof/libiberty/stage2/libiberty.o' is a
> > > > 'big endian' file. Drlink does not support these
> > >
> > > That's useful to know. It looks like we need to force `as' and `libfile'
> > > create little-endian files no matter what the endian-ness of the processor
> > > is.
> > >
> > > Nick.
> > I think I'm just confusing myself here. I've now changed as to do what
> > I think is create little-endian files, but now drlink complains about
> > gcc.o being big-endian! I've had a look at libfile, and to me it looks
> > like it is doing it in a way which will create little-endian files
> > anyway, so I'm wondering now whether it's drlink reading it wrong, and
> > it's actually as and drlink that need updating, rather than libfile.
> > Could you have a quick look at the drlink source (assuming you have it)
> > and see how it decides whether it's big or little-endian? One thing I
> > will try when I get home tonight is taking the gcc.o and libiberty.o
> > from the Solaris machine and try linking them with drlink on my Acorn to
> > see if they are right.
> > Am I barking up the wrong tree completely?
> I think there are big problems here.
> I've never used a big-endian machine so the whole issue confuses me since
> I'm not sure what endian-ness as, libfile and drlink are writing out.
> My assumption is that as, libfile, drlink are writing out files in the
> byte-sex of the host computer i.e. big-endian. However, I don't see
> why drlink should take issue with this because it should be reading
> a big-endian file, but the byte-sex should be OK since it is being
> read on a big-endian processor.
> Yours confused,
Sorry, sent this to the wrong place again:
OK. I'll give you an example of why I think libfile is doing it right
and as isn't. In libfile it stores everything in a buffer before it
writes it to the file. When it puts ints into this buffer it uses:
void Buffer::putInt(int a_data)
which as far as I can see will always store the least significant byte
first in memory whether the machine is bigendian or not. as doesn't do
this, it just writes the int directly to the file in which case on a big
endian machine it will end up with the most significant byte first (ie
You might be right that if libfile was persuaded to output in big-endian
format drlink wouldn't complain as everything would be big-endian and it
wouldn't notice, but I don't think this is really the best thing to do,
and I don't know what effect this would have on the executables.
I think we might be best to carry on this conversation tomorrow after
I've tried linking on my Acorn so we can be sure where the problem is.
More information about the gcc