On 9/23/2010 1:37 PM, Rene Rebe wrote:
Porting the MIPS bits in dietlibc to 64 bit may only take some hours of trial
and error. In fact I may even do so the next days (donations welcome :-).
I looked at that dietlibc code a while ago, and tried to do some things so it would build
for mips64, but I gave up because there was too much mips32 specific assembly code in
there that would need porting, and my knowledge of Mips64 assembly was not sufficient to
do this in a reasonable amount of time, If you can find a way to bypass those assembly
code issues, or are not daunted by coding at that level, perhaps a few hours will do it.
You could mark dietlibc [R] - mips64 temporarily (in it's .desc).
Thanks for the tip.
I have a local mips64 glibc fix that i am just test build to check regressions
and hope to commit any minute.
The glibc solution is at the heart of the mips64 building troubles, I was never able to
get multilib working, so I bailed out into building it either as n64abi or n32abi. for
embedded purposes, it may still be good to let the user specify whether its multilib,
single lib n64 or single lib n32.
In building off the trunk as it is right now, I am getting the o32 abi libs in /lib and
the n32 abi libs in /lib64.
The question arises as to which libs really should be used where. The o32 abi libs are
the true old 32 bit libs which will allow the running of the ancient mips32 binaries on a
mips64 system, but the n32 abi libs are of more interest to someone running on modern
64bit hardware, and wants to maintain a 32 bit user space. the n32 abi relies on some
64bit hardware features, and is not usable on 32bit hardware, but it is still a 32 bit
abi, not a full 64bit abi. I think n32 would be the most common choice for a 32bit abi on
current Mips technology. I think the true n64 abi should be in /lib64. The question is:
does one library solution make sense for every one using Mips64, or should we let them
pick their own combos?
Jan
René
Sent abroad - http://ExactCODE.com Germany.
On Sep 23, 2010, at 18:51, Jan Rovins<[email protected]> wrote:
Thanks Rene for reviewing& committing pieces of that big patch.
I am starting to work again on the current trunk, just to see what will build
for Mips64.
would like to have the embedded, embedded-minimal, and generic-minimal
buildable for mips64
Right now, the biggest show stopper is dietlibc. I don't think it will be
ported to mips64 any time soon, so is there a way to leave it out of the
package list conditionally, when we are building a Mips64 target?
Jan
On 9/23/2010 9:21 AM, Rene Rebe wrote:
Hi,
On Sep 8, 2010, at 7:01 AM, Jan Rovins wrote:
<mips64-T2-R36064.patch>
Applied reworked tcl cross compile glue:
Index: package/base/tcl/tcl.desc
===================================================================
--- package/base/tcl/tcl.desc (revision 36064)
+++ package/base/tcl/tcl.desc (working copy)
@@ -26,9 +26,10 @@
[C] extra/development extra/tool extra/shell
>
+[F] CROSS
...
+ #JLR ? do we need seperate include paths for cross& non cross builds?
+ # or can $root$includedir work for native builds too?
Yes, we can!
+strtod_fix () {
+ export ac_cv_func_strtod=yes
+ export tcl_cv_strtod_buggy=1
+}
+
+if ! atstage native; then
+ hook_add preconf 4 strtod_fix
+fi
This can also be done more elegantly, see:
Committed revision 37666.
René
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[email protected] with a subject of: unsubscribe t2
