hat even on modern systems, hard links are only reliably usable
within the same directory. The example in the Stack Exchange question is
hard-linking to a different directory, which I would expect to fail in
lots of situations, such as on AFS file systems.)
--
Russ Allbery (ea...@eyrie.org)
rl
5.33.3 (which included 0.2311).
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
stem you will build on will
need the CC modification anyway."
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
typical
user may not have locally.
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
kouts/gnu/autoconf/manual/autoconf-2.71/html_node/Common-Shell-Constructs.html#index-AS_005fIF-1
The principle that one should always use an AS_* construct if one exists
rather than regular shell constructs could probably be documented more
aggressively.
--
Russ Allbery (ea...@eyrie.org)
ast.
I recognize that there will be overlap once file timestamps are past 2038
and that will happen sooner than anyone plans for, but it's still true
that this has *not* happened right now and this therefore is not currently
creating many bugs, whereas this switch in this way will create many
ture pain ever since.
Interestingly, at around the same time they made that decision, they also
dropped bcopy and bzero from the standard library, provoking a ton of
porting problems. (They reversed that decision later and added them
back.)
--
Russ Allbery (ea...@eyrie.org) <https://w
I still do anyway, for maintainer builds, and have not had
any real problems with that (and have been grateful to pick up new
warnings automatically), but it shouldn't be a default.
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
Wvla],
[RRA_PROG_CC_FLAG(flag,
[WARNINGS_CFLAGS="${WARNINGS_CFLAGS} flag"])])])
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
mpiler is Clang], [rra_cv_prog_cc_clang],
[AC_COMPILE_IFELSE([AC_LANG_SOURCE([_RRA_PROG_CC_CLANG_SOURCE])],
[rra_cv_prog_cc_clang=yes],
[rra_cv_prog_cc_clang=no])])
AS_IF([test x"$rra_cv_prog_cc_clang" = xyes], [CLANG=yes])])
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
t "$ac_cv_have_C__func__" = 'yes'], [
AC_DEFINE([HAS_C__func__],[1],[Define if C compiler supports __func__])
])
])
This will protect against a lot of edge cases.
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
make manual:
https://www.gnu.org/software/automake/manual/html_node/Renamed-Objects.html
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
rompt for us to
fix it. :) (Debian will almost certainly just point sharedstatedir at
the same directory as localstatedir.)
--
Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
___
Autoconf mailing list
Autoconf@gnu.org
http
hing like `exit 96`
> Do you have any experience/thoughts about this?
Personally, I'd make the actual test a tiny C program that execs argv,
waits for it to exit, and then inspects the resulting exit status to see
if it died with SIGABRT.
--
Russ Allbery (ea...@eyrie.org) <
or this specific request, it would surprise me a
good deal if Android would move sh and not also move env to some other
directory than /usr/bin. If you're going to break compatibility that
much, it's unlikely you're going to keep compatibility for env. But,
well, I've been surprised before..
e looking for.
$datadir/, no? Script libraries are almost certainly
architecture-independent.
--
Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
, you should not rely on 'AC_CONFIG_FILES' to replace
| 'bindir' and friends in your shell scripts and other files; instead, let
| 'make' manage their replacement.
There are more details in this section ("Installation Directory
Variables") about how to write Makefile rules to do th
e it as easy as
possible to get free software working on any platform, even proprietary
platforms, because that's how we get our foot in the door, and that's how
we get more people using free software. Let's save strategic lack of
cooperation for some other area where the benefits for users
, if GCC added a new define, the other compilers would just start
defining that symbol as well.
I'm afraid the only hope you have, if you depend on extensions that are
not implemented by other compilers, is to test explicitly for those
extensions.
--
Russ Allbery (ea...@eyrie.org) http
a given flag is used to simply not
use that flag there.
For this particular situation, which I think is relatively rare, I would
just parse the output of gcc -v.
--
Russ Allbery (ea...@eyrie.org) http://www.eyrie.org/~eagle/
___
Autoconf
missing?
Occasionally I've used the pattern
save_LIBS=$LIBS
AC_SEARCH_LIBS([...
LIBS=$save_LIBS
Likewise. I do this a lot.
--
Russ Allbery (ea...@eyrie.org) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
https
given NULL, 0 as the first arguments to snprintf, which makes it
impossible to use snprintf safely in many programs.
See:
https://www.gnu.org/software/gnulib/manual/html_node/snprintf.html
for more information about the portability mess.
--
Russ Allbery (ea...@eyrie.org) http
basically
inherent in how the feature test macros work. But it's worth being aware
of. All namespace bets are essentially off once you enable system
extensions.
--
Russ Allbery (ea...@eyrie.org) http://www.eyrie.org/~eagle/
___
Autoconf
is not the best, but the functionality you
need is there. I would rewrite the example as:
AC_CACHE_CHECK([for m4 that supports indir], [ac_cv_path_M4_indir],
[AC_PATH_PROGS_FEATURE_CHECK([M4_indir], [m4 gm4],
...
AC_SUBST([M4], [$ac_cv_path_M4_indir])
--
Russ Allbery (ea
Peter Rosin p...@lysator.liu.se writes:
On 2014-02-27 01:20, Russ Allbery wrote:
Wouldn't you name the variable FOO_FEATURE? In other words, I think
the example in the Autoconf manual is not the best, but the
functionality you need is there. I would rewrite the example
be more portable than trying to grep the assembly
output.
--
Russ Allbery (ea...@eyrie.org) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
extent to --std=c99 or --std=c11.
--
Russ Allbery (ea...@eyrie.org) http://www.eyrie.org/~eagle/
, or
unless it's only turned on optionally.
--
Russ Allbery (ea...@eyrie.org) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
.
--
Russ Allbery (ea...@eyrie.org) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
,
which may be the case here.
Short version: If I'm right, find where the configure script is throwing
$FREETYPE_LIBS into $LDFLAGS and change it to add those flags to $LIBS
instead.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
?
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
(...)])
But if the contents of m4_ifdef expand into shell code, doesn't this
prepend : to the first line of that shell code, effectively commenting it
out? It seems cleaner to use [:] in the else branch of m4_ifdef for that
reason.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle
Eric Blake ebl...@redhat.com writes:
If that's the case, then write AM_CONDITIONAL so that it always produces
a shell statement:
m4_define_default([AM_CONDITIONAL], [:])
Oh, good idea. Yes, that's even cleaner.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle
if it is not available.
You may also want to test for long long availability before
including it in the union...
And long double, which IIRC is more of a portability issue than long long.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle
Peter Rosin p...@lysator.liu.se writes:
On 2013-06-01 00:06, Russ Allbery wrote:
Autoconf doesn't work with MSVC directly so far as I know. All of the
packages I have that are ported to MSVC have a separate hand-written
config.h that's used for MSVC builds, and in that file one simply
Peter Rosin p...@lysator.liu.se writes:
On 2013-06-01 08:09, Russ Allbery wrote:
Peter Rosin writes:
On 2013-06-01 00:06, Russ Allbery wrote:
Autoconf doesn't work with MSVC directly so far as I know. All of
the packages I have that are ported to MSVC have a separate
hand-written config.h
that and do not prototype
those functions in string.h. I'm quite sure there is code out there that
assumes that Autoconf will probe for strings.h as a side effect of other
probes and set HAVE_STRINGS_H, and therefore doesn't probe for it
explicitly. (I maintain some of it, in fact.)
--
Russ
the standard Autoconf header probes do.
This behavior is not currently clearly documented, but I will point out
that the current documentation of AC_INCLUDES_DEFAULT shows use of the
HAVE_STRINGS_H define without any mention of any other required checks.
--
Russ Allbery (r...@stanford.edu
my concern.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
misunderstood something?
Autoconf doesn't work with MSVC directly so far as I know. All of the
packages I have that are ported to MSVC have a separate hand-written
config.h that's used for MSVC builds, and in that file one simply doesn't
define HAVE_STRINGS_H.
--
Russ Allbery (r...@stanford.edu
this in different ways. As always with Debian,
though, we're not very centralized about practices, so it takes a while to
get this deployed consistently across the whole archive.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle
back and revisited.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
and don't really notice a significant difference.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
way of expressing things and just adds complexity to no real purpose.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
an alternative, but some searching (I'm not
horribly familiar with the regex syntax in expr) says:
`expr //$file : '.*/\([^/]*\)'`
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
to add -Wno-portability
to the Automake flags (in AM_INIT_AUTOMAKE, for example).
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
not portable. Omitting the destination
argument to ln is a GNU extension. Try changing that to:
ln -s PerlMAgick/quantum/Q16.xs Q16.xs
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
exactly what goes into them.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
builds.
(ssize_t was the thing I ran into most recently that Windows doesn't have
but which is otherwise universal and required by POSIX.)
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf
a DoS, but rather to gain additional
*performance* by removing all the checks done via assert(). If your goal
is to favor security over performance, you never want to use -DNDEBUG.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle
changes is
that the needs of embedded systems, who are heavy toolchain users, are
often quite different.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman
from the start. Yes, it's probably slower, but I'll trade
speed for clarity and safety nearly all of the time.
(Or you could also dodge the memory management problems by using a C
framework that supports garbage collection, like APR, but that's farther
afield of this list.)
--
Russ Allbery (r
obstacks or APR pools) instead.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
for the software I write.)
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Adrian Bunk b...@stusta.de writes:
On Sat, Oct 27, 2012 at 06:45:01PM -0700, Russ Allbery wrote:
Almost none of the software that I work on requires a 64-bit integer type.
(C89 or later is also my default target for the software I write.)
I just tried to build remctl and lbcd with CC=gcc
support onto an old (20+ years in this case) code base with its
own extremely complex build system.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
that as a permanent fork.)
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
you need for arm64? We could also recommend
dh_autoreconf at the same time, which might resolve a lot of these
problems going forward.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
, and those will generally work fine on a new Debian
architecture as long as config.guess/config.sub doesn't explode when
attempting to determine the triplet.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf
Bruce Korb bk...@gnu.org writes:
On 09/19/12 11:03, Russ Allbery wrote:
... I believe the method using sed is
correct, and generating the file at Autoconf time is not as correct...
For my perspective, there really ought to be a simple macro that just
exports all the configured values
' at configure time, even if it's not common.
So yes, you could use config.status, but only if it also had a flag that
said to fully expand the variables before substituting them in, and I
suspect that's a fair amount of change to the script.
--
Russ Allbery (r...@stanford.edu) http
Nick Bowler nbow...@elliptictech.com writes:
On 2012-09-20 13:14 -0700, Russ Allbery wrote:
config.status also doesn't fully expand the variables, though, which is
something that you'd want for this sort of application. Otherwise, you
have to know all of the possible ways in which one
natively rather
than requiring that people roll it themselves.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
. :-)
Thus making the problem much better by *guaranteeing* that the *.pc file
is wrong if there are any make-time overrides! Er, wait :)
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf
/lib/i386-linux-gnu
Name: remctl
Description: Remote authenticated command execution with ACLs
URL: http://www.eyrie.org/~eagle/software/remctl/
Version: 3.2
Cflags: -I${includedir}
Libs: -L${libdir} -lremctl
Libs.private: -lgssapi_krb5
--
Russ Allbery (r...@stanford.edu
it as well as letting make just do
the expansion.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Mike Frysinger vap...@gentoo.org writes:
On Wednesday 19 September 2012 14:03:51 Russ Allbery wrote:
That macro has gotten better (it at least doesn't put the user's
CPPFLAGS and LDFLAGS into the *.pc file like it used to), but I still
would not recommend people use it. By default, it still
are just following
cookbooks and who aren't prepared to debug the software are not going to
gain anything useful by enabling a bunch of optional warnings, let alone
trying to use -Werror.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle
a debugging tool to find potential security problems.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
please don't do
that. :) (Other common culprits for this are the headers generated by
scripting languages for their dynamically-loaded extension mechanism.)
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing
line.
I suspect the above is what's happening when you see this in really old
projects, and in newer projects it's copy and paste from older projects.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing
Miles Bader mi...@gnu.org writes:
Russ Allbery r...@stanford.edu writes:
Also, you should generally not add -Wall -Wextra to the configure
flags, and instead add it after configure completes, since many of the
tricks configure has to use will result in warnings when you turn on
all
, ... if they are, these checks need to be
considered broken ;)
I've clearly just misremembered, then. Apologies for the noise.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
https
in CFLAGS and don't worry about the difference. Libtool is already
adding -fPIC -shared when building the shared objects, and is smart enough
to drop -fPIE from the shared objects as pointless.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle
configure completes, since many of the tricks
configure has to use will result in warnings when you turn on all the
compiler warnings, which can confuse configure.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf
directly in standard
Autoconf macros for handling compiler warning flags, although I suspect
there is stuff in both the macro archive and in gnulib.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
with personally):
http://wiki.debian.org/Hardening/
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
function.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
the places where it's appropriate.
Note that it is safe to pass -fPIE globally via CFLAGS even if shared
libraries (which must use -fPIC instead of -fPIE) are in play provided
Libtool is in use, since Libtool is smart enough to not pass -fPIE into
shared library builds.
--
Russ Allbery (r...@stanford.edu
that is portable on a practical
level (meaning that people on multiple UNIX platforms can just run
./configure make).
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org
). The
easiest way to work around this is probably to change the Automake helper
functions that sit between the code and the Perl open command and have
them switch to calling open with two arguments if the file name is -.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle
James K. Lowden jklow...@schemamania.org writes:
Russ Allbery r...@stanford.edu wrote:
is primarily a source of bugs and annoyances
Based on what?
Problems just like the one on this thread, or the breakage Debian saw with
multiarch and headers that relied on , or similar problems that we've
modify the source, get rid of all uses of in #include. I
would recommend never using if you can avoid it. Once you have a good
build system that can handle adding the appropriate -I flags for the
compiler, is primarily a source of bugs and annoyances and not really a
help.
--
Russ Allbery (r
message;
}
on Windows (obviously not threadsafe; you have to do other things if you
need to be threadsafe).
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
not sure that you can make
that assumption. Can't Autoconf be used to cross-compile software for a
free-standing target, where several of those header files are not
required to exist?
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
Jim Meyering j...@meyering.net writes:
If you were more intimately familiar with gzip's code, you would have
switched long ago ;-)
[...]
Thanks for this. I hadn't realized the issues with the gzip code.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle
all the same to me. But
I'm fairly unconvinced by the larger argument that free software
developers should move to xz and away from gzip.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf
Someone mentioned in another forum that I read that the autoreconf
Invocation node of the Autoconf manual has a typo: -V (upper-case) is
shown as the short option for both --version and --verbose. From the
--help output, it looks like this should be -v for --verbose.
--
Russ Allbery (r
([AC_LANG_SOURCE([int x;])], [opt_ok=yes], [opt_ok=no])
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Miles Bader mi...@gnu.org writes:
Russ Allbery r...@stanford.edu writes:
You're missing a level of quoting. That should be:
AC_COMPILE_IFELSE([AC_LANG_SOURCE([int x;])], [opt_ok=yes], [opt_ok=no])
Hmm, ok.
[I'm not sure if I'm _ever_ going to really have any intuitive sense
is obsolete and gnulib should be used instead.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
will have different
names and will therefore not need to retain compatibility with the
same-named macros in Autoconf.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org
mind, then. :)
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
to the autoconf-doc package for that file.
Could you report this against autoconf via reportbug?
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
system that does some
things that Automake can't easily handle, such as build kernel modules for
nearly a dozen versions of UNIX.)
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
of platforms.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
someone feel more welcome by not
literally writing their gender out of the manual, and the reward is far
stronger than the small loss of perceived elegance of wording.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
). I tend to use the abs_*
versions as a matter of course since they avoid weird issues.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo
, and mails out the log file if anything fails is sufficient for
what I've done. I just wrote a simple one myself.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
http
only run by developers.
This approach also lets me use gcc-specific warning flags since I know the
developers will be using gcc, as opposed to end users who may be using a
wide variety of other compilers.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle
1 - 100 of 292 matches
Mail list logo
