Hi,
On Sep 23, 2010, at 20:13 , Jan Rovins wrote:
> 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.
well, I'm doing such stuff for years.
>> 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?
Personally I would set it up like powerpc64, or x86-64, that is default to the
full 64bit binaries in lib64 and have fully backward compatible lib/ support to
support running the vanilla 32bit binaries of the architecture, which for MIPS
would mean o32.
I see little benefit in supporting the n32 variant. Of course anyone is free to
setup his target to build n32 if they want to gain the extra performance %
digit, ... But as outlined I would default to reasonable choices, the efforts
to keep them working are already high enough. The Linux kconfig has this:
Select this option if you want to run n32 binaries. These are
64-bit binaries using 32-bit quantities for addressing and certain
data that would normally be 64-bit. They are used in special
cases.
If unsure, say N.
So this would mean fixing trunk to built n64 binaries instead of n32 gcc is
apparently (accidentally) defaulting to.
René
> 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é
>>>>
>
--
René Rebe, ExactCODE GmbH, Jaegerstr. 67, DE-10117 Berlin
http://exactcode.com | http://t2-project.org | http://rene.rebe.de
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[email protected] with a subject of: unsubscribe t2
