#1648 closed defect (fixed)
Mutt gcc4 issues
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | high | Milestone: | |
Component: | BOOK | Version: | SVN |
Severity: | normal | Keywords: | |
Cc: |
Description (last modified by ) ¶
Mutt-1.4.2.1i doesn't compile with gcc4. A patch has been added to the livecd repository:
This does help compiling Mutt-1.4.2.1i. For the "normal" LFS, patched Mutt works.
For the UTF-8 book, patched Mutt-1.4.2.1i segfaults at startup if /etc/Muttrc contains at least one "macro" line. Reason: ./configure checks for ncursesw, and a different code path is used. There was no segfault with gcc-3.4.x.
Upgrading to Mutt-1.5.10i resolves both the compilation failure and the segfault issue.
Change History (15)
comment:1 by , 19 years ago
blocked: | → 1579 |
---|
comment:2 by , 19 years ago
Description: | modified (diff) |
---|---|
Owner: | changed from | to
Status: | new → assigned |
comment:3 by , 19 years ago
Mutt-1.5.11 is out now, so I'll be trying that. Anyone know of any issues with this version?
comment:4 by , 19 years ago
(in reply to the most previous entry)
Other than the maintainers consider it a development version, and not stable, no.
comment:5 by , 19 years ago
Dan. I already provided some info to upgrade mutt to 1.5.11. http://linuxfromscratch.org/pipermail/blfs-dev/2006-February/013594.html
No issues so far,included UTF-8.
comment:6 by , 19 years ago
Thanks, Ag. Do you build mutt against any of the dependencies: gnupg, openssl, krb5, heimdal, s-lang, cyrus-sasl? I'd only planned on building against openssl, so if you have any information about the others, I'd be glad to hear it.
comment:8 by , 19 years ago
Before this bug is closed, the BLFS Mutt page should be updated to include a note about why we are using a development version of the package, and not the stable version.
comment:9 by , 19 years ago
I'm not sure what to say. "A development version is being used because it fixes issues with GCC-4 and UTF-8." This version is 6 months old now, and the stable version is 2 years old, so we're not really on the bleeding edge.
Any other suggestions?
comment:10 by , 19 years ago
But don't you think there is a reason that it is still be referred to as a development version? We really need to explain this as it directly conflicts with BLFS policy.
Just as Archaic mentioned yesterday about shadow: "Backporting the cvs changes and creating a patch sounds like a viable option."
Don't get me wrong, I think doing whatever is necessary to allow the package to build with the current toolchain is mandatory. If it cannot be accomplished with a patch, then we just gotta do what we gotta do.
I, however, don't think that we should migrate to development versions of packages because of UTF-8 issues, though. We could mention the updated development version on the Wiki or the "Locale issues" page, but I'm more into keeping with the policy of using 'stable' versions.
Where do we stop? If it is acceptable to migrate to development versions of packages because it provides enhanced functionality, or fixing brokenness to areas of the package that are only meaningful to *some* users, I'd bet we could update every BLFS package to a development version.
This is simply my opinion though. YMMV. Don't do anything just because of my opinion, please. Just consider it and do whatever you think is best.
comment:11 by , 19 years ago
Yeah, I think you're right about this. Although I consider it pretty stable relatively, I can't know what the developer thinks. I still want to use this version because it solves the gcc-4 issue as well, and I can't find Alexander's patch anymore. Anyway, could you help me decide on the wording for the note? Here's my first thought.
This version of <application>Mutt</application> is a development release. It is being used to workaround issues with <application>GCC-4</application> and provide UTF-8 locale support. To find the current stable release, please refer to the <ulink url="http://www.mutt.org/">Mutt home page</ulink>.
comment:12 by , 19 years ago
Since you asked: :-)
s/workaround/work around/
A workaround would typically be consider a noun, yet you're using it as a verb. To me 'work around' is more proper. But if it were me, I would use this (or something similar) as the second sentence:
"The BLFS staff has determined it provides a stable program and fixes some issues with the current stable version of Mutt: a segmentation fault which occurs under certain conditions and a compilation problem when building with GCC-&gcc-version;."
comment:13 by , 19 years ago
I did ask and I've taken your advice. In the future, I'll try to stick with stable versions and patch accordingly. If it turns out that 1.5.11 isn't stable, I'll gladly work up a patch for 1.4.2i that addresses the gcc-4 issues.
New commit in r5698.
comment:14 by , 19 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I'm going to upgrade to 1.5.10i for the SVN book. Should the patch go in the Errata for stable? Seems kind of silly since who build LFS SVN then BLFS stable. What do you think?