:
:Matthew Dillon wrote:
:> Well, then what we want is a new syscall vector, duplicate libraries,
:> and a compiler option, and leave all the function names the same
:> (which means no bintime but allows us to retain everything else).
:> -current would release supporting both with the compiler option
:> defaulting to --unix32 on the IA32 and --unix64 on 64 bit platforms,
:> and then down the line the compiler option would default to --unix64
:> on all platforms, and then down the line a little more the original
:> syscall vector would become a compatibility option that most people
:> leave out.
:
:
:Not to be a party-pooper, but I think this will fail as soon
:as you have a program that wants to link against a third party
:library that calls entry points in libc.
:
:It doesn't even have to be a binary-only thing; think of trying
:to build packages for the purposes of a CDROM distribution. You
:would end up needing to do the same "--unix32/--unix64" thing for
:every library you build.
:
:-- Terry
Well I figured one would just use the default for third party
libraries. The idea is to get the system sources working first
as well as support developers who need the feature, and worry
about ports and so forth later. Ports might not be able to use
64 bit functionality under 32 bit OSs until it becomes the default
under 32 bit OSs.
The moment we even *attempt* to introduce changes to things ports and
third part libraries use, we blow up half the ports tree. Oh, wait,
we've ALREADY blown up half the ports tree. On nearly every release!
Its one of the big complaints I hear about FreeBSD.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
