| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
None of these files are (or can be) executed directly, so drop the
spurious +x permission bit. None of the other tests do this either.
* t/built-sources-install-exec.sh: Remove +x bit.
* t/ccnoco-deps.sh: Likewise.
* t/ccnoco-lib.sh: Likewise.
* t/ccnoco-lt.sh: Likewise.
* t/perf/cond.sh: Likewise.
* t/perf/testsuite-recheck.sh: Likewise.
* t/perf/testsuite-summary.sh: Likewise.
* t/python-prefix.sh: Likewise.
* t/tags-lisp-space.sh: Likewise.
* t/test-extensions-empty.sh: Likewise.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This update has been made with 'make update-copyright'.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Gnulib, Emacs, etc. we are changing ftp: and http: URLs to use
https:, to discourage man-in-the-middle attacks when downloading
software. The attached patch propagates these changes upstream to
Automake. This patch does not affect files that Automake is
downstream of, which I'll patch separately.
Althouth the resources are not secret, plain HTTP is vulnerable to
malicious routers that tamper with responses from GNU servers,
and this sort of thing is all too common when people in some other
countries browse US-based websites. See, for example:
Aceto G, Botta A, Pescapé A, Awan MF, Ahmad T, Qaisar
S. Analyzing internet censorship in Pakistan. RTSI
2016. https://dx.doi.org/10.1109/RTSI.2016.7740626
HTTPS is not a complete solution here, but it can be a significant
help. The GNU project regularly serves up code to users, so we should
take some care here.
|
| |
|
|
| |
This update has been made with 'make update-copyright'.
|
| |
|
|
| |
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
| |
|
|
|
|
| |
We've been in 2014 already for few months now...
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
** Theoretical problems of AC_PROG_CC_C_O:
Both cc and $CC are checked to see if they support the '-c' and '-o'
options together.
This behaviour is highly inconsistent with that of the other macros
related to C compiler checks -- which test only $CC.
It can also cause unwarranted uses of the 'compile' script on systems
where the default 'cc' is inferior, but the user is compiling with a
proper, different compiler (e.g., gcc).
** Practical problems with our previous implementation of C support m4
macros in Automake:
- AM_PROG_AR must now be called *before* AC_PROG_CC; this wasn't the
case before, and it turns out there are packages in the wild that
relied on the old behaviour.
- The cross-referenced requirements and macro rewrites juggled among
AC_PROG_CC, AC_PROG_CC_C_O and AM_PROG_CC_C_O caused warnings in
autoconf; for example, in our test 't/libobj3.sh', we could see
warnings like these (here slightly tweaked for legibility):
configure.ac:5: AC_REQUIRE: `AC_PROG_CC' expanded before required
autoconf/c.m4:567: AC_PROG_CC_C_O is expanded from...
autoconf/c.m4:429: AC_LANG_COMPILER(C) is expanded from...
autoconf/lang.m4:329: AC_LANG_COMPILER_REQUIRE is expanded from...
autoconf/general.m4:2606: AC_COMPILE_IFELSE is expanded from...
m4sugar/m4sh.m4:639: AS_IF is expanded from...
autoconf/general.m4:2031: AC_CACHE_VAL is expanded from...
autoconf/general.m4:2052: AC_CACHE_CHECK is expanded from...
aclocal.m4:70: AM_PROG_AR is expanded from...
configure.ac:5: the top level
** Fix all of that:
We fix all of the described issues with a new internal m4 macro
_AM_PROG_CC_C_O (inspired to, but not based on, AC_PROG_CC_C_O) that
gets tacked on to AC_PROG_CC automatically (this is done in the
Automake-generated aclocal.m4) and that takes care of checking and
adjusting '$CC' for "-c -o" support.
The macro AM_PROG_CC_C_O is still present, but is now just a thin
wrapper around such Automake-enhanced AC_PROG_CC.
It is worth noting that the present patch causes three slight
*backward-incompatibilities*:
1. The name cache variable used by AM_PROG_CC_C_O is no longer
computed (at configure runtime!) from the content of '$CC',
but is statically defined as 'am_cv_prog_cc_c_o'.
2. 'cc' is no longer checked by AM_PROG_CC_C_O, only '$CC' is.
3. AM_PROG_CC_C_O no longer AC_DEFINE the C preprocessor symbol
'NO_MINUS_C_MINUS_O'.
Given however that the third change can easily be worked around, that
the first two changes can be legitimately seen as bug fixes, and that
the new semantics introduced by such changes will simplify the transition
to Automake 2.0 (when the 'subdir-objects' will always be enabled
unconditionally), we believe they are acceptable to be shipped with
Automake 1.14.
With this patch, we also revert some of the testsuite adjustments done
in previous commit v1.13.2-178-g9877109 of 2013-05-24 (compile: rewrite
AC_PROG_CC with AM_PROG_CC_C_O contents). Such adjustments are no longer
needed.
* m4/minuso.m4 (_AM_PROG_CC_C_O): New internal macro, basically and
adjusted version of a merge between Autoconf-provided AC_PROG_CC_C_O
and our old implementation of AM_PROG_CC_C_O.
(AM_PROG_CC_C_O): Redefine as a simple wrapper around AC_PROG_CC.
* m4/init.m4 (AC_PROG_CC): Append _AM_PROG_CC_C_O, not AM_PROG_CC_C_O,
to the pre-existing expansion of this macro.
* m4/ar-lib.m4 (AM_PROG_AR): No longer require it to be expanded after
AC_PROG_CC.
* t/aclocal-deps.sh: Move AC_PROG_CC invocation after AC_PROG_RANLIB
and AM_PROG_AR invocations. Things should work this way too (as they
used to).
* t/subobj-clean-lt-pr10697.sh: Likewise.
* t/alloca.sh: Move AC_PROG_CC invocation after AM_PROG_AR invocation.
* t/condlib.sh: Likewise.
* t/aclocal-deps.sh: Move AC_PROG_CC invocation after LT_INIT and
AM_PROG_AR invocations. Make autoconf and autoheader warnings fatal.
* t/am-prog-cc-c-o.sh: Adjust to the new semantics, enhance a little,
and reduce code duplication.
* t/ccnoco.sh: Make autoconf warnings fatal.
* t/subpkg.sh: Likewise.
* t/ccnoco-lib.sh: Likewise, and fix a comment.
* t/link_cond.sh: Enhance a couple of error messages.
* configure.ac: Drop "nullification" of AM_PROG_CC_C_O.
* NEWS: Adjust.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
|
|
This is a much simpler rewrite than the one we attempted in the past,
and that was later removed by commit 'v1.13.1d-137-g32eb770' of
2013-05-11 (compile: avoid AC_PROG_CC messy rewrite).
Not only this change simplifies the code a little, but has the welcome
collateral effect of making automatic dependency tracking work better
with compilers that doesn't grasp the '-c' and '-o' options together.
Issues in that setup have been caught by several failures in the target
'check-no-cc-c-o'.
Unfortunately, this change has less welcome collateral effects:
1. AM_PROG_AR must now be called *after* AC_PROG_CC;
2. Autoconf emits extra warnings when used with Automake-generated
aclocal.m4.
These are unacceptable regressions for a release, but since we are
going to fix them soon enough in a follow-up patch (surely to be
applied before Automake 1.14 is released) we don't worry too much.
* m4/init.m4: Redefine AC_PROG_CC early, to automatically invoke
AM_PROG_CC_C_O as well. Accordingly, drop now-unneeded "automagical"
AM_PROG_CC_C_O expansion at later time (which took place thanks to
a AC_CONFIG_COMMANDS_PRE call).
* m4/minuso.m4 (AM_PROG_CC_C_O): Ensure the expansion of the body
of this macro takes place with C as "current Autoconf language" (use
AC_LANG_PUSH/AC_LANG_POP).
* m4/ar-lib.m4 (AM_PROG_AR): Likewise. Also, require this macro to
be expanded *after* AC_PROG_CC (so that any rewrite of $CC, if required,
has already taken place).
* t/add-missing.tap: Adjust to avoid spurious failures.
* t/aclocal-deps.sh: Likewise, by having AM_PROG_AR called *after*
AC_PROG_CC.
* t/subobj-clean-lt-pr10697.sh: Likewise.
* t/alloca.sh: Likewise.
* t/condlib.sh: Likewise.
* t/discover.sh: Likewise.
* t/objc-megademo.sh: Likewise.
* t/ccnoco.sh: Extend a little.
* t/ccnoco-deps.sh: New test.
* t/ccnoco-lib.sh: Likewise.
* t/ccnoco-lt.sh: Likewise.
* t/list-of-tests.mk: Add them.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
