Re: 64-bit

2007/11/27, Justin Karneges <[email protected]>:
> Hi Isak,
>
> On Monday 26 November 2007 11:44 pm, Isak Savo wrote:
> > 2007/11/27, Justin Karneges <[email protected]>:
> >
> > Right now, you'd definitely need to bundle the runtime files, since we
> > don't have a 64-bit version of it on our web. Part of the runtime is
> > compiled c-code, so you'd need to compile it on a 64bit system.
>
> Can you describe how to do this?  It sounds like it is probably not the same
> as traditionally bundling the autopackage files.  I presume this also means
> the package becomes 64-bit-only?  (which is fine, that's what I was asking
> for.)  Can my application remain 32-bit even if it is wrapped in a
> 64-bit-only autopackage?

First you need to create autopackage.tar.bz2 and autopackage-gtk.x86:

Check out the full environment from svn, see
http://www.autopackage.org/source.html

Then, enter main/release/ and run:
   ./autopackage-build --gtkfe

This will create autopackage.tar.bz2 and autopackage-gtk-1.2.5.package
in the 1.2.5 subdirectory. These two files should be bundled with your
package.

Follow the devguide on how to make a sealed package (that contains
deps, including autopackage support code):
http://www.autopackage.org/docs/devguide/ch02s05.html

Let us know if something fails to build on 64bit (it should work - I
fixed this a while ago)

> > > 2) Is it possible to make a 32-bit package that works on both 32-bit or
> > > 64-bit platforms, with very minimal user instructions?  Something like
> > > "install the 32bit compat libs, then run our 32-bit application package"
> > > would be nice.  I saw this idea mentioned during my searches, but it
> > > wasn't stated confidently (I get the impression that none of the AP devs
> > > have 64-bit systems...).
> >
> > In theory, this is exactly how it's supposed to work. Problem is, from
> > what I understand the user needs to have 32bit compatibility libs for
> > ALL the app's dependencies. Many distros provide a bunch of base stuff
> > (including X11, GTK etc.) as 32bit compat libs, but more exotic
> > libraries might be missing.
>
> I should be able to provide my own 32-bit packages for the "exotic" libraries
> in our application package file (or via URLs to our company website)
> shouldn't I?  It seems to me like compat libs shouldn't be a problem unless a
> distro is missing 32-bit compat libs on base libraries.

Yes, problem is our detection system is not aware of 32bit vs 64bit.
It might pass a dep check if it finds the 64bit version, not sure. (I
*think* we have checks against that, but I don't remember)

> > One issue with this is our detection system. It is very hard to
> > programatically determine if the users system is 32bit compatible or
> > not (it'd require that all our dependency checking API functions
> > became aware of this, not to mention all distros put the 32bit libs in
> > different locations.)
>
> Hmm, it sounds like the 32-bit compat approach is not very reliable then.  Two
> questions about this:
>
> 1) Is it possible to make 32-bit compat reliable?

To some extent, yes. By making the autopackage API fully 64/32bit
aware so that it can determine whether the compat version of a lib is
installed or not.

One thing to tackle is where do we install 32bit libs/binaries on a
64bit distro? I'm sure they all have different locations (they always
do).

> 2) Ultimately, do we really need 32-bit compat?  If we can get a dual package
> that contains both 32-bit and 64-bit binaries, then you'd never use compat.

It's a nice thing for situations where the developer doesn't have
access to a 64bit machine, and can't build native 64bit packages
(hmm.. cross compilation should work, shouldn't it?)

> > A good middle step I think would be to allow 64bit only packages to work.
>
> And what is left for this to work?  Compile the autopackage runtime as 64-bit?

Basically, yes. And of course fix all the minor issues that will pop
up during that process ;-)

> What is left to support autopackages containing both 32-bit and 64-bit?

Once the API is upgraded to handle it, we just need to put both
binaries in the package. We already have a mechanism for dealing with
two C++ ABI's (see
http://trac.autopackage.org/wiki/C%2B%2BSupportIn1.2 ) which should be
usable for 64/32bit hybrids aswell.

Not sure how modular that code is though, since I wasn't involved in
writing it...

> > We fix minor bugs here and there, and for most people Autopackage
> > works quite well. But none of us has the time or energy to do big
> > changes.
> >
> > BUT. There's always a but. If you are willing to invest some time in
> > looking into making autopackage more 64bit friendly I will certainly
> > assist you in doing that. Maybe Taj and Curtis can help too.
>
> Great, then here I am. :)

Awesome!

-Isak

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