This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFC] libiberty build failure after upgrade to autoconf 2.57


Hello,

I noticed that GDB failed trying to build clock.c in libiberty because
the declaration of function "clock" in clock.c was conflicting with
the declaration of "clock" in /usr/include/sys/time.h. Since libiberty
is shared between GDB and GCC, presumably the same failure applies on
GCC as well.

libiberty's idea of clock: long clock ();
HP/UX's idea of clock: clock_t clock();

Since "clock" is provided by the system, it seems that configure has
incorrectly determined that the libiberty version of clock should be
used.

Basically, the sequence of events is the following: 
  - configure tests for "clock"
  - gcc fails to compile the test program because the declaration
    used in the test program conflicts with the one provided by HP/UX.
  - So configure adds clock.c to the list of files to be included
    in libiberty
  - during the libiberty build, we fail while trying to build clock.c
    because of the same definition conflict.

With an older version of autoconf (2.13), the little test application
used to check for each function was slightly different (#included
assert.h instead of now limits.h), and that caused the check for "clock"
to be succesful. This configured libiberty to be built without clock.c.

I'm not really sure how this should be fixed. Should it be fixed in
autoconf for instance? Or should we use a custom test for "clock"
in libiberty/configure.in? Or should we simply use the standard
function check except on HP/UX were we know that "clock" is provided.

I don't know autoconf that much, but it seems that trying to fix this
problem may be a bit hard. So I took the simplest route, which was to
skip the test for "clock" on HP/UX knowing that it's not necessary
there. The downside of this approach is that it slightly increases
the maintenance burden, but I think the increase should remain minimal.
And it doesn't seem that this is the first time we do this sort of
thing.

Does the following patch look correct? Or should the problem be solved
differently?

2003-09-03  J. Brobecker  <brobecker@gnat.com>

        * configure.in: Skip the test for "clock" on HP/UX hosts.
        * configure: Regenerate.

Thanks,
-- 
Joel

Attachment: libiberty.diff
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]