On Sat, 2011-07-02 at 13:59 -0400, Jon Masters wrote:
On Sat, 2011-07-02 at 05:15 -0400, Jon Masters wrote:
On Thu, 2011-06-30 at 18:47 -0400, Jon Masters wrote:
Thanks to the hard work of many people (including Stefan's
contribution
this morning to get some of the final nss bits and RPM in place, and
of
course the groundwork put in place by DJ Delorie), we are now very
close
to having rpm and rpmbuild. I fixed a problem with digest support earlier, we're just waiting on fixing the RPM macros/teaching RPM
about
armv7hl vs. armv7l, etc. in patches Dennis already has and will send
me.
I'm hoping to get the remaining bits in place so that tomorrow's
VFAD
can be spent building actual RPMs. We'll need to start by rebuilding what we have but in real RPM format, then work toward slowly getting
a
buildroot that we can use to rebuild everything again, and finally
do
one more build to have a full featured build environment. It would
be
awesome to get to a point tomorrow where we've got an armv7hl
binutils
binary RPM and its deps at least, with anything else being a bonus.
Just as a head's up. I've changed the default build for all v7 systems such that we'll target armv7hl, unless it's otherwise set at build. I committed the change to redhat-rpm-config, and pushed up to F15.
Since this came up on IRC, and I need to run, let me note:
Note. I changed this for a *very specific reason*. Without this, and if you don't have /proc explicitly mounted, RPM will default to armv5tel. Since (at least for now), we have no business building armv5tel on armv7 systems, it's better to make sure nobody is building armv5tel.
Really have to run...but just to add...
I know it's good to bind mount /proc, it's probably a good idea anyway. I'm also not against agreeing to drop this patch, but I'm not in favor of dropping it just to support some theoretical ARM v7 system without hardfp. There is really, in reality, no such thing as non-hardfp v7 (as long as you do -d16, which we do). Therefore, I can see no harm in assuming armv7 means hardfp for the moment.
Finally, I know sparc parses /proc/cpuinfo, so I see where the idea comes from, but as I mentioned in this case before, the correct thing to do is to use something intrinsic from the filesystem, such as the ELF sectional data on the RPM binary itself that says it was build hardfp. I would rather fix the patch not to rely on /proc information, however it is actually done. Anyway, we can debate, but I need to run!
For now, at least, just cloning the repo on an armv7hl system will do the right thing for all actual systems that (will ever) exist.
As i said on irc making the change in the git tree for this would be ok, but the change is wrong for general consumption, parsing /proc/cpuinfo as my patch does is used to check for the existance of cpu flags to determine capability, i.e. can we run a neon optimised binary etc. though that should be in an ideal world detected at run time and not at build time.
there is possibly many ways to skin the cat. what i see as wrong here is that if you end up with rpm saying your on softfloat and the internal copy of uname -m that rpm uses hasnt been rewritten to something indicating that you are running with hardfp i t will try to build a hardfp binary. we should be trying for softfp binaries the route we have gone with rpm has been to keep hard and softfp separate and not parallel installable, what this means is that in practice you can not install hardfp rpms on softfp systems and vice versa. with this change we then limit our building of softfp binaries to armv5tel and armv6l systems only, i am sure we will want to use some armv7 machines in the build pool for armv5tel binaries, users may also want to do the same thing. while you can install either stream of binary rpms into a chroot and it will work as you want it to and expect it to. it would require special work in rpm to detect these cases and allow the transaction to happen. maybe thats easier to do than i expect. im happy to be proven wrong.
i dont disagree that having thins as you patched them in the git chroot is ok. but i do disagree with making that change upstream in fedora as its not going to help and will confuse those who do run softfp installs on v7 hardware for whatever reason. except in limited cases i do agree that v7 hardware should be running a hardfp install.
Dennis
On Sat, 2011-07-02 at 20:14 +0000, Dennis Gilmore wrote:
On Sat, 2011-07-02 at 13:59 -0400, Jon Masters wrote:
I know it's good to bind mount /proc, it's probably a good idea anyway. I'm also not against agreeing to drop this patch, but I'm not in favor of dropping it just to support some theoretical ARM v7 system without hardfp. There is really, in reality, no such thing as non-hardfp v7 (as long as you do -d16, which we do). Therefore, I can see no harm in assuming armv7 means hardfp for the moment.
Finally, I know sparc parses /proc/cpuinfo, so I see where the idea comes from, but as I mentioned in this case before, the correct thing to do is to use something intrinsic from the filesystem, such as the ELF sectional data on the RPM binary itself that says it was build hardfp. I would rather fix the patch not to rely on /proc information, however it is actually done. Anyway, we can debate, but I need to run!
For now, at least, just cloning the repo on an armv7hl system will do the right thing for all actual systems that (will ever) exist.
As i said on irc making the change in the git tree for this would be ok, but the change is wrong for general consumption, parsing /proc/cpuinfo as my patch does is used to check for the existance of cpu flags to determine capability, i.e. can we run a neon optimised binary etc. though that should be in an ideal world detected at run time and not at build time.
As I said, I understand why you parsed /proc/cpuinfo using the same approach as the SPARC code. My point above is that it's better we replace that with either parsing out the ELF section info on the RPM binary so that we know we're actually running hardfp (that way, you can even install softfp on hardfp systems and use whatever kernel you like - the correct thing will happen based on the software environment).
there is possibly many ways to skin the cat. what i see as wrong here is that if you end up with rpm saying your on softfloat and the internal copy of uname -m that rpm uses hasnt been rewritten to something indicating that you are running with hardfp i t will try to build a hardfp binary. we should be trying for softfp binaries the route we have gone with rpm has been to keep hard and softfp separate and not parallel installable, what this means is that in practice you can not install hardfp rpms on softfp systems and vice versa. with this change we then limit our building of softfp binaries to armv5tel and armv6l systems only, i am sure we will want to use some armv7 machines in the build pool for armv5tel binaries, users may also want to do the same thing. while you can install either stream of binary rpms into a chroot and it will work as you want it to and expect it to. it would require special work in rpm to detect these cases and allow the transaction to happen. maybe thats easier to do than i expect. im happy to be proven wrong.
I thought one could still specify a target explicitly at build time? So it'd be like all i686 systems defaulting to i686 but having the ability to build for i386 if you explicitly tell them to.
[ addition: though perhaps using "buildtranslate" excludes that. And if it does, then, ok we need another solution because yes we'll want armv7 hosts to be able to build packages for armv5 ]
i dont disagree that having thins as you patched them in the git chroot is ok. but i do disagree with making that change upstream in fedora as its not going to help and will confuse those who do run softfp installs on v7 hardware for whatever reason. except in limited cases i do agree that v7 hardware should be running a hardfp install.
So I'm ok with reverting in F15 and upstream if you want :) I think we need to keep this hack in the rootfs version for now so that it just works (I don't want volunteers who come to help having to do anything in addition to the instructions[0]), and then I'd like to replace the /proc parsing with ELF parsing or similar if possible. We already link against (I think, I'll check) enough deps to do that without increasing the burden on RPM. But I guess we'll need to get Panu or someone to comment on whether they mind having code that opens the ELF file and parses it.
Thanks for your hard work on this. I'm not criticizing :) My point is more that we need to make sure things are easy for people who want to help build stuff. If we need to rely on them having setup a bind mount in /proc for binaries to come out the right way, it's one more way we might not be able to benefit from their time helping to build stuff.
Thanks!
Jon.
[0] The fact that this *didn't* work out of the box with the rootfs and that you, DJ, and others were obviously having to "do something" to make it (rpmbuild) build correctly means you were doing something not in the instructions. That's fine. Because you know what you're doing - it's the standard Linux dilemma ("oh I just did this...and it was fine") but it doesn't help someone who comes along and wants to help. We need to all be using the stock rootfs in explicitly documented ways for bootstrap.
-
Dennis Gilmore -
Jon Masters