[NTLUG:Discuss] Re: AMD 64 Bit Distro -- your first 32/64-bit library issue

Justin M. Forbes 64bit_fedora at comcast.net
Sat May 8 11:17:41 CDT 2004


On Sat, May 08, 2004 at 12:16:31AM -0400, Bryan J. Smith wrote:
> 
> I'm just checking into this for a colleague on our list.  He downloaded
> the programs like Firefox from Mozilla, and GAIM from its project page,
> and expected no issues.  I, among others, have encouraged him to use the
> Apt/Yam capabilites for FC instead, to minimize issues.
> 
You will notice there are many issues with simply trying to rebuild
upstream applications on a multilib system.  I am trying to push fixes
upstream as I find them, other times I just fix it with packaging.  The
Fedora packaging actually can handle multilib very well, unfortunately
while the patches have been pushed upstream, they have not been merged. If
rebuilding upstream source against a RHEL 3 or a Fedora system, if things
dont work,try to libtoolize.

> The issue is that even though x86-64's 64-bit memory mode is backward
> compatible with i386 protected, you can't simply have 32-bit programs
> using 64-bit libraries, etc..., without extensive re-work.  Hence why
> Mozilla ships as a 32-bit program, so 32-bit plug-ins will work.
> 
Actually, there are several issues, memory mode is in fact one of them,
AMD 64 can use PAE when in Legacy mode, and it can limit 32bit applications
while in long mode, but 32bit applications could not use the 64bit memory
model. In addition, while in long mode, your registers are extended, and
there are twice as many of them in long mode.  While you may not notice the
difference in programming for these in C or the like, the assembler and
machine code is very different.  In order for a 64bit application to use a
32bit plugin/lib/etc, a thunking layer would have to be written, and the
idea of writing that code is not something I like to think about after a
meal. Doing the 32bit syscalls for the Fedora Core 1 kernel is about as
close as I am willing to get to such an idea.

> Right.  FC is using /usr/lib64 and other paths.  Symlinking to the non-
> 64-bit directories does not always solve the problem, because of the
> memory mode differences.
> 
Actually, this is not limited to FC.  The FHS calls for this, and I believe
all PPC64/390x/x86-64 and other multilib systems use this.  Sym linking
does not work for the reasons listed above.
 
> 
> Very, very cool!  GCC 3.3+ and kernel 2.6+ seem to be the combo for x86_64.
> Big thanks to SuSE for their early work with AMD to get this rolling, although
> I assume Red Hat has come on strong as of late as well (even HP, who co-
> designed IA-64, which is HP PA-RISC compatible, with Intel is now selling
> competing Opteron systes ;-).
>
For Fedora, x86_64 is now a tier one arch, which means it is just as
important as i386.  It is kind of interesting how some mindsets have
changed since I began working on this port back in September.  

> Thanx.  I'm wondering if I can help any?  I might have a lot of free
> time in the summer since I've left technology and am now a secondary
> education teacher (only working on my masters in education starting
> the end of this month).
> 
Testing and feedback is most important. While we are in code freeze for
Fedora Core 2, we will need testing on Extras (Fedora.us) as we roll out
x86_64, and of course the FC3 development cycle will start up soon.  Bug
reports are great, patches even better.

Thanks,
Justin



More information about the Discuss mailing list