Bug 7617 - spamc cannot be build on Windows
Summary: spamc cannot be build on Windows
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamc/spamd (show other bugs)
Version: 3.4 SVN branch
Hardware: PC Windows 7
: P2 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-06 11:19 UTC by Martin Puppe
Modified: 2018-09-17 11:14 UTC (History)
2 users (show)



Attachment Type Modified Status Actions Submitter/CLA Status
Proposed patch patch None Martin Puppe [HasCLA]

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Puppe 2018-09-06 11:19:29 UTC
Building spamc currently fails on Windows. This is caused by two issues:

1. There is a subtle bug in spamc/Makefile.win (see also bug #7393).
2. spamc/getopt.c is not POSIX-compliant.

Regarding 1.: The first line of the target for spamc/spamc.exe changes the working directory. However, dmake (installed with Strawberry Perl 5.24) and GNU make (gmake, installed with Strawberry Perl 5.28) spawn a sub-shell for each command [^1][^2]. The change of directory thus only affects the sub-shell and is "forgotten" immediately afterwards.

Regarding 2.: spamc/getopt.c uses function err from err.h, which is not part of the POSIX standard [^3], and thus it is not availabe on Windows, neither natively nor in MinGW.

I have fixes for these issues mostly ready. I will submit a patch, once I have verified that no tests are negatively affected by this.

[^1]: https://www.openoffice.org/tools/dmake/dmake_4.11.html, see section MAKING TARGETS
[^2]: https://www.gnu.org/software/make/manual/html_node/Execution.html#Execution
[^3]: "These functions are nonstandard BSD extensions." https://man.cx/err
Comment 1 Martin Puppe 2018-09-06 12:57:33 UTC
Created attachment 5595 [details]
Proposed patch

Here is the proposed patch. Both fixes are relatively straight-forward. I have tried to replicate the behavior of err. The new implementation is mostly equivalent with one exception. Instead of "the last component of the program name" [^1], my implementation prints argv[0]. Is that acceptable?

[^1]: http://man7.org/linux/man-pages/man3/err.3.html
Comment 2 Kevin A. McGrail 2018-09-17 11:14:54 UTC
I don't have any concern on an error message using argv before an exit.

3.4:
Committed revision 1841065.
trunk:
Committed revision 1841066.