[aur-general] multilib

newer
[aur-general] voting period: Brad...

Nathan O

6 Sep 2010 6 Sep '10

11:39 p.m.

I installed the x86_64 version of Arch, and I was looking at the wiki on running 32-bit apps in a 64-bit environment which seems what the multilib project/repo does. Though If I try and do pacman -S gcc-multilib gcc-libs-multilib binutils-multilib libtool-multilib lib32-glibc. Pacman gives me that binutils and binutils-multilib conflict. Do I let multilib's version replace it? Mainly I want to build i686/x86_64 packages and make sure they work fine on both architectures as well, maybe with running a few 32-bit only applications if I come across them. Thanks

Show replies by date

Gary Wright

7 Sep 7 Sep

1:19 a.m.

On Mon, Sep 6, 2010 at 5:39 PM, Nathan O wrote:

...

I installed the x86_64 version of Arch, and I was looking at the wiki on running 32-bit apps in a 64-bit environment which seems what the multilib project/repo does. Though If I try and do pacman -S gcc-multilib gcc-libs-multilib binutils-multilib libtool-multilib lib32-glibc. Pacman gives me that binutils and binutils-multilib conflict. Do I let multilib's version replace it? Mainly I want to build i686/x86_64 packages and make sure they work fine on both architectures as well, maybe with running a few 32-bit only applications if I come across them.

Thanks

Sadly enough, its been a while since I've booted into a linux environment. (mostly because since xorg 1.6/kernel 2.6.26 my radeon 9800 just doesn't work all that well anymore.) But such queries might be answered better on the multilib mailinglist: http://mailman.archlinux.org/mailman/listinfo/arch-multilib Also, to answer your question: http://lmgtfy.com/?q=binutils+and+binutils-multilib+conflict Its the first result :) Gary.

Nathan O

2:49 a.m.

On Mon, Sep 6, 2010 at 8:19 PM, Gary Wright wrote:

...

On Mon, Sep 6, 2010 at 5:39 PM, Nathan O wrote:

...
I installed the x86_64 version of Arch, and I was looking at the wiki on running 32-bit apps in a 64-bit environment which seems what the multilib project/repo does. Though If I try and do pacman -S gcc-multilib gcc-libs-multilib binutils-multilib libtool-multilib lib32-glibc. Pacman gives me that binutils and binutils-multilib conflict. Do I let multilib's version replace it? Mainly I want to build i686/x86_64 packages and make sure they work fine on both architectures as well, maybe with running a few 32-bit only applications if I come across them.

Thanks

Sadly enough, its been a while since I've booted into a linux environment. (mostly because since xorg 1.6/kernel 2.6.26 my radeon 9800 just doesn't work all that well anymore.) But such queries might be answered better on the multilib mailinglist:

http://mailman.archlinux.org/mailman/listinfo/arch-multilib

Also, to answer your question:

http://lmgtfy.com/?q=binutils+and+binutils-multilib+conflict

Its the first result :)

Gary.

Off topic, have you tried the xf86-video-ati driver to see if it will work?

Rémy Oudompheng

6:49 a.m.

Nathan O wrote:

...

I installed the x86_64 version of Arch, and I was looking at the wiki on running 32-bit apps in a 64-bit environment which seems what the multilib project/repo does. Though If I try and do pacman -S gcc-multilib gcc-libs-multilib binutils-multilib libtool-multilib lib32-glibc. Pacman gives me that binutils and binutils-multilib conflict. Do I let multilib's version replace it? Mainly I want to build i686/x86_64 packages and make sure they work fine on both architectures as well, maybe with running a few 32-bit only applications if I come across them.

If you want to build i686 packages, multilib is not the solution, because it aims at creating 32-bit binaries which work correctly on a 64-bit system (that is, using different library paths to avoid confusion and so on). multilib is suited to create packages containing 32-bit binaries for the x86_64 packages (like the lib32-* packages). Yes, you need the gcc-multilib packages and friends to make it work. If you want to know whether your packages will work on i686, I think you'd better set up a chroot. -- Rémy.

Nathan O

6:51 a.m.

On Tue, Sep 7, 2010 at 1:49 AM, Rémy Oudompheng wrote:

...

Nathan O wrote:

...
I installed the x86_64 version of Arch, and I was looking at the wiki on running 32-bit apps in a 64-bit environment which seems what the multilib project/repo does. Though If I try and do pacman -S gcc-multilib gcc-libs-multilib binutils-multilib libtool-multilib lib32-glibc. Pacman gives me that binutils and binutils-multilib conflict. Do I let multilib's version replace it? Mainly I want to build i686/x86_64 packages and make sure they work fine on both architectures as well, maybe with running a few 32-bit only applications if I come across them.

If you want to build i686 packages, multilib is not the solution, because it aims at creating 32-bit binaries which work correctly on a 64-bit system (that is, using different library paths to avoid confusion and so on). multilib is suited to create packages containing 32-bit binaries for the x86_64 packages (like the lib32-* packages). Yes, you need the gcc-multilib packages and friends to make it work.

If you want to know whether your packages will work on i686, I think you'd better set up a chroot.

-- Rémy.

Thanks for the suggestion, my main thing is to test a package using i686 and maybe occasional running apps that only run in 32bit mode.

Nathan O

8:10 a.m.

On Tue, Sep 7, 2010 at 1:51 AM, Nathan O wrote:

...

On Tue, Sep 7, 2010 at 1:49 AM, Rémy Oudompheng wrote:

...
Nathan O wrote:

...
I installed the x86_64 version of Arch, and I was looking at the wiki on running 32-bit apps in a 64-bit environment which seems what the multilib project/repo does. Though If I try and do pacman -S gcc-multilib gcc-libs-multilib binutils-multilib libtool-multilib lib32-glibc. Pacman gives me that binutils and binutils-multilib conflict. Do I let multilib's version replace it? Mainly I want to build i686/x86_64 packages and make sure they work fine on both architectures as well, maybe with running a few 32-bit only applications if I come across them.

If you want to build i686 packages, multilib is not the solution, because it aims at creating 32-bit binaries which work correctly on a 64-bit system (that is, using different library paths to avoid confusion and so on). multilib is suited to create packages containing 32-bit binaries for the x86_64 packages (like the lib32-* packages). Yes, you need the gcc-multilib packages and friends to make it work.

If you want to know whether your packages will work on i686, I think you'd better set up a chroot.

-- Rémy.

Thanks for the suggestion, my main thing is to test a package using i686 and maybe occasional running apps that only run in 32bit mode.

I tried the Arch32-light package Xyne made, but I may have done something wrong, so I uninstalled it. Then I found out that, don't know how, my root password wasn't correct, had to readd gnome-session to > .xinitrc and resetup pidgin(including pidgin plugin tha twas installed) and Thunderbird. It is like I just installed all those apps and had to set them up it is really weird. I am afraid of tempting that again :) So I thought maybe use mkarchroot -r /aur/root and setup the pacman.conf to use i686 and such. What do you think, will this method work good?

Xyne

12:19 p.m.

Nathan O wrote:

...

I tried the Arch32-light package Xyne made, but I may have done something wrong, so I uninstalled it. Then I found out that, don't know how, my root password wasn't correct, had to readd gnome-session to > .xinitrc and resetup pidgin(including pidgin plugin tha twas installed) and Thunderbird. It is like I just installed all those apps and had to set them up it is really weird.

I am afraid of tempting that again :) So I thought maybe use mkarchroot -r /aur/root and setup the pacman.conf to use i686 and such. What do you think, will this method work good?

I just want to interject that the only way arch32-light would affect anything in your home directory is if you chose to mount it in the chroot and then ran something else in the chroot that alters files in $HOME. By default the chroot does not even mount /home and I have added several checks to the daemon and other scripts to prevent accidental wiping of data on mounted drives. Also note that it is possible to mount e.g. $HOME/home32 on the host as $HOME in the chroot. Btw, if anyone is interested, arch32-light no longer abuses the post_install function to set up the chroot... it now includes a script named "arch32initialize" ;) Regards, Xyne

Nathan O

7:36 p.m.

On Tue, Sep 7, 2010 at 7:19 AM, Xyne wrote:

...

...
I tried the Arch32-light package Xyne made, but I may have done something wrong, so I uninstalled it. Then I found out that, don't know how, my root password wasn't correct, had to readd gnome-session to > .xinitrc and resetup pidgin(including pidgin plugin tha twas installed) and Thunderbird. It is like I just installed all those apps and had to set them up it is really weird.

I am afraid of tempting that again :) So I thought maybe use mkarchroot -r /aur/root and setup the pacman.conf to use i686 and such. What do you

Nathan O wrote: think,

...
will this method work good?

I just want to interject that the only way arch32-light would affect anything in your home directory is if you chose to mount it in the chroot and then ran something else in the chroot that alters files in $HOME. By default the chroot does not even mount /home and I have added several checks to the daemon and other scripts to prevent accidental wiping of data on mounted drives.

Also note that it is possible to mount e.g. $HOME/home32 on the host as $HOME in the chroot.

Btw, if anyone is interested, arch32-light no longer abuses the post_install function to set up the chroot... it now includes a script named "arch32initialize" ;)

Regards, Xyne

Don't get me wrong, I wasn't accusing you or your package of anything. Not sure what happened except those problems that came out of no where.

Xyne

8:03 p.m.

...

Don't get me wrong, I wasn't accusing you or your package of anything. Not sure what happened except those problems that came out of no where.

Don't worry, I didn't take it that way at all. I just wanted to clarify for anyone else following the thread so they don't walk away thinking that arch32-light might be dangerous. ;)

Ng Oon-Ee

11:29 p.m.

On Tue, 2010-09-07 at 22:03 +0200, Xyne wrote:

...

...
Don't get me wrong, I wasn't accusing you or your package of anything. Not sure what happened except those problems that came out of no where.

Don't worry, I didn't take it that way at all. I just wanted to clarify for anyone else following the thread so they don't walk away thinking that arch32-light might be dangerous. ;)

But arch32-light ate my babies =)

Nathan O

11:35 p.m.

2010/9/7 Ng Oon-Ee

...

On Tue, 2010-09-07 at 22:03 +0200, Xyne wrote:

...
...
Don't get me wrong, I wasn't accusing you or your package of anything. Not sure what happened except those problems that came out of no where.

Don't worry, I didn't take it that way at all. I just wanted to clarify for anyone else following the thread so they don't walk away thinking that arch32-light might be dangerous. ;)

But arch32-light ate my babies =)

How dare arch32-light do that

Xyne

11:54 p.m.

Ng Oon-Ee wrote:

...

...
...
Don't get me wrong, I wasn't accusing you or your package of anything. Not sure what happened except those problems that came out of no where.

Don't worry, I didn't take it that way at all. I just wanted to clarify for anyone else following the thread so they don't walk away thinking that arch32-light might be dangerous. ;)

But arch32-light ate my babies =)

Hey, that's by design. Why do you think it's called "-light"? If you want to enjoy the act of procreation *and* the progeny it engenders, then you should use the non-light package. :P

4994

Age (days ago)

4995

Last active (days ago)

List overview

Download

11 comments

5 participants

participants (5)

Gary Wright
Nathan O
Ng Oon-Ee
Rémy Oudompheng
Xyne