Closed GoogleCodeExporter closed 8 years ago
One remark. We just need this for the partial linking step. So may be the flag
in the
file header must be set only. At the end we link with SX native linker which
will
look for it. The source files also compiled with SX native.
Original comment by danny.st...@gmail.com
on 11 Nov 2009 at 2:29
hmmmm ... can do, but ...
does this imply that no symbol in the object file uses size_t? (that is how I
understand "not depending on size of size_t type") or what exactly is the
meaning of
the flag?
Original comment by jmoc...@gmail.com
on 11 Nov 2009 at 5:42
No, it means that the size_t('s) in this object are compatible to both, to
size_t32
and to size_t64. You should find it in the SX ld source code how to handle it. I
don't know how it is implemented.
Original comment by danny.st...@gmail.com
on 12 Nov 2009 at 10:08
hmmm ... ok, will take a look ...
Original comment by jmoc...@gmail.com
on 12 Nov 2009 at 10:22
size_tmix option is implemented in r216. svn up, pls.
use it by passing --sx-option=size_tmix to ld (or, equivalently,
-Wl,--sx-option=size_tmix to gcc if that one is used to invoke the linker).
do report if it works properly ... ;)
Original comment by jmoc...@gmail.com
on 12 Nov 2009 at 11:27
So basically it seems to work. At least it does the same as SX native link does.
However I have a problem to use that feature as intended with both linkers.
I'll come
up later again if I found it out.
Original comment by danny.st...@gmail.com
on 13 Nov 2009 at 7:52
As understood the size_tmix is used to mark objects to compatible to both,
size_t32
and size_t64, because they do not include this data type. So it is harmless to
link a
size_tmix object to size_32/64 executable. At final linking step compatibility
is not
checked for this mixed object even if size_t is included.
Unfortunately this doesn't bring any benefit to us. ;-( However this option is
implemented correctly in SX GNU ld now. Thanks again!
Original comment by danny.st...@gmail.com
on 16 Nov 2009 at 11:07
Original issue reported on code.google.com by
danny.st...@gmail.com
on 11 Nov 2009 at 2:25