On 08/17/2017 11:28 PM, Dmitry V. Levin wrote:
On Thu, Aug 17, 2017 at 08:16:12AM +0300, Panu Matilainen wrote:
On 08/16/2017 11:51 PM, Dmitry V. Levin wrote:
On Thu, Aug 10, 2017 at 08:15:02PM +0300, Panu Matilainen wrote:
The subtle test is too subtle for its own good, this patch breaks
thirty six testcases on 32bit architectures.
This reverts commit 1eadabe4453ef32eb6c3bc837094e1ca998affcc.
[leaving non-technical part aside for a while]
But as the
revert commit message says, the test is way too subtle for my liking, I
never liked it at all because of that. In retrospective, that distrust
combined with the clock-is-ticking situation ... I don't think I ever
actually thought to suspect fakechroot in this case.
Sorry but your distrust of AC_CHECK_HEADERS([fts.h]) looks rather irrational.
What kind of doubts do you have wrt this very basic test?
Do you have any doubts about AC_CHECK_HEADERS documented behaviour, e.g.
that it uses the compiler to test header usability, and it is affected
by the arrangements made by AC_SYS_LARGEFILE?
Even the memorable 8-year-old change of AC_CHECK_HEADERS behaviour
described in [1] shouldn't affect this case because glibc's fts.h used
to issue an "#error" in case of _FILE_OFFSET_BITS==64 thus breaking
the preprocessor test, too.
There are plenty of AC_CHECK_HEADERS invocations in configure.ac -
do they also look doubtful to you?
Meh.
"Any technology, no matter how primitive, is magic to those who don't
understand it."
The "earlier configure.ac foo hidden side-effects cause this to do
something else" that somehow ends up being completely counter-intuitive
and magic to me. I'm still deep in the superstition phase when in comes
to autoconf ;)
- Panu -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
