Re: More on the OO 64-bit source

--===============8924217001180916438==
Content-Type: multipart/alternative; boundary="0-1592297939-1288301439=:983"

--0-1592297939-1288301439=:983
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Note there is also an officially supported Itanium 64-bit (ia64) release of=
 the latest OpenOffice. =A0 I do not have much depth of C-programming exper=
ience myself, but one of the people working on Itanium support + developmen=
t of the Red-Hat-based "Scientific Linux CERN" Linux OS once mentioned to m=
e that ia64 was a more "stringent" (or strict) 64-bit implementation than 6=
4-bit x86.=A0 His experience was such that source code upgraded from 32-bit=
 x86 to 64-bit x86 was not necessarily guaranteed to be up-to-snuff for bui=
lding "as is" on ia64 -- i.e., some additional 64-bit upgrades to the sourc=
e code are frequently required in order to build the code successfully on i=
a64.=A0=A0 Conversely 32-bit source code upgraded to adhere to the stricter=
 64-bit demands for building on ia64 were then fine building "as is" on 64-=
bit x86.

I can't say whether this is indeed true, or not -- and if true, whether the=
 existence of an Itanium release of OpenOffice has anything to do with gett=
ing those same source codes to build successfully on 64-bit Alpha platforms=
 -- but I thought it was an interesting claim that one could apparently get=
 away with certain legacy 32-bit programming practices on 64-bit x86 that w=
ere strictly forbidden on ia64.

-- Jim
=A0=20

--- On Thu, 10/28/10, Dialup Jon Norstog <[email protected]> wrote:

From: Dialup Jon Norstog <[email protected]>
Subject: More on the OO 64-bit source
To: "Linux on Alpha processors" <[email protected]>
Date: Thursday, October 28, 2010, 9:55 AM

To the list:

here is the port maintainer's clarification on 64-bit source code.

**********************************************************
On Thu, 2010-10-28 at 08:52 -0600, Jon Norstog wrote:
> Thanks for getting back to me, Caolan.=A0 So that means the 64-bit X-86=
=A0=20
> source is Alpha-friendly?

In theory at least it should build on Alpha. I ported the core bit, the uno
bridge, to Alpha some time ago. Its not like it gets built every day so par=
ts
mightn't work. Various workarouns like=20

configuring --with-system-python and/or --with-system-mozilla etc to avoid
building the in-tree copies and use the copy already installed might be
helpful to avoid any gotchas with those.

C.


_______________________________________________
axp-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/axp-list

--0-1592297939-1288301439=:983
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;">Note there is also an officially supported It=
anium 64-bit (ia64) release of the latest OpenOffice. &nbsp; I do not have =
much depth of C-programming experience myself, but one of the people workin=
g on Itanium support + development of the Red-Hat-based "Scientific Linux C=
ERN" Linux OS once mentioned to me that ia64 was a more "stringent" (or str=
ict) 64-bit implementation than 64-bit x86.&nbsp; His experience was such t=
hat source code upgraded from 32-bit x86 to 64-bit x86 was not necessarily =
guaranteed to be up-to-snuff for building "as is" on ia64 -- i.e., some add=
itional 64-bit upgrades to the source code are frequently required in order=
 to build the code successfully on ia64.&nbsp;&nbsp; Conversely 32-bit sour=
ce code upgraded to adhere to the stricter 64-bit demands for building on i=
a64 were then fine building "as is" on 64-bit x86.<br><br>I can't say wheth=
er
 this is indeed true, or not -- and if true, whether the existence of an It=
anium release of OpenOffice has anything to do with getting those same sour=
ce codes to build successfully on 64-bit Alpha platforms -- but I thought i=
t was an interesting claim that one could apparently get away with certain =
legacy 32-bit programming practices on 64-bit x86 that were strictly forbid=
den on ia64.<br><br>-- Jim<br>&nbsp; <br><br>--- On <b>Thu, 10/28/10, Dialu=
p Jon Norstog <i>&lt;[email protected]&gt;</i></b> wrote:<br><blockquot=
e style=3D"border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; paddi=
ng-left: 5px;"><br>From: Dialup Jon Norstog &lt;[email protected]&gt;<b=
r>Subject: More on the OO 64-bit source<br>To: "Linux on Alpha processors" =
&lt;[email protected]&gt;<br>Date: Thursday, October 28, 2010, 9:55 AM<br=
><br><div class=3D"plainMail">To the list:<br><br>here is the port maintain=
er's clarification on 64-bit source
 code.<br><br>**********************************************************<br=
>On Thu, 2010-10-28 at 08:52 -0600, Jon Norstog wrote:<br>&gt; Thanks for g=
etting back to me, Caolan.&nbsp; So that means the 64-bit X-86&nbsp; <br>&g=
t; source is Alpha-friendly?<br><br>In theory at least it should build on A=
lpha. I ported the core bit, the uno<br>bridge, to Alpha some time ago. Its=
 not like it gets built every day so parts<br>mightn't work. Various workar=
ouns like <br><br>configuring --with-system-python and/or --with-system-moz=
illa etc to avoid<br>building the in-tree copies and use the copy already i=
nstalled might be<br>helpful to avoid any gotchas with those.<br><br>C.<br>=
<br><br>_______________________________________________<br>axp-list mailing=
 list<br><a ymailto=3D"mailto:[email protected]" href=3D"/mc/compose?to=
[email protected]">[email protected]</a><br><a href=3D"https://www.r=
edhat.com/mailman/listinfo/axp-list"
 target=3D"_blank">https://www.redhat.com/mailman/listinfo/axp-list</a><br>=
</div></blockquote></td></tr></table>
--0-1592297939-1288301439=:983--


--===============8924217001180916438==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
axp-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/axp-list
--===============8924217001180916438==--