multilib
 

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

multilib
 

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.

multilib
 

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?

multilib
 

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.

multilib
 

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.

multilib
 

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?

multilib
 

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

multilib
 

On Tue, Sep 7, 2010 at 7:19 AM, Xyne <xyne@archlinux.ca> wrote:

> 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
>
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.

multilib
 

> 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. ;)

multilib
 

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 =)