AMD64 port

[Noah yan]

Matt,

under platform/pc32/, what do you mean to have a i386 folder and all
the source files in the folder, the are cpu-specific codes under
platform?
Yonghong

On 7/16/07, Matthew Dillon <dillon at apollo.backplane.com> wrote:
::However, there is not much point in that unless you also build some libraries, at least libgcc.a.  And for those we'd need the right kernel headers.
::
::Plus, what's the gain?  I can see the use on a 64 bit system, however.
::
::cheers
::  simon
:
:    It looks like just creating a subdirectory for each architecture
:    would be sufficient, e.g. /usr/lib/gcc34/i386/libgcc.a instead of
:    /usr/lib/gcc34/libgcc.a.
:
:    But that sort of change is not something I'd want to do for this
:    release, it would have to be post-release.
    Again, post-release, if we want to create a multi-target environment,
    we need to come up with a solution to /usr/lib, /usr/libexec, /usr/bin,
    /usr/sbin, /bin, /sbin, and so forth.  Even /usr/pkg/{bin,lib,libexec,sbin}
    could use the scheme.
    Maybe after this release is the time to finally use our varsym
    support!
    I was thinking having /usr/lib_i386, /usr/lib_amd64, etc and then
    making /usr/lib a varsym which points to the correct architecture.
    We would then do something similar for everything else.  /bin, /sbin,
    /usr/bin, /usr/sbin, /usr/libexec, /usr/pkg/{bin,lib,libexec,sbin}.
    It would be possible to maintain all the standard, expected places
    and yet still support multiple architecture targets.
                                        -Matt
                                        Matthew Dillon
                                        <dillon at backplane.com>