FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 03-08-2010, 09:20 PM
Paul Mattal
 
Default i686 pkg built in chroot on x86_64 doesn't work

On 03/07/2010 02:33 PM, Paul Mattal wrote:

On 02/25/2010 11:49 AM, Aaron Griffin wrote:

On Tue, Feb 23, 2010 at 7:17 PM, Daniel J Griffiths (Ghost1227)
<ghost1227@archlinux.us> wrote:

I've always thought the method of modifying your local mirrorlist,
running mkarchroot, then reverting the changes to be more tedious than
necessary for creation of i686 chroots on x86_64. My recent work with
setting up a dedicated build server gave me plenty of time and an
excuse to actually do something about it. As such, I've put together a
little patch that allows specification of creation of an i686 chroot
at runtime. When set, this flag will automatically modify your local
mirrorlist, create the requested i686 chroot, then revert the changes
to the mirrorlist file. I don't know if others would find this useful
or not, but I figured it wouldn't hurt to post it.


Actually, I *thought* I added a flag to point to an alternate pacman
config when building the chroot, to simplify this. So it'd be as
simple as:

sed s/x86_64/i686/< /etc/pacman.d/mirrorlist>
/etc/pacman.d/mirrorlist-i686
sed s/mirrorlist/mirrorlist-i686/< /etc/pacman.conf>
/etc/pacman-i686.conf

mkarchroot -C /etc/pacman-i686.conf ...yada yada...


Having some uniform turnkey script to build an i686 chroot on an x86_64
box as part of devtools would be useful.

I just noticed today that in setting up my chroots, I had replaced my
x86_64 in makepkg.conf with i686, but not replaced the x86-64 which
occur in CFLAGS and CXXFLAGS. If others have done similar things, it
might result in buggy or suboptimal packages.

It would at least be nice of someone who knows a lot about building in
chroots describes in detail what must be done for i686 chroots in x86_64
in the wiki page, just in case there are important details I or others
have missed.


So here's one for the chroot gurus.

It appears that even with all my settings fixed, tomcat doesn't work
when built in my i686 chroot on x86_64:


http://bugs.archlinux.org/task/18604

Building on an actual i686 box, even in a chroot, works.

Can anyone guess why this might be? Are there some guidelines someone
can give for evaluating whether or not it's safe to build a package
under an i686 chroot on an x86_64 box?


It seems there's an increased risk we're putting out broken packages
when we build i686 packages in a chroot on an x86_64 box.


- P
 
Old 03-08-2010, 09:38 PM
"Daniel J Griffiths (Ghost1227)"
 
Default i686 pkg built in chroot on x86_64 doesn't work

On 03/08/10 at 05:20pm, Paul Mattal wrote:
> On 03/07/2010 02:33 PM, Paul Mattal wrote:
> >On 02/25/2010 11:49 AM, Aaron Griffin wrote:
> >>On Tue, Feb 23, 2010 at 7:17 PM, Daniel J Griffiths (Ghost1227)
> >><ghost1227@archlinux.us> wrote:
> >>>I've always thought the method of modifying your local mirrorlist,
> >>>running mkarchroot, then reverting the changes to be more tedious than
> >>>necessary for creation of i686 chroots on x86_64. My recent work with
> >>>setting up a dedicated build server gave me plenty of time and an
> >>>excuse to actually do something about it. As such, I've put together a
> >>>little patch that allows specification of creation of an i686 chroot
> >>>at runtime. When set, this flag will automatically modify your local
> >>>mirrorlist, create the requested i686 chroot, then revert the changes
> >>>to the mirrorlist file. I don't know if others would find this useful
> >>>or not, but I figured it wouldn't hurt to post it.
> >>
> >>Actually, I *thought* I added a flag to point to an alternate pacman
> >>config when building the chroot, to simplify this. So it'd be as
> >>simple as:
> >>
> >>sed s/x86_64/i686/< /etc/pacman.d/mirrorlist>
> >>/etc/pacman.d/mirrorlist-i686
> >>sed s/mirrorlist/mirrorlist-i686/< /etc/pacman.conf>
> >>/etc/pacman-i686.conf
> >>
> >>mkarchroot -C /etc/pacman-i686.conf ...yada yada...
> >
> >Having some uniform turnkey script to build an i686 chroot on an x86_64
> >box as part of devtools would be useful.
> >
> >I just noticed today that in setting up my chroots, I had replaced my
> >x86_64 in makepkg.conf with i686, but not replaced the x86-64 which
> >occur in CFLAGS and CXXFLAGS. If others have done similar things, it
> >might result in buggy or suboptimal packages.
> >
> >It would at least be nice of someone who knows a lot about building in
> >chroots describes in detail what must be done for i686 chroots in x86_64
> >in the wiki page, just in case there are important details I or others
> >have missed.
>
> So here's one for the chroot gurus.
>
> It appears that even with all my settings fixed, tomcat doesn't work
> when built in my i686 chroot on x86_64:
>
> http://bugs.archlinux.org/task/18604
>
> Building on an actual i686 box, even in a chroot, works.
>
> Can anyone guess why this might be? Are there some guidelines
> someone can give for evaluating whether or not it's safe to build a
> package under an i686 chroot on an x86_64 box?
>
> It seems there's an increased risk we're putting out broken packages
> when we build i686 packages in a chroot on an x86_64 box.
>
> - P
I've seen a few (rare) cases where a package built for i686 on an x86_64
machine _must_ be run with linux32, just using a 32bit chroot doesn't
cut it. This could be one of those cases. On a side note, perhaps I should
add a flag on pkgbuild.com to enable this just for those off-the-wall
cases...
--
 
Old 03-09-2010, 03:32 AM
Paul Mattal
 
Default i686 pkg built in chroot on x86_64 doesn't work

On 03/08/2010 07:16 PM, Allan McRae wrote:

On 09/03/10 08:38, Daniel J Griffiths (Ghost1227) wrote:

On 03/08/10 at 05:20pm, Paul Mattal wrote:

On 03/07/2010 02:33 PM, Paul Mattal wrote:

On 02/25/2010 11:49 AM, Aaron Griffin wrote:

On Tue, Feb 23, 2010 at 7:17 PM, Daniel J Griffiths (Ghost1227)
<ghost1227@archlinux.us> wrote:

I've always thought the method of modifying your local mirrorlist,
running mkarchroot, then reverting the changes to be more tedious
than
necessary for creation of i686 chroots on x86_64. My recent work with
setting up a dedicated build server gave me plenty of time and an
excuse to actually do something about it. As such, I've put
together a
little patch that allows specification of creation of an i686 chroot
at runtime. When set, this flag will automatically modify your local
mirrorlist, create the requested i686 chroot, then revert the changes
to the mirrorlist file. I don't know if others would find this useful
or not, but I figured it wouldn't hurt to post it.


Actually, I *thought* I added a flag to point to an alternate pacman
config when building the chroot, to simplify this. So it'd be as
simple as:

sed s/x86_64/i686/< /etc/pacman.d/mirrorlist>
/etc/pacman.d/mirrorlist-i686
sed s/mirrorlist/mirrorlist-i686/< /etc/pacman.conf>
/etc/pacman-i686.conf

mkarchroot -C /etc/pacman-i686.conf ...yada yada...


Having some uniform turnkey script to build an i686 chroot on an x86_64
box as part of devtools would be useful.

I just noticed today that in setting up my chroots, I had replaced my
x86_64 in makepkg.conf with i686, but not replaced the x86-64 which
occur in CFLAGS and CXXFLAGS. If others have done similar things, it
might result in buggy or suboptimal packages.

It would at least be nice of someone who knows a lot about building in
chroots describes in detail what must be done for i686 chroots in
x86_64
in the wiki page, just in case there are important details I or others
have missed.


So here's one for the chroot gurus.

It appears that even with all my settings fixed, tomcat doesn't work
when built in my i686 chroot on x86_64:

http://bugs.archlinux.org/task/18604

Building on an actual i686 box, even in a chroot, works.

Can anyone guess why this might be? Are there some guidelines
someone can give for evaluating whether or not it's safe to build a
package under an i686 chroot on an x86_64 box?

It seems there's an increased risk we're putting out broken packages
when we build i686 packages in a chroot on an x86_64 box.

- P

I've seen a few (rare) cases where a package built for i686 on an x86_64
machine _must_ be run with linux32, just using a 32bit chroot doesn't
cut it. This could be one of those cases. On a side note, perhaps I
should
add a flag on pkgbuild.com to enable this just for those off-the-wall
cases...


I'd say to always use linux32... You can get some very strange configure
errors without it. I have "makechrootpkg64" as an alias to use "linux64
makechrootpkg" on my system.


I've added linux32 to my build scripts on my x86_64 box, since this
seems like a good idea in general; is there any reason *not* to run
makechrootpkg for an i686 chroot on an x86_64 box with linux32 all the
time? I could try to tool up a patch to makechrootpkg to automatically
detect/do that.


However, adding it doesn't solve the tomcat building problem; same
result. This must be some other issue.


- P
 
Old 03-09-2010, 03:40 AM
"Daniel J Griffiths (Ghost1227)"
 
Default i686 pkg built in chroot on x86_64 doesn't work

On 03/08/10 at 11:32pm, Paul Mattal wrote:
> On 03/08/2010 07:16 PM, Allan McRae wrote:
> >On 09/03/10 08:38, Daniel J Griffiths (Ghost1227) wrote:
> >>On 03/08/10 at 05:20pm, Paul Mattal wrote:
> >>>On 03/07/2010 02:33 PM, Paul Mattal wrote:
> >>>>On 02/25/2010 11:49 AM, Aaron Griffin wrote:
> >>>>>On Tue, Feb 23, 2010 at 7:17 PM, Daniel J Griffiths (Ghost1227)
> >>>>><ghost1227@archlinux.us> wrote:
> >>>>>>I've always thought the method of modifying your local mirrorlist,
> >>>>>>running mkarchroot, then reverting the changes to be more tedious
> >>>>>>than
> >>>>>>necessary for creation of i686 chroots on x86_64. My recent work with
> >>>>>>setting up a dedicated build server gave me plenty of time and an
> >>>>>>excuse to actually do something about it. As such, I've put
> >>>>>>together a
> >>>>>>little patch that allows specification of creation of an i686 chroot
> >>>>>>at runtime. When set, this flag will automatically modify your local
> >>>>>>mirrorlist, create the requested i686 chroot, then revert the changes
> >>>>>>to the mirrorlist file. I don't know if others would find this useful
> >>>>>>or not, but I figured it wouldn't hurt to post it.
> >>>>>
> >>>>>Actually, I *thought* I added a flag to point to an alternate pacman
> >>>>>config when building the chroot, to simplify this. So it'd be as
> >>>>>simple as:
> >>>>>
> >>>>>sed s/x86_64/i686/< /etc/pacman.d/mirrorlist>
> >>>>>/etc/pacman.d/mirrorlist-i686
> >>>>>sed s/mirrorlist/mirrorlist-i686/< /etc/pacman.conf>
> >>>>>/etc/pacman-i686.conf
> >>>>>
> >>>>>mkarchroot -C /etc/pacman-i686.conf ...yada yada...
> >>>>
> >>>>Having some uniform turnkey script to build an i686 chroot on an x86_64
> >>>>box as part of devtools would be useful.
> >>>>
> >>>>I just noticed today that in setting up my chroots, I had replaced my
> >>>>x86_64 in makepkg.conf with i686, but not replaced the x86-64 which
> >>>>occur in CFLAGS and CXXFLAGS. If others have done similar things, it
> >>>>might result in buggy or suboptimal packages.
> >>>>
> >>>>It would at least be nice of someone who knows a lot about building in
> >>>>chroots describes in detail what must be done for i686 chroots in
> >>>>x86_64
> >>>>in the wiki page, just in case there are important details I or others
> >>>>have missed.
> >>>
> >>>So here's one for the chroot gurus.
> >>>
> >>>It appears that even with all my settings fixed, tomcat doesn't work
> >>>when built in my i686 chroot on x86_64:
> >>>
> >>>http://bugs.archlinux.org/task/18604
> >>>
> >>>Building on an actual i686 box, even in a chroot, works.
> >>>
> >>>Can anyone guess why this might be? Are there some guidelines
> >>>someone can give for evaluating whether or not it's safe to build a
> >>>package under an i686 chroot on an x86_64 box?
> >>>
> >>>It seems there's an increased risk we're putting out broken packages
> >>>when we build i686 packages in a chroot on an x86_64 box.
> >>>
> >>>- P
> >>I've seen a few (rare) cases where a package built for i686 on an x86_64
> >>machine _must_ be run with linux32, just using a 32bit chroot doesn't
> >>cut it. This could be one of those cases. On a side note, perhaps I
> >>should
> >>add a flag on pkgbuild.com to enable this just for those off-the-wall
> >>cases...
> >
> >I'd say to always use linux32... You can get some very strange configure
> >errors without it. I have "makechrootpkg64" as an alias to use "linux64
> >makechrootpkg" on my system.
>
> I've added linux32 to my build scripts on my x86_64 box, since this
> seems like a good idea in general; is there any reason *not* to run
> makechrootpkg for an i686 chroot on an x86_64 box with linux32 all
> the time? I could try to tool up a patch to makechrootpkg to
> automatically detect/do that.
>
> However, adding it doesn't solve the tomcat building problem; same
> result. This must be some other issue.
>
> - P
OK... take two at an explanation... the go package won't build in an i686 chroot because the
build scripts natively use uname to determine arch... possibly something similar in tomcat?
--
 
Old 03-09-2010, 04:21 AM
Gerardo Exequiel Pozzi
 
Default i686 pkg built in chroot on x86_64 doesn't work

On 03/09/2010 01:32 AM, Paul Mattal wrote:



However, adding it doesn't solve the tomcat building problem; same
result. This must be some other issue.


- P

I tested building from trunk tomcat on x86_64, inside i686 chroot
(chroot made with a custom script not from devtools). Builds fine, just
before entering, or executing linux32 makepkg.



[djgera@exequiel trunk]$ strings pkg/opt/tomcat/bin/jsvc | grep i386
$JAVA_HOME/lib/i386/jvm.cfg
$JAVA_HOME/lib/i386/libjvm.so
$JAVA_HOME/bin/i386/libjvm.so
...
[djgera@exequiel trunk]$ strings pkg/opt/tomcat/bin/jsvc | grep amd64
[djgera@exequiel trunk]$



--
Gerardo Exequiel Pozzi ( djgera )
http://www.djgera.com.ar
KeyID: 0x1B8C330D
Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
 
Old 03-09-2010, 04:23 AM
Paul Mattal
 
Default i686 pkg built in chroot on x86_64 doesn't work

On 03/09/2010 12:19 AM, Allan McRae wrote:

On 09/03/10 14:40, Daniel J Griffiths (Ghost1227) wrote:

On 03/08/10 at 11:32pm, Paul Mattal wrote:

On 03/08/2010 07:16 PM, Allan McRae wrote:

On 09/03/10 08:38, Daniel J Griffiths (Ghost1227) wrote:

On 03/08/10 at 05:20pm, Paul Mattal wrote:

On 03/07/2010 02:33 PM, Paul Mattal wrote:

On 02/25/2010 11:49 AM, Aaron Griffin wrote:

On Tue, Feb 23, 2010 at 7:17 PM, Daniel J Griffiths (Ghost1227)
<ghost1227@archlinux.us> wrote:

I've always thought the method of modifying your local mirrorlist,
running mkarchroot, then reverting the changes to be more tedious
than
necessary for creation of i686 chroots on x86_64. My recent
work with
setting up a dedicated build server gave me plenty of time and an
excuse to actually do something about it. As such, I've put
together a
little patch that allows specification of creation of an i686
chroot
at runtime. When set, this flag will automatically modify your
local
mirrorlist, create the requested i686 chroot, then revert the
changes
to the mirrorlist file. I don't know if others would find this
useful
or not, but I figured it wouldn't hurt to post it.


Actually, I *thought* I added a flag to point to an alternate
pacman
config when building the chroot, to simplify this. So it'd be as
simple as:

sed s/x86_64/i686/< /etc/pacman.d/mirrorlist>
/etc/pacman.d/mirrorlist-i686
sed s/mirrorlist/mirrorlist-i686/< /etc/pacman.conf>
/etc/pacman-i686.conf

mkarchroot -C /etc/pacman-i686.conf ...yada yada...


Having some uniform turnkey script to build an i686 chroot on an
x86_64
box as part of devtools would be useful.

I just noticed today that in setting up my chroots, I had
replaced my
x86_64 in makepkg.conf with i686, but not replaced the x86-64 which
occur in CFLAGS and CXXFLAGS. If others have done similar things, it
might result in buggy or suboptimal packages.

It would at least be nice of someone who knows a lot about
building in
chroots describes in detail what must be done for i686 chroots in
x86_64
in the wiki page, just in case there are important details I or
others
have missed.


So here's one for the chroot gurus.

It appears that even with all my settings fixed, tomcat doesn't work
when built in my i686 chroot on x86_64:

http://bugs.archlinux.org/task/18604

Building on an actual i686 box, even in a chroot, works.

Can anyone guess why this might be? Are there some guidelines
someone can give for evaluating whether or not it's safe to build a
package under an i686 chroot on an x86_64 box?

It seems there's an increased risk we're putting out broken packages
when we build i686 packages in a chroot on an x86_64 box.

- P

I've seen a few (rare) cases where a package built for i686 on an
x86_64
machine _must_ be run with linux32, just using a 32bit chroot doesn't
cut it. This could be one of those cases. On a side note, perhaps I
should
add a flag on pkgbuild.com to enable this just for those off-the-wall
cases...


I'd say to always use linux32... You can get some very strange
configure
errors without it. I have "makechrootpkg64" as an alias to use "linux64
makechrootpkg" on my system.


I've added linux32 to my build scripts on my x86_64 box, since this
seems like a good idea in general; is there any reason *not* to run
makechrootpkg for an i686 chroot on an x86_64 box with linux32 all
the time? I could try to tool up a patch to makechrootpkg to
automatically detect/do that.

However, adding it doesn't solve the tomcat building problem; same
result. This must be some other issue.

- P

OK... take two at an explanation... the go package won't build in an
i686 chroot because the
build scripts natively use uname to determine arch... possibly
something similar in tomcat?


linux32 will change uname appropriately.

allan@arch ~
> linux32 uname -m
i686

allan@arch ~
> linux64 uname -m
x86_64


So this is a weird one, but I think I just made some headway.

Apparently, this seems to be related to the ACTUAL CPU of the box I
build on. When building on an i686 Arch box running on an AMD 64 CPU,
the build generates the broken binaries! When I build on an Intel CPU,
it works fine.


So it would appear this is at least in part Tomcat's build process's
fault for not building the right thing based on the uname -m but rather
looking directly at the processor.


Yuck. Perhaps I will at least add a note to the PKGBUILD suggesting this
issue, so that the next poor person who decides to update tomcat doesn't
trip over this same thing.


Thanks, all, for working this through with me.

- P
 
Old 03-09-2010, 04:39 AM
Gerardo Exequiel Pozzi
 
Default i686 pkg built in chroot on x86_64 doesn't work

On 03/09/2010 02:27 AM, Allan McRae wrote:

On 09/03/10 15:23, Paul Mattal wrote:

So this is a weird one, but I think I just made some headway.

Apparently, this seems to be related to the ACTUAL CPU of the box I
build on. When building on an i686 Arch box running on an AMD 64 CPU,
the build generates the broken binaries! When I build on an Intel CPU,
it works fine.

So it would appear this is at least in part Tomcat's build process's
fault for not building the right thing based on the uname -m but rather
looking directly at the processor.

Yuck. Perhaps I will at least add a note to the PKGBUILD suggesting this
issue, so that the next poor person who decides to update tomcat doesn't
trip over this same thing.


Seriously... WTF! That is up there with some of the strangest build
issues I have ever seen.


Allan

jsvc uses "arch" command. arch is marked as deprecated tool replaced by
uname.
Anyway "arch" will return correct values when using linux32 wrapper.
(And I am on AMD64).


what return "linux32 arch" on your weird chroot?

--
Gerardo Exequiel Pozzi ( djgera )
http://www.djgera.com.ar
KeyID: 0x1B8C330D
Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
 

Thread Tools




All times are GMT. The time now is 09:44 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org