| Summary: | net-mail/mailutils-2.99.98-r1 fails to compile in hardened/linux/musl/amd64 profile. | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Chad Joan <chadjoan> |
| Component: | Hardened | Assignee: | Gentoo musl team <musl> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 430702 | ||
| Attachments: |
Build log.
emerge --info emerge -pqv mailutils-2.99.98-musl-libc.patch mailutils-ebuilds.tar.gz |
||
Created attachment 458074 [details]
emerge --info
Created attachment 458076 [details]
emerge -pqv
Update:
Versions 2.99.99 and 3.0 fail with the same error.
In version 3.1, the error goes away, but then errors like this take its place:
argcvrem.c:24:29: fatal error: mailutils/argcv.h: No such file or directory
#include <mailutils/argcv.h>
^
compilation terminated.
[...]
argcvjoin.c:24:29: fatal error: mailutils/argcv.h: No such file or directory
#include <mailutils/argcv.h>
^
compilation terminated.
libtool: compile: x86_64-gentoo-linux-musl-gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../include -I../../include -I/libmailutils -DSYSCONFDIR=\"/etc\" -DSITE_VIRTUAL_PWDDIR=\"/etc/domain\" -DLOCALEDIR=\"/usr/share/locale\" -DSYSCONFDIR=\"/etc\" -march=x86-64 -mtune=core-avx2 -O2 -pipe -g -fno-strict-aliasing -Wall -Wdeclaration-after-statement -c rfc2047.c -fPIC -DPIC -o .libs/rfc2047.o
Makefile:1159: recipe for target 'argcvjoin.lo' failed
make[4]: *** [argcvjoin.lo] Error 1
argcvfree.c:24:29: fatal error: mailutils/argcv.h: No such file or directory
#include <mailutils/argcv.h>
^
compilation terminated.
libtool: compile: x86_64-gentoo-linux-musl-gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../include -I../../include -I/libmailutils -DSYSCONFDIR=\"/etc\" -DSITE_VIRTUAL_PWDDIR=\"/etc/domain\" -DLOCALEDIR=\"/usr/share/locale\" -DSYSCONFDIR=\"/etc\" -march=x86-64 -mtune=core-avx2 -O2 -pipe -g -fno-strict-aliasing -Wall -Wdeclaration-after-statement -c tilde.c -fPIC -DPIC -o .libs/tilde.o
Makefile:1159: recipe for target 'argcvfree.lo' failed
make[4]: *** [argcvfree.lo] Error 1
msgid.c:36:29: fatal error: mailutils/argcv.h: No such file or directory
#include <mailutils/argcv.h>
^
compilation terminated.
Update:
I tried building mailutils myself on the machine from cloned git repositories.
Release 3.1.1 and git HEAD (66f7ed9562cce859f20166f9cf0c38a018a83dbe) both fail to compile with:
str.c: In function 'mu_sockaddr_to_astr':
str.c:96:15: error: 'NULL' undeclared (first use in this function)
char *buf = NULL;
^
str.c:96:15: note: each undeclared identifier is reported only once for each function it appears in
My conclusion is that the missing argcv.h file thing was possibly a short-lived and maybe-unrelated bug in release 3.1 specifically. Thus, I am going to focus my efforts on that bit where NULL is undeclared (and anything else afterwards), which looks to me like mailutils did something not-entirely-standard with macros and musl is getting picky about it. I'll work on it some more.
Created attachment 458196 [details, diff]
mailutils-2.99.98-musl-libc.patch
All it needed was for #include <stddef.h> to be added, and that provides a proper source for the NULL definition on musl systems. Easy one-liner.
This patch should work for all mailutils ebuilds. I have tested it on all versions in portage at the moment (2.99.98, 2.99.98-r1, 2.99.99, 3.0, 3.1). Yes, even 3.1: I can get 3.1 to compile if I have an already-installed version providing the argcv.h file in /usr/include/mailutils/argcv.h. It also compiles on the git HEAD, which was where I wrote it.
Created attachment 458198 [details]
mailutils-ebuilds.tar.gz
This gzip file contains all of the .ebuild files that I have in my local overlay, modified to use the previously attached patch. I'm not sure how to patch the portage tree, so I am just giving you all the .ebuild files in a state that works for me.
To get a working package, just extract these into */net-mail/mailutils/, place the patch in */net-mail/mailutils/files/, and run 'ebuild mailutils-xyz.ebuild manifest' as needed.
Hope that helps.
I have notified the upstream maintainer, Sergey Poznyakoff, by emailing him the patch and a pull request using his email found in the project's git logs. Hopefully this will help fix the bug for future ebuilds and on other distros. Your patch looks good. Thanks for submitting it upstream! Sorry for doing something similar without contacting you: http://lists.gnu.org/archive/html/bug-mailutils/2016-12/msg00054.html (I wanted to post the archive link to this bug, but because I wasn't subscribed it took a while for my mail to show up in the archive.) Looking at the activity of the upstream git repository, I would expect that this issue will soon be fixed in upstream git. Then you could submit a pull request for the main gentoo repository: https://wiki.gentoo.org/wiki/Gentoo_Github Ah, no worries. It'd be nice to know, but I kind of assumed that looking for dupes on the bugzilla would solve that problem, therefore I don't expect any kind of a personal notification :) Well, bugzilla entries would help a lot, but I won't be upset if some of them get missed here or there and cost me some time (especially if it's because you or someone else is busy contributing a lot). Thanks for the links! I'll look over Gentoo pull-request practice at some point and give it a shot when I get the chance. My time is scattered, so in the coming future I will probably prioritize opening bug reports based on things I encounter on my system (versus researching upstream responses, writing patches, or making pull requests). That will give others a chance to work on them before I revisit them at some unknown-to-me later time ;) Thanks Felix! (In reply to Chad Joan from comment #9) > Ah, no worries. > > It'd be nice to know, but I kind of assumed that looking for dupes on the > bugzilla would solve that problem, therefore I don't expect any kind of a > personal notification :) Well, bugzilla entries would help a lot, but I > won't be upset if some of them get missed here or there and cost me some > time (especially if it's because you or someone else is busy contributing a > lot). > > Thanks for the links! I'll look over Gentoo pull-request practice at some > point and give it a shot when I get the chance. > > My time is scattered, so in the coming future I will probably prioritize > opening bug reports based on things I encounter on my system (versus > researching upstream responses, writing patches, or making pull requests). > That will give others a chance to work on them before I revisit them at some > unknown-to-me later time ;) > > Thanks Felix! Should we add this patch in the tree? (In reply to Anthony Basile from comment #10) > > Should we add this patch in the tree? Yes definitely, but only for existing versions (not future). I suspect that the next release from upstream will have the fix. There is a commit for it here in the mailutils git repo: http://git.savannah.gnu.org/cgit/mailutils.git/commit/?id=068c059972fbc53d734ab816d7583ec2fb918b12 Hope that helps. This appears to be fixed in v3.2 I was able to successfully merge net-mail/mailutils-3.2::gentoo on the machine. If we're not going to patch the earlier versions, then I recommend masking them in the hardened musl profile, and, if possible, stabilizing net-mail/mailutils-3.2. This would prevent hardened musl users from accidentally pulling in versions with broken builds on this profile. Hope that helps. (In reply to Chad Joan from comment #12) > This appears to be fixed in v3.2 > > I was able to successfully merge net-mail/mailutils-3.2::gentoo on the > machine. > > If we're not going to patch the earlier versions, then I recommend masking > them in the hardened musl profile, and, if possible, stabilizing > net-mail/mailutils-3.2. This would prevent hardened musl users from > accidentally pulling in versions with broken builds on this profile. > > Hope that helps. i've masked it and will work towards stabilizing 3.2 Awesome; thanks! |
Created attachment 458072 [details] Build log. Build fails, I think this error kills it: str.c: In function 'mu_sockaddr_to_astr': str.c:96:15: error: 'NULL' undeclared (first use in this function) char *buf = NULL; ^ str.c:96:15: note: each undeclared identifier is reported only once for each function it appears in Looks musl-related to me; my apologies if otherwise.