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
On Mon, Sep 6, 2010 at 5:39 PM, Nathan O <ndowens.aur@gmail.com> 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.
On Mon, Sep 6, 2010 at 8:19 PM, Gary Wright <wriggary@gmail.com> wrote:
On Mon, Sep 6, 2010 at 5:39 PM, Nathan O <ndowens.aur@gmail.com> 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?
Nathan O <ndowens.aur@gmail.com> 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.
On Tue, Sep 7, 2010 at 1:49 AM, Rémy Oudompheng <remyoudompheng@gmail.com>wrote:
Nathan O <ndowens.aur@gmail.com> 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.
On Tue, Sep 7, 2010 at 1:51 AM, Nathan O <ndowens.aur@gmail.com> wrote:
On Tue, Sep 7, 2010 at 1:49 AM, Rémy Oudompheng <remyoudompheng@gmail.com>wrote:
Nathan O <ndowens.aur@gmail.com> 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?
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
On Tue, Sep 7, 2010 at 7:19 AM, Xyne <xyne@archlinux.ca> 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.
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. ;)
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 =)
2010/9/7 Ng Oon-Ee <ngoonee@gmail.com>
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
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
participants (5)
-
Gary Wright
-
Nathan O
-
Ng Oon-Ee
-
Rémy Oudompheng
-
Xyne