bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bizarre error from CVS ltdl.c with HPUX 10.20 c89


From: Gary V. Vaughan
Subject: Re: bizarre error from CVS ltdl.c with HPUX 10.20 c89
Date: Wed, 5 Dec 2001 02:05:13 +0000
User-agent: Mutt/1.3.22.1i

On Tue, Nov 27, 2001 at 12:09:41PM -0600, Robert Boehne wrote:
> Hello,
> 
> I'm racking my brain to figure out why this platform won't compile
> CVS HEAD libtool any longer.  The errors from ltdl.c don't make any
> sense to me.
> For example, ENOMEM is defined by <errno.h> which is found during
> configure and gets included.  I can see no reason for these errors,
> do they look familiar to anyone out there?
> (am I missing somthing obvious?)

[[snip]]
> config.status: creating config.h
> config.status: config.h is unchanged

If config.h is broken, then configure is not fixing it... and inclusion
of errno.h relies on HAVE_ERRNO_H being defined by config.h.  My guess
is that config.h does not define it correctly on this platform for some
reason.

[[snip]]
> cc: "ltdl.c", line 451: error 1588: "ENOMEM" undefined.

If it ENOMEM were being substituted for its value by the preprocessor,
the compiler would never see the ENOMEM symbol to give this error.

Pasting the compile line with a judicious -E (or equivalent) to examine
what the preprocessor is doing and which files it is visiting should be
your next step.  Like this:

> In the preprocessed output I have this:
>  <SNIP>
> # 62 "/icarus/GNU/libtool/libltdl/ltdl.c"
>  
>  
>  
>  
> # 1 "/usr/include/errno.h"
> # 9
> extern int errno;
>  
> # 1 "/usr/include/sys/errno.h"
> # 13
>  
> # 1 "/usr/include/sys/stdsyms.h"
> # 254
>  
> # 14 "/usr/include/sys/errno.h"
> # 24
>          extern int errno;
> # 208
>  
> # 11 "/usr/include/errno.h"
> # 24
> <SNIP>

Does the following behave as expected when fed to `gcc -E -I. -I.. foo.h':

#if HAVE_CONFIG_H
#  include <config.h>
#endif

#if HAVE_ERRNO_H
#  include <errno.h>
#endif

x ENOMEM x

What about with the native compiler?

Other than that, you might try rolling back the CVS revisions a few
weeks at a time to try and isolate when the breakage started to occur,
and at least localise the responsible code.

HTH,
        Gary.
-- 
  ())_. Gary V. Vaughan     gary@(oranda.demon.co.uk|gnu.org)
  ( '/  Research Scientist  http://www.oranda.demon.co.uk       ,_())____
  / )=  GNU Hacker          http://www.gnu.org/software/libtool  \'      `&
`(_~)_  Tech' Author        http://sources.redhat.com/autobook   =`---d__/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]