Bug 7367 - spamc/configure.pl: Can't exec `version.h.pl': No such file or directory at spamc/configure.pl line 74.
Summary: spamc/configure.pl: Can't exec `version.h.pl': No such file or directory at s...
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamc/spamd (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: All All
: P1 blocker
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL: https://cve.mitre.org/cgi-bin/cvename...
: 7378 7389 (view as bug list)
Depends on: 7378
  Show dependency tree
Reported: 2016-11-06 07:22 UTC by jidanni
Modified: 2017-11-01 21:31 UTC (History)
4 users (show)

Attachment Type Modified Status Actions Submitter/CLA Status
log application/gzip None jidanni@jidanni.org [NoCLA]
spamc/configure.pl.NEW patch None jidanni@jidanni.org [NoCLA]

Note You need to log in before you can comment on or make changes to this bug.
Description jidanni 2016-11-06 07:22:37 UTC
cd spamc
/usr/bin/perl version.h.pl
spamc/configure.pl: Can't exec `version.h.pl': No such file or directory at spamc/configure.pl line 74.
Comment 1 Bill Cole 2016-11-07 04:02:36 UTC
spamc/version.h.pl is present in a pristine checkout of the trunk and in a normal build procedure configure.pl finds it and runs it with no trouble. 

I suggest you redo your checkout of the source and try the build again.
Comment 2 jidanni 2016-11-07 07:09:30 UTC
Created attachment 5419 [details]

Sure, I bet if I started clean, it would all work.

But I am just alerting you, there is something you did that causes it
not to work on ALL my machines upgrading.

Sure, users could just clone the whole thing over each time, instead of
using subversion to only get the changed files. But is that really what
you want?
Comment 3 jidanni 2016-11-19 01:39:29 UTC
It fails despite your advice.
Comment 6 jidanni 2016-11-19 01:42:42 UTC
Yes the file DOES exist in the checkout, but that does not help anything.
Comment 7 jidanni 2016-12-02 00:09:34 UTC
By the way, "No such file or directory" is not necessarily the case always...
Comment 8 jidanni 2016-12-02 00:14:56 UTC
Debian$ man perlvar

       @INC    The array @INC contains the list of places that the "do EXPR",
               "require", or "use" constructs look for their library files.
               It initially consists of the arguments to any -I command-line
               switches, followed by the default Perl library, probably
               /usr/local/lib/perl, followed by ".", to represent the current
               directory.  ("." will not be appended if taint checks are
               enabled, either by "-T" or by "-t".)  In Debian, '.' is removed
               by /etc/perl/sitecustomize.pl by default, as a prelude to it
               being removed upstream in a future release. If you need to
               modify @INC at runtime, you should use the "use lib" pragma to
               get the machine-dependent library properly loaded also:

                   use lib '/mypath/libdir/';
                   use SomeMod;

               You can also insert hooks into the file inclusion system by
               putting Perl code directly into @INC.  Those hooks may be
               subroutine references, array references or blessed objects.
               See "require" in perlfunc for details.

Debian$ cat /etc/perl/sitecustomize.pl

# This script is only provided as a transition mechanism for
# removing the current working directory from the library search path
# while leaving a temporary way to override this locally.
# If you really need "." to be on @INC globally, you can comment
# this away for now. However, please note that this facility
# is expected to be removed after the Debian stretch release,
# at which point any code in this file will not have any effect.
# Please see CVE-2016-1238 for background information on the risks
# of having "." on @INC.

pop @INC if $INC[-1] eq '.' and !$ENV{PERL_USE_UNSAFE_INC};
Comment 9 jidanni 2016-12-02 00:16:09 UTC
Created attachment 5425 [details]
Comment 10 John Hardin 2017-02-13 02:16:58 UTC
Fixed on Trunk: Committed revision 1782716.
Fixed on 3.4 branch: Committed revision 1782717.
Comment 11 John Hardin 2017-02-13 02:26:14 UTC
*** Bug 7378 has been marked as a duplicate of this bug. ***
Comment 12 Todd Rinaldo 2017-11-01 21:31:45 UTC
*** Bug 7389 has been marked as a duplicate of this bug. ***