Try harder to nasm_realpath() to be as portable as possible. Move it
to a separate file since it has gotten complex enough that it is
cleaner that way.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Looks like -Werror=missing-declarations revealed problem in
configure: the "inline" support has not been detected properly
leading to problem in building procedure.
Lets move AC_C_INLINE and etc to be tested before gcc flags.
Reported-by: NAKAI Yuta <nak5124@live.jp>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
This reverts commit 99427bdb6c.
We don't include generated files in the repository, instead we should
pregenerate them for the tarball generation, just as we do for the
Perl-generated files.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
It's been reported that force people to install
asciidoc for man pages generation is not acceptible.
Just ship them pregenerated.
http://bugzilla.nasm.us/show_bug.cgi?id=3392262
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
It's been noticed on nasm forum that we don't complain
if no asciidoc/xmlto package installed on a system while
they are required for man pages generation.
So warn a user then, but still allow to build nasm.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Add strlcpy() function and implementation, and use configure to detect
if strlcpy() is natively available on the system.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
OpenWatcom 1.8 has a C99 mode, which implements _Bool and
<stdbool.h>. Unfortunately the implementation is broken, and doesn't
let _Bool be implicitly converted to integer (as required by the C99
spec). Detect this case in autoconf.
For PostScript to PDF conversion, use whichever of "acrodist",
"ps2pdf", or "pstopdf" which we can find on the system. I haven't
tried either acrodist or pstopdf myself, only going my the
documentation, but prefer acrodist since it is claimed to produce
smaller output files than ps2pdf.
Use autoconf to detect littleendian word order, and use
WORDS_LITTLEENDIAN instead of X86_MEMORY when we don't require
unaligned memory accesses to be permitted.
Some platforms apparently feel -std=c99, which defines
__STRICT_ANSI__, should also hide a bunch of function prototypes.
This rather sucks. At least try to deal with it.
MinGW and DJGPP both have this problem, in particular.
Both C and C++ have "bool", "true" and "false" in lower case; C
requires <stdbool.h> for this, in C++ it is an inherent type built
into the compiler. Use those instead of the old macros; emulate with
a simple typedef enum if unavailable.
Concentrate compiler dependencies to compiler.h; make sure compiler.h
is included first in every .c file (since some prototypes may depend
on the presence of feature request macros.)
Actually use the conditional inclusion of various functions (totally
broken in previous releases.)
To deal with fools^Wpeople trying to keep really old systems alive,
create a proper framework for substitution functions, and make it
possible to deal with the lack of snprintf/vsnprintf in particular.
We can actually test for the options being accepted, rather than try
to test for gcc; this handles differences between gcc versions as well
as compilers with a similar command line set.
- Remove obsolete types like "uint32"; use "uint32_t" consistently.
- Make sure we include <inttypes.h> where needed.
- Header file guards should be FOO_H or SUBDIR_FOO_H; _FOO_H infringes
on the C implementation's namespace and should only be used when
writing libc!
- Change a few "int8_t" back to "char" where appropriate. There are
a lot more places where that should be done, though.
- Clean up the check for getuid/getgid in rdoff/rdlar.h.
actually *use* the resulting configuration file, but it keeps autoconf
from creating an insanely long compiler command line, which can cause
problems all by itself. Eventually we can do:
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
... to get the same information.