Closed psaavedra closed 7 months ago
Your fix is correct; although _
is a name in use, by GNU gettext, as a function --or function-like macro; I don't know-- _()
).
You'll need to use a different name.
$ grepc unused .
./lib/attr.h:# define unused __attribute__((unused))
./lib/attr.h:# define unused
./src/su.c:static void kill_child (int unused(s));
unused
is a macro defined by us. I happened to look at that code a few days ago, and was surprised that it didn't result in a build error, but since nobody reported such a problem, I guessed I was missing something. It seems I was right to suspect of it.
I would also send a patch for renaming the unused macro to UNUSED. Would you mind?
I would also send a patch for renaming the unused macro to UNUSED. Would you mind?
Pushed a PR for master. I think another one is going to be needed for the 4.14.x branch.
I think another one is going to be needed for the 4.14.x branch.
No PR needed. The commit will be picked.
No PR needed. The commit will be picked.
OK. The cherry-pick is not straightforward but easy to adapt. I left in my fork the backport commit just as reference: e1e95951b0b9553e801b57ccd153c42baa956caa
What I meant to say is that after the PR to master you dont need to do anything. The maintainer of the stable branches will select the commits from master as they see fit.
No PR needed. The commit will be picked.
OK. The cherry-pick is not straightforward but easy to adapt. I left in my fork the backport commit just as reference: e1e95951b0b9553e801b57ccd153c42baa956caa
Thanks, but for the stable branch, I'll omit the renaming of the macro, so the fix should be trivial to backport.
But yeah, thanks for suggesting a backport in case the cherry-pick gets tricky.
I'm getting this error building shadow 4.14.2:
I am using
gcc (Debian 10.2.1-6) 10.2.1 20210110
in this context.The following patch fix the error but I am not 100% sure if this is the exected: