Re: 64 bit support, finally!

On Sun, Apr 20, 2008 at 2:55 PM, Jan Niklas Hasse <[email protected]> wrote:
> >  >  After my patch it should be possible to compile autopackage on 64 and
>  >  >  (!!!!) create true x86_64 packages! It's also possible to create
>  >  >  Hybrid-Packages (containing both binaries): Just set CpuArchitectures
>  >  >  to "x86 x86_64" and install the correct binary (I haven't tested it
>  >  >  though).
>  >
>  >  How would this work in practice for packagers? I assume we
>  >  (autopackage) would provide an x86_64 version of the support code +
>  >  frontends, but how would packagers do to provide both 64 and 32 bit
>  >  versions of their packages?
>
>  They would need to import both binaries and then do something like this:
>
>  if [[ $(uname -m) == "x86_64" ]]; then
>     installExe bin64/foobar
>  else
>     installExe bin32/foobar
>  fi
>
>  It would be better to provide something like GCCABI2 which
>  automatically creates patches.

Either that, or just create separate packages form x86 and x86_64 and
have the user choose the correct one depending on his system. But the
more we can do automatically, the better...

>
>  >  I.e. is it possible to cross compile to x86_64 binaries on a x86 system?
>
>  Do you mean compiling x86_64 binaries on a x86 system? I think that's
>  not possible, but it's possible to create x86 binary on a x86_64
>  system with a special compiler switch (i will look this up and do some
>  testing).

Ok. It *should* be possible to cross compile to 64bit from a vanilla
32 bit system. I mean, it shouldn't be harder to do that than cross
compile to a completely different target like say, ppc or arm which is
clearly possible.

>  >  Is CpuArchitectures a flag set in the .aspec? How will this affect
>  >  backwards compatibility?
>
>  You can set it in the .aspec file, but if you don't, it will
>  automatically set itself to the system you are currently running.
>  Backwards compatibility might be a problem, i haven't tested that.

Ok, just asking in case you'd already thought of any issues.
Basically, there are a few gotchas with backwards compatibility for
autopackage:
 * It is not always certain that the user will have the latest support
code installed. Even if your package is built against 1.2 or svn,
autopackage will not update the users version of the support code if
its already there. (You can force a 1.0.x to 1.2.x upgrade by setting
AutopackageTarget in the .apspec though)
 * The package stub cannot call new functions unless we take care to
version protect the calls (this is what caused the entire _checkEULA
mess a couple of months ago)
* The support code must be able to handle any version of a package,
which means behaviour from deprecated .apspec variables must remain
the same.

That said, I can't see any direct problems with adding new metadata
keys, except perhaps that its good practice to only do so in minor
version updates (like in this case, bumping the version to 1.3 to
indicate new functionality)

>  >  >  Autopackage now determines whether it has got a x86_64 package and
>  >  >  only searches for proper libraries. Examples:
>  >
>  >  I'm not sure I understand the tables below. Is 'arch' the architecture
>  >  of the package or the users system? etc.
>
>  The user system. "package" is the archtecture of the package and
>  "libraries" is the sort of libraries autopackage will check for.

Ok.

>  >  >  I hope everyone helps my testing it, I'm very often on IRC (nick:
>  >  >  jhasse). Feel free to highlight me.
>  >
>  >  We'd need some people with access to 64bit systems to try this. Is
>  >  there anyone on this list who can help testing this??
>
>  Yeah, it certainly needs more testing. I'm trying to set up VMware
>  today, so that i can test on several different machines.

Awesome. I wonder if vmware can run a 64bit guest OS on 32bit hardware
thought.. Do you know if that's possible?

-Isak

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/[email protected]
For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/[email protected]