This causes clang to give fewer warnings of implicit declarations of
functions.
In mach/pdp/cv/cv.c, rename wr_int2() to cv_int2() because it
conflicts with wr_int2() in <object.h>.
In util/ack, rename F_OK to F_TRANSFORM because it conflicts with F_OK
for access() in <unistd.h>.
With this change, I built and ran ack on a big-endian PowerPC Linux
machine. I used gcc 4.9.4 to build ack, and I only built the linuxppc
back end.
Before this change, wr_ranlib() corrupted a value by changing it from
0x66 to 0x66000066. This value was too big, so led made a fatal
error, "bad ranlib string offset".
This header declares functions in libobject. Our programs never
included object.h, but called functions in libobject without declaring
them. So, our build system never put object.h in the include path;
any #include <object.h> would fail to find the header.
With this commit, a program may #include <object.h> if it has
modules/src/object+lib in its deps.
Declare structs in object.h so we can use them in prototypes without
gcc warning, "'struct whatever' declared inside parameter list".
Remove inclusion of ansi.h from object.h. Programs would need to
depend on modules+headers to get ansi.h in the include path.
the number of types of relocation possible in the object file. (Now,
hopefully, working.)
Also change the object serialiser/deserialiser to never try to read or
write raw structures; it's way safer this way and we don't need the
performance boost any more.
--HG--
branch : default-branch
These files "magically reappeared" after the conversion from CVS to
Mercurial. The old CVS repository deleted these files but did not
record *when* it deleted these files. The conversion resurrected these
files because they have no history of deletion. These files were
probably deleted before year 1995. The CVS repository begins to record
deletions around 1995.
These files may still appear in older revisions of this Mercurial
repository, when they should already be deleted. There is no way to fix
this, because the CVS repository provides no dates of deletion.
See http://sourceforge.net/mailarchive/message.php?msg_id=29823032
