Why isnt Arch 64 Multilib?

Enverex · 2007-06-13 09:06:42

As per the title, why was it chosen to keep it ¨pure" which as far as Im aware has no benefits and means youŕe unable to compile some 32bit things. Just seems like an annoying infuriating (I know for me and at least one other person I was talking to earlier) thing to do. I refuse to use a chroot because itś messy, longwinded, a waste of space and requires screwing about with rebinding mounts.

To anyone that thinks it already has multilib: bunging a few 32bit libraries in doesn make it multilib, gcc and glibc need to be compiled as multilib, which they arent.

Excuse the awful typing, this machine is being retarded and the UK keymap doesn appear to work properly, it renders lots of the keys useless, a few wrong and some dead.

[vEX] · 2007-06-13 09:20:22

Quote from http://wiki.archlinux.org/index.php/Arc … _Arch64.3F:

BUT: Our goal is to be the most bleeding edge distribution around! 32-bit is old fashioned. We want Arch64 to be modern and pure 64-bit. So we don't have a Multilib system. We won't take any package into the repos improving 32-bit compatibility. Maybe we will place them into the AUR or community repo. Don't expect any support from the devs getting 32-bit apps running on Arch64!

Not sure if that is a satisfiable answer to you though.

Enverex · 2007-06-13 10:14:38

I read that before and it doesn make much sense to be honest. Having gcc and glibc doesnt make a distro not bleeding edge nor does it negatively impact it in any way. The only thing not having multilib does it mean that people that need to compile 32bit apps cant. There are some apps that CANNOT be compiled 64bit.

Note that itś not that i need to be able to install a 32bit app, its that i specifically need to be able to compile it.

again, sorry if this is hard to read, i pretty much dont have any special characters or anything, what is wrong with the uk international keymay on arch?

AndyRTR · 2007-06-13 11:23:01

it doesn't make sense to include the 32bit crap and compatibility into the most bleading edge 64bit distribution. there's not much left in the open source world that can't be compiled in true 64bit. last gaps will soon be closed. see gnash, gcj java browser applet and more.

but if you like you can simply replace gcc/glibc with multilib versions...

Enverex · 2007-06-13 11:27:02

AndyRTR wrote:

it doesn't make sense to include the 32bit crap and compatibility into the most bleading edge 64bit distribution. there's not much left in the open source world that can't be compiled in true 64bit. last gaps will soon be closed. see gnash, gcj java browser applet and more.
but if you like you can simply replace gcc/glibc with multilib versions...

Building GCC and GLibC with multilib doesn't suddenly make the distro not "bleeding edge". There are also things that CANNOT be compiled 64bit, for instance Wine. Please don't point me to the pre-built one, I'm a developer and need to be able to build the source (without using a chroot either, now THOSE are messy).

I've spent 10 hours or so now arsing around trying to get this to work and I'm quickly losing my rag. GCC WILL NOT build if I edit the PKGBUILD to enable multilib, it fails with:

make[5]: Entering directory `/var/abs/base/gcc/src/gcc-4.2.0/build/gcc'
/var/abs/base/gcc/src/gcc-4.2.0/build/./gcc/xgcc -B/var/abs/base/gcc/src/gcc-4.2.0/build/./gcc/ -B/usr/x86_64-unknown-linux-gnu/bin/ -B/usr/x86_64-unknown-linux-gnu/lib/ -isystem /usr/x86_64-unknown-linux-gnu/include -isystem /usr/x86_64-unknown-linux-gnu/sys-include -O2 -O2 -march=x86-64 -O2 -pipe  -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include  -I. -I32 -I../../gcc -I../../gcc/32 -I../../gcc/../include -I../../gcc/../libcpp/include  -I../../gcc/../libdecnumber -I../libdecnumber -m32 -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder  -fno-omit-frame-pointer -fno-asynchronous-unwind-tables \
          -c ../../gcc/crtstuff.c -DCRT_BEGIN \
          -o 32/crtbegin.o
In file included from /usr/include/features.h:345,
                 from /usr/include/stdio.h:28,
                 from ../../gcc/tsystem.h:90,
                 from ../../gcc/crtstuff.c:68:
/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory

So, either do you know of an existing multilib glibc and gcc I can use (preferred) or how to fix this to build them it would be appreciated.

AndyRTR · 2007-06-13 11:39:05

Enverex wrote:

So, either do you know of an existing multilib glibc and gcc I can use (preferred) or how to fix this to build them it would be appreciated.

nobody so far really wanted to do this. there's only one way to go: rebootstrap Arch64 all from the beginning using the cross-linuxfromscratch book. good luck.

Enverex · 2007-06-13 11:45:39

AndyRTR wrote:

Enverex wrote:
So, either do you know of an existing multilib glibc and gcc I can use (preferred) or how to fix this to build them it would be appreciated.
nobody so far really wanted to do this. there's only one way to go: rebootstrap Arch64 all from the beginning using the cross-linuxfromscratch book. good luck.

That's out of the question, I may as well use Gentoo (which I really don't want to). I had such high hopes for Arch because I love the package manager etc, but, this just isn't going to work. *sighs*

dongiovanni · 2007-06-13 12:05:29

There are the lib32-* packages in the community repository. I am using them for skype (although i don't like this solution very much).
I think, that's good, that there are no multilibs, so the distribution is much smaller! (KISS)

Enverex · 2007-06-13 12:08:02

dongiovanni wrote:

There are the lib32-* packages in the community repository. I am using them for skype (although i don't like this solution very much).
I think, that's good, that there are no multilibs, so the distribution is much smaller! (KISS)

Those libs are no use for building this. "much smaller"? You are aware that it saves a few meg max? At the expense of losing quite a bit of compatability. That's a really bad trade-off, but judging from the reponses no-one will agree with me anyway.

kth5 · 2007-06-13 12:43:20

Enverex wrote:

AndyRTR wrote:
Enverex wrote:
So, either do you know of an existing multilib glibc and gcc I can use (preferred) or how to fix this to build them it would be appreciated.
nobody so far really wanted to do this. there's only one way to go: rebootstrap Arch64 all from the beginning using the cross-linuxfromscratch book. good luck.
That's out of the question, I may as well use Gentoo (which I really don't want to). I had such high hopes for Arch because I love the package manager etc, but, this just isn't going to work. *sighs*

If you want 32bit apps, run regular Arch i686. What's the big problem?

I don't see a reason to make Arch x86_64 multilib either, for that use AUR lib32-* or chroot like I do. We won't have any applications left that do not support 64bit in about a year or so. The only ones I know that do not work so far are:

* pcsx
* pcsx2
* flashplugin
* wine
* codecs in mplayer/xine

Especially the last one is an really really oldfashioned thing to do even on 32bit as mplayer comes with all decent codecs. Nobody should be using anything else. Same thing for flashplugin. Wine? I don't know for what if not gaming one would need it. so optional too.

I hear you want 32bit here, and 32bit there. Why exactly? What do you need to run? Why does a pure 64bit distro keep you from using it?

skottish · 2007-06-13 13:22:55

I don't know if this helps you Enverex, but the stubs-32.h file is easy enough to get:

/* This file is automatically generated.
   It defines a symbol `__stub_FUNCTION' for each function
   in the C library which is a stub, meaning it will fail
   every time called, usually setting errno to ENOSYS.  */

#ifdef _LIBC
 #error Applications may not define the macro _LIBC
#endif

#define __stub___kernel_cosl
#define __stub___kernel_sinl
#define __stub___kernel_tanl
#define __stub_chflags
#define __stub_fattach
#define __stub_fchflags
#define __stub_fdetach
#define __stub_futimens
#define __stub_gtty
#define __stub_lchmod
#define __stub_lutimes
#define __stub_revoke
#define __stub_setlogin
#define __stub_sigreturn
#define __stub_sstk
#define __stub_stty
#define __stub_utimensat

.:B:. · 2007-06-13 13:51:06

As Andy says - pure 64 bit is the way to go. I really don't get why people who 'want' to run 64 bit make the switch but want to run heaps of 32 bit apps on top of it. It only takes more work to make them run and in the end what benefit do you have from the 64 bit base? Nothing.

If really want to run 64 bit, the 32 bit thingies shouldn't be an issue at all. Multilib is a compromise, it's a bit like running Windows apps on Linux imho.

Enverex · 2007-06-13 14:11:09

kth5 wrote:

for what if not gaming one would need it. so optional too.

I'm a Wine dev, I NEED Wine to work (to be able to compile it manually) but yeah, enough of this. People are telling me what I should and shouldn't want to do and that doesn't help in the slightest. Thanks to anyone that did try and help before, telling me to use 32bit system for one app is not a good answer.

I'll find something else.

kth5 · 2007-06-13 15:08:13

Well, why doesn't wine work on 64bit? I don't really get it either. When I want wine I run it from a chroot, works well and keeps the rest of the system uncluttered by 32bit stuff which after is a burden. Keeping every package twice to make it a full multilib system is just as much work as it is to quickly create a chroot somewhere.

Last edited by kth5 (2007-06-13 15:08:47)

KerowynM · 2007-06-13 20:44:01

I suppose telling the devs they need to make the distro the way one person wants it isn't the way to go either. Build your own multilib packages like the rest of us would. Arch is about giving a simple base from which to customize as you see fit. If you see fit to add multilib, then do it. If not, too bad. Don't expect the entire distro to bend to your will.

Last edited by KerowynM (2007-06-13 20:44:43)

lloeki · 2007-06-14 09:07:01

Well, why doesn't wine work on 64bit?

because it implements 32bit windows api, and thus expects results to be behaving like 32bits, not 64bits (think limit cases like carries, pointers, etc...) and you can't just truncate 64bits to obtain 32bits. thus as of now, wine has to be compiled as 32bit.
running a 32bit windows app (is there any real 64bit windows app anyway?) on a supposedly pure 64bit wine would then require wine to implement a 32bit compatibility layer inside wine, which is a sure daunting process (but I heard they're working on it)

whatever, asking for multilib (only necessary for compilation, at runtime lib32- is sufficient for non-broken apps) is like asking for cross-compilation. what would you say if one cried because there's no arm or mips support in arch's gcc? besides, running a chroot for building a 32bit app is really much less a hassle than rebootstrapping.

that said, I feel the arch64 stance is a bit harsh. I think ruling out any form of 32bit is hampering 64bit progress: it would e.g bring some more users, translating directly into potential reporters, testers, maintainers that will progressively drop their 32bit habits...
for that, chroot is good, but not as convenient as lib32 (e.g when apps need to call each other). that's why I think lib32 deserves some more loving (e.g in the wiki). besides, writing a lib32 PKGBUILD is generally a straightforward and (for most packages) automatable process.

Wine? I don't know for what if not gaming one would need it. so optional too.

there are companies that transition from legacy home built sh*t windows apps to linux, and need a bunch of them, so they need wine.
as for gaming, linux is a wonderful gaming platform, and sadly I have not much satisfaction at playing open games as of today (there are good ones, but just not the ones I like to play) so I play doom3, guild wars, cnc3, homeworld 2, and so on.

see gnash, gcj java browser applet and more.

gnash is flash<7, when 9 is everywhere, and even then, it's unstable and bad behaving, esp. when there is interaction involved.
gcjwebapplet is totally unsecure (and won't for a long time) and totally inefficient. I did not manage to get anything but a solid colored area (black or grey) for any applet I tried.

that said, I too dream of the day where everything would be both opensource, portable and efficient, but that's not the case yet, nor in the coming years.

whatever, the subject is debatable (and certainly has been debated) to death, the distro is heading in a clear direction and keeps it, going in circles would be the worst thing.

Last edited by lloeki (2007-06-14 09:08:52)

Stalwart · 2007-06-16 10:15:47

What's the problem with 32bit apps? Just fetch lib32-* pkgs and run apps. I have opera, flash9 and skype running great

Enverex · 2007-06-17 17:05:33

KerowynM wrote:

I suppose telling the devs they need to make the distro the way one person wants it isn't the way to go either. Build your own multilib packages like the rest of us would. Arch is about giving a simple base from which to customize as you see fit. If you see fit to add multilib, then do it. If not, too bad. Don't expect the entire distro to bend to your will.

That isn't possible, you have to rebuild the ENTIRE system, you may as well just use LFS instead, it would be less hassle.

Stalwart wrote:

What's the problem with 32bit apps? Just fetch lib32-* pkgs and run apps. I have opera, flash9 and skype running great

*sighs* Did you even read the thread?

Thanks lloeki for at least trying but it seems like there is no-way this is gonna work without a chroot. Wine creates menu entries in the Gnome menu for Windows apps that are installed for instance. Installing inside a chroot means that those aren't going to work (which complicates running them and also means I can't test if they are working properly). That is unless I'm missing some magic chroots can do to somehow integrate completely with the main host system?

lloeki · 2007-06-17 17:15:58

I use wine with lib32-* without any hassles.

if you want to build 32bit e.g wine on 64bit, then setup a chroot, makepkg wine there, then copy the pkg outside the chroot, makepkg as lib32- so that it ends up in /opt/lib32, and pacman -U. that's it.

this way you can both build wine in a chroot, and have the benefits of lib32 (i.e not the hassles of chroot). basically your chroot is only a build environment, and then you drop the 64bit refactored packages into your 64bit system.

Last edited by lloeki (2007-06-17 17:18:35)

Enverex · 2007-06-17 17:26:34

lloeki wrote:

I use wine with lib32-* without any hassles.
if you want to build 32bit e.g wine on 64bit, then setup a chroot, makepkg wine there, then copy the pkg outside the chroot, makepkg as lib32- so that it ends up in /opt/lib32, and pacman -U. that's it.
this way you can both build wine in a chroot, and have the benefits of lib32 (i.e not the hassles of chroot). basically your chroot is only a build environment, and then you drop the 64bit refactored packages into your 64bit system.

True, but when I'm regression testing I may need to build Wine up to 50 times or so using GIT. Can you imagine how much time having to go through that processes each time is going to add to the amount of time it all takes? heh.

lloeki · 2007-06-17 17:42:58

well then, that's two different use cases

use the gnome links with wine with lib32- outside your chroot, but do regression testing inside your chroot?

plus you can certainly script what's above in 2*20 lines of bash (one srcipt inside chroot, chroot-called by one outside)

even if it adds some overhead, it certainly doesn't cost more than a full-rebootstrapping.

Last edited by lloeki (2007-06-17 17:43:28)

kth5 · 2007-06-18 12:37:01

lloeki wrote:

plus you can certainly script what's above in 2*20 lines of bash (one srcipt inside chroot, chroot-called by one outside)
even if it adds some overhead, it certainly doesn't cost more than a full-rebootstrapping.

http://kth5.telekommunisten.net/makeroot/

Arch Linux

#1 2007-06-13 09:06:42

Why isnt Arch 64 Multilib?

#2 2007-06-13 09:20:22

Re: Why isnt Arch 64 Multilib?

#3 2007-06-13 10:14:38

Re: Why isnt Arch 64 Multilib?

#4 2007-06-13 11:23:01

Re: Why isnt Arch 64 Multilib?

#5 2007-06-13 11:27:02

Re: Why isnt Arch 64 Multilib?

#6 2007-06-13 11:39:05

Re: Why isnt Arch 64 Multilib?

#7 2007-06-13 11:45:39

Re: Why isnt Arch 64 Multilib?

#8 2007-06-13 12:05:29

Re: Why isnt Arch 64 Multilib?

#9 2007-06-13 12:08:02

Re: Why isnt Arch 64 Multilib?

#10 2007-06-13 12:43:20

Re: Why isnt Arch 64 Multilib?

#11 2007-06-13 13:22:55

Re: Why isnt Arch 64 Multilib?

#12 2007-06-13 13:51:06

Re: Why isnt Arch 64 Multilib?

#13 2007-06-13 14:11:09

Re: Why isnt Arch 64 Multilib?

#14 2007-06-13 15:08:13

Re: Why isnt Arch 64 Multilib?

#15 2007-06-13 20:44:01

Re: Why isnt Arch 64 Multilib?

#16 2007-06-14 09:07:01

Re: Why isnt Arch 64 Multilib?

#17 2007-06-16 10:15:47

Re: Why isnt Arch 64 Multilib?

#18 2007-06-17 17:05:33

Re: Why isnt Arch 64 Multilib?

#19 2007-06-17 17:15:58

Re: Why isnt Arch 64 Multilib?

#20 2007-06-17 17:26:34

Re: Why isnt Arch 64 Multilib?

#21 2007-06-17 17:42:58

Re: Why isnt Arch 64 Multilib?

#22 2007-06-18 12:37:01

Re: Why isnt Arch 64 Multilib?

Board footer