Hi,
Le 5 févr. 10 à 10:15, Caolán McNamara a écrit :
On Fri, 2010-02-05 at 09:19 +0100, eric b wrote:
Till now we have tested DEV300_m58 and DEV300_m60, the breakage
took place in the latter but not the former one.
And it was *definitely* the same compiler and tool chain used in
both cases right ? And the error in question is ...
Exactly : both tree on the same machine : rebuild comphelper with
DEV300_m57, and DEV300_m58 is ok.
Starting m60 -> you have the issue below
comphelper/source/container/enumerablemap.cxx
{standard input}: Assembler messages:
{standard input}:714: Error: opcode not supported on this
processor: mips1
(mips1) `ll $3,8($4)'
This massively looks like a toolchain issue to me
To me too
and not an OOo one. e.g. binutils/gcc target mismatch or some foo
like that.
Well, this must be investigated anyway. I'd better vote for one
option like "all linux by default" or something like that. But again,
I can be wrong : I work on that just a little time per day, in my
free time.
I imagine that we're talking about the "normal" mips o32 abi
right ?, the one that gcc defaults to out of the box for mips-linux-.
Yes, we are. I do the chroot (linux32) like you suggested, and it was
working fine. Until one change I ignore.
There shouldn't be anything really different about mips during the
build until bridges and the bridge test in testtools. e.g. there is
nothing in comphelper that has any mips specific stuff in there.
The issue occurs in compheelper, but we agree the root is not in
comphelper. A t least, this is obvious for me.
Thanks for your time :)
Eric
--
qɔᴉɹə
