Hi,
As it stands, the f11 release will not contain a ppc/ppc64 version of mono due to a continued build issue.
As a compromise, would it be acceptible to download the latest svn tarball, do a complete diff and patch in the diff file and then release it but not with the svn attribute? (assuming it will build on the ppc machines).
Failing that, should I just build mono from svn and check that in today as a chain build? Time is short - it's my birthday today, I've also got my kids for it (first time in 2 years), so a quick reply would help.
TTFN
Paul
On Mon, Apr 13, 2009 at 10:49 AM, Paul paul@all-the-johnsons.co.uk wrote:
Hi,
As it stands, the f11 release will not contain a ppc/ppc64 version of mono due to a continued build issue.
As a compromise, would it be acceptible to download the latest svn tarball, do a complete diff and patch in the diff file and then release it but not with the svn attribute? (assuming it will build on the ppc machines).
If the latest svn works on ppc it should be fine to apply the individual patch(s) that fixes the ppc builds. Has the issue been identified upstream?
Peter
Paul wrote:
Hi,
As it stands, the f11 release will not contain a ppc/ppc64 version of mono due to a continued build issue.
As discussed earlier on this list, the worst that should happen is we release with mono-2.4-9.RC1.fc11 which builds on ppc/ppc64.
As a compromise, would it be acceptible to download the latest svn tarball, do a complete diff and patch in the diff file and then release it but not with the svn attribute? (assuming it will build on the ppc machines).
Failing that, should I just build mono from svn and check that in today as a chain build? Time is short - it's my birthday today, I've also got my kids for it (first time in 2 years), so a quick reply would help.
It sounds like mono's svn snapshot won't build on ppc any more than current release + patches from the bug. So taking a snapshot seems unnecessary.
-Toshio
On Mon, Apr 13, 2009 at 10:14:09AM -0700, Toshio Kuratomi wrote:
Paul wrote:
Hi,
As it stands, the f11 release will not contain a ppc/ppc64 version of mono due to a continued build issue.
As discussed earlier on this list, the worst that should happen is we release with mono-2.4-9.RC1.fc11 which builds on ppc/ppc64.
As a compromise, would it be acceptible to download the latest svn tarball, do a complete diff and patch in the diff file and then release it but not with the svn attribute? (assuming it will build on the ppc machines).
Failing that, should I just build mono from svn and check that in today as a chain build? Time is short - it's my birthday today, I've also got my kids for it (first time in 2 years), so a quick reply would help.
It sounds like mono's svn snapshot won't build on ppc any more than current release + patches from the bug. So taking a snapshot seems unnecessary.
We've actually had someone looking into this, primarily the person that did many ppc fixes upstream for Mono. The bug has the details, but at the moment Mono builds just fine on an Apple G5 machine installed with the latest rawhide.
Why this doesn't build in the koji environment is the odd question.
josh
Josh Boyer wrote:
We've actually had someone looking into this, primarily the person that did many ppc fixes upstream for Mono. The bug has the details, but at the moment Mono builds just fine on an Apple G5 machine installed with the latest rawhide.
Why this doesn't build in the koji environment is the odd question.
Short update. This comes in two pieces:
1) mono-2.4RC1 has been built for F11. The package is mono-2.4-15.1.RC1.fc11: http://koji.fedoraproject.org/koji/taskinfo?taskID=1295722
This package has the moonlight necessary bits flipped on and the other changes to the packaging (not the upstream code) from later releases. It is not built for ppc64 as we've never had ppc64 mono. We can look at fixing that once we get mono-2.4-final building on ppc. This package should be our fallback in case we aren't able to fix the bugs in mono-2.4-final by the time F11 ships.
**Important** Anyone who has been building mono packages with ExcludeArch: ppc, please fix that. We need to get those packages back into the ppc tree ASAP. this goes double for mono libraries.
2) The bugs in mono/ppc are being worked through here: https://bugzilla.redhat.com/show_bug.cgi?id=494026
So far Steven Munroe has diagnosed and fixed a problem in the assembly for ppc and has narrowed down the current build failure to a particular configure flag. We'll keep you posted as we (mostly Steven ;-) gets the rest of the bugs worked out.
-Toshio
Toshio Kuratomi wrote:
- The bugs in mono/ppc are being worked through here:
https://bugzilla.redhat.com/show_bug.cgi?id=494026
So far Steven Munroe has diagnosed and fixed a problem in the assembly for ppc and has narrowed down the current build failure to a particular configure flag. We'll keep you posted as we (mostly Steven ;-) gets the rest of the bugs worked out.
So mono builds itself and then uses the resulting binary during the build process. If we link that binary dynamically against libmono.so, at least some subsequent commands break on ppc. If we link that binary statically against libmono.so (but dynamically against everything else) then subsequent commands work fine and we get mono packages built. Does this sound like a bug in gcc or the dynamic linker? Does this remind anyone of some other bug they've encountered in the past?
-Toshio
On Mon, Apr 13, 2009 at 8:46 PM, Toshio Kuratomi a.badger@gmail.com wrote:
So mono builds itself and then uses the resulting binary during the build process. If we link that binary dynamically against libmono.so, at least some subsequent commands break on ppc. If we link that binary statically against libmono.so (but dynamically against everything else) then subsequent commands work fine and we get mono packages built. Does this sound like a bug in gcc or the dynamic linker? Does this remind anyone of some other bug they've encountered in the past?
-Toshio
Wild shot in the dark: is -fPIC supplied for every single source file and also for the link command to create libmono.so?
When subsequent commands "break", how exactly are they breaking?
Is this still a koji-only problem, or can it be reproduced on somebody's personal machine now?
Jerry James wrote:
On Mon, Apr 13, 2009 at 8:46 PM, Toshio Kuratomi a.badger@gmail.com wrote:
So mono builds itself and then uses the resulting binary during the build process. If we link that binary dynamically against libmono.so, at least some subsequent commands break on ppc. If we link that binary statically against libmono.so (but dynamically against everything else) then subsequent commands work fine and we get mono packages built. Does this sound like a bug in gcc or the dynamic linker? Does this remind anyone of some other bug they've encountered in the past?
-Toshio
Wild shot in the dark: is -fPIC supplied for every single source file and also for the link command to create libmono.so?
I don't know for sure but I'd expect x86_64 to break as well if that wasn't happening.
When subsequent commands "break", how exactly are they breaking?
In the mono build, mcs.exe is used to build some C# files and that overflows the stack: Stack overflow in unmanaged: IP: 0xf8b4b54, fault addr: 0xff18bda0 Stack overflow in unmanaged: IP: 0xf8b4b54, fault addr: 0xff18abd0
(More details are in the build.log's linked from this bug: https://bugzilla.redhat.com/show_bug.cgi?id=494026 )
Is this still a koji-only problem, or can it be reproduced on somebody's personal machine now?
Nope. It can be reproduced on personal machines as well.
-Toshio