Ticket #10 (closed Enhancement: fixed)

Opened 2 years ago

Last modified 2 months ago

Multi-arch support

Reported by: taj Assigned to: Jan-Nik
Priority: Low Milestone: 1.3
Component: main Version: development
Severity: Normal Keywords: 64bit
Cc:

Description

People want support for 64bit systems. LLVM might be the way forward here.

Attachments

x86_64.diff (12.2 kB) - added by Jan-Nik on 04/20/08 16:43:04.
adding x86_64 support; apgcc64.patch needs to be applied too
apgcc64.patch (1.0 kB) - added by Jan-Nik on 06/08/08 10:14:11.
Here's a very little patch which lets 64 bit users use apgcc too.
x86_64-1.3.diff (38.3 kB) - added by Jan-Nik on 07/12/08 13:15:14.
new AutopackageTarget 1.3. Replaces x86_64.patch, but apgcc64.patch needs to be applied to

Change History

04/01/07 16:47:20 changed by taj

  • owner deleted.

04/01/07 16:50:20 changed by taj

  • priority changed from Medium to Low.

04/02/07 18:46:42 changed by thelusiv

I think this should be a higher priority... :)

One issue for 64-bit support is identifying libraries that may live in alternative locations like /lib64.

Does the scope of this ticket include PPC support and other architectures as well? Also, is the plan for developers to create different packages for each architecture, or create one package that works on any architecture?

04/03/07 12:00:58 changed by taj

Does the scope of this ticket include PPC support and other architectures as well?

Yes.

Also, is the plan for developers to create different packages for each architecture, or create one package that works on any architecture?

One package, kind of like the universal binaries on Mac OS X. Using LLVM, we package up LLVM bytecode that is then "compiled" on the target system on install. This would make the packages installable everywhere, unless, of course, they contain ASM. (It would also make it so the developer wouldn't need to have other architectures. )

Actually, I don't know how LLVM handles ASM--it'd be good to look into.

04/05/07 17:21:02 changed by isak

I see two different sets of improvements here.

  1. Make autopackage's buildable and installable on intel/amd x86-64 systems which CPU's are compatible with x86-32 systems. This is probably a medium priority thing and boils down to making sure that autopackage treats x86-64 systems as 32-bit systems as long as they contain the 32bit compat libs. My estimate is that this is a pretty low hanging fruit with not so much code change.
  2. Make it possible to create true architecture dependent packages. For instance foobar-1.2.3-ppc.package or foobar-1.2.3-arm.package. This is IMO low priority and it requires lots of work.

Doing 1) above is something we should focus on for now. If someone else steps in and want to take a shot at solving 2), I'm all for it. But I can't really see it being done within the current limited manpower we have right now.

There might also be a 1.5, which would be to add support for x86-64 only (ignoring PPC, etc), since that's where the biggest demand is right now.

12/29/07 16:48:36 changed by isak

  • keywords set to 64bit.

04/20/08 16:43:04 changed by Jan-Nik

  • attachment x86_64.diff added.

adding x86_64 support; apgcc64.patch needs to be applied too

06/08/08 10:14:11 changed by Jan-Nik

  • attachment apgcc64.patch added.

Here's a very little patch which lets 64 bit users use apgcc too.

07/12/08 13:15:14 changed by Jan-Nik

  • attachment x86_64-1.3.diff added.

new AutopackageTarget 1.3. Replaces x86_64.patch, but apgcc64.patch needs to be applied to

(follow-up: ↓ 8 ) 08/03/08 15:24:07 changed by Jan-Nik

  • owner set to Jan-Nik.

I thought about this. IMHO we should create a new command called aphybrid or something like this, which takes two identical package files (but with different architectures) and automatically creates a new package which is installable on both architectures (using binary patches).
It's just an idea, what do you think of it?

(in reply to: ↑ 7 ) 08/03/08 17:18:42 changed by isak

Replying to Jan-Nik:

I thought about this. IMHO we should create a new command called aphybrid or something like this, which takes two identical package files (but with different architectures) and automatically creates a new package which is installable on both architectures (using binary patches).
It's just an idea, what do you think of it?

I think it sounds cool. Autopackage's goal has always been to make it as easy as possible to the end users. Your idea definitely sounds like it's aligned with those goals!

08/04/08 19:28:45 changed by Jan-Nik

Great, I'm trying to implement it then next week.

Another thing: There are shared library files in libexec. I wasn't able to compile libuau.so. It looks like the following case: http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3#doc_chap7

Is the luau project dead? There wasn't a new release since 2005: http://luau.sourceforge.net/

What is luau used for anyway?

08/12/08 10:57:32 changed by add

http://www.salewroughtiron.cn installing metal stair rails Interior stair handrail installing metal stair rails Interior stair handrail exterior baluster Glass wood stainless wrought CONTEMPORARY designs stairways aluminum modern log banister DECK outdoor price posts vinyl curved rails http://www.china-made-door.com.cn door gate http://www.beijing-door.cn wrought CONTEMPORARY designs stairways installing metal stair rails Interior stair handrail exterior baluster Glass wood stainless wrought CONTEMPORARY designs stairways aluminum modern log banister DECK outdoor price posts vinyl curved rails http://www.hebei-railings.cn aluminum modern log banister DECK outdoor price installing metal stair rails Interior stair handrail exterior baluster Glass wood stainless wrought CONTEMPORARY designs stairways aluminum modern log banister DECK outdoor price posts vinyl curved rails posts vinyl curved rails

08/21/08 15:56:31 changed by Jan-Nik

  • status changed from new to closed.
  • resolution set to fixed.

Closing this as fixed now. Compilation with apgcc under 64 bit still doesn't work, but that's because of #20.