Re: Guile 1.8.2 Compile Error [GAH]

Re: Guile 1.8.2 Compile Error [GAH]

[Mike Gran]

> From: Neil Jerram <neil@ossau.uklinux.net>
> 
> "Kevin Brott"  writes:
> 
> > Still baffled - but haven't given up yet.
> 
> Going back to your original report... all of the compile errors were
> triggered on lines containing "func_data".  Is it possible that you're
> somehow pulling in a header which #defines func_data to be something
> else (including a .) ?  What happens if you change all occurrences of
> "func_data" to "xxx_func_data" and then build again?


This is probably it.  I did almost get Guile 1.6.x to compile on the ancient AIX 4.2.1.0 (using xlc) a couple of years back.  To make it build, I remember having to change "func_data" to "funk_data" in a few places to avoid some internal definition.

Sorry I didn't mention this before, but, I'd forgotten until Neil mentioned it.

--
Mike Gran



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.8.2 Compile Error [GAH]

[Mike Gran]

> From: Kevin Brott <kevin.brott@providence.org>

> I find that this line in numbers.c
> 
> 6081: return scm_from_complex_double (cexp (SCM_COMPLEX_VALUE (z)));
> 
> expands to this:
> 
>       return scm_from_complex_double (cexp (((((scm_t_complex *)
> ((((scm_t_bits) (0? (*(SCM*)0=((((SCM *)((scm_t_cell *) (((scm_t_bits)
> (0? (*(SCM*)0=((((z))))): (((z)))))))) [((1))]))):
> (((SCM
> 
 *)((scm_t_cell
> *) (((scm_t_bits) (0? (*(SCM*)0=((((z))))): (((z))))))))
> [((1))]))))))->real) + __I * (((scm_t_complex *) ((((scm_t_bits) (0?
> (*(SCM*)0=((((SCM *)((scm_t_cell *) (((scm_t_bits) (0?
> (*(SCM*)0=((((z))))): (((z)))))))) [((1))]))): (((SCM *)((scm_t_cell *)
> (((scm_t_bits) (0? (*(SCM*)0=((((z))))): (((z))))))))
> [((1))]))))))->imag))));
> 

You are correct. There is a value in that macro called "_Complex_I" that is, for some reason, being processed down to "__I", losing the word "Complex".

What if you replace "_Complex_I" with "(0.0 + 1.0i)" ?

Good Luck,

Mike Gran

----- Original Message ----
> From: Kevin Brott <kevin.brott@providence.org>
> To: Guile-User <guile-user@gnu.org>
> Sent: Wednesday, November 14, 2007 10:37:01 AM
> Subject: Re: Guile 1.8.2 Compile Error [GAH]
> 
> 
> On Wed, 2007-11-14 at 09:59 -0800, Kevin Brott wrote:
> 
> > No - it bombs out now, trying to compile numbers.c  with this error:
> > 
> > numbers.c: In function 'scm_exp':
> > numbers.c:6081: error: '__I' undeclared (first use in this function)
> > numbers.c:6081: error: (Each undeclared identifier is reported
> only
> 
 once
> > numbers.c:6081: error: for each function it appears in.)
> > 
> > And I'm trying to work out where that __I is hiding.
> > 
> 
> Found where it's manifesting, now to figure out why ... from the
> guile-1.8.3 directory, if I do:
> 
>   cpp -I. -DHAVE_CONFIG_H libguile/numbers.c -o foo.cpp
> 
> I find that this line in numbers.c
> 
> 6081: return scm_from_complex_double (cexp (SCM_COMPLEX_VALUE (z)));
> 
> expands to this:
> 
>       return scm_from_complex_double (cexp (((((scm_t_complex *)
> ((((scm_t_bits) (0? (*(SCM*)0=((((SCM *)((scm_t_cell *) (((scm_t_bits)
> (0? (*(SCM*)0=((((z))))): (((z)))))))) [((1))]))):
> (((SCM
> 
 *)((scm_t_cell
> *) (((scm_t_bits) (0? (*(SCM*)0=((((z))))): (((z))))))))
> [((1))]))))))->real) + __I * (((scm_t_complex *) ((((scm_t_bits) (0?
> (*(SCM*)0=((((SCM *)((scm_t_cell *) (((scm_t_bits) (0?
> (*(SCM*)0=((((z))))): (((z)))))))) [((1))]))): (((SCM *)((scm_t_cell *)
> (((scm_t_bits) (0? (*(SCM*)0=((((z))))): (((z))))))))
> [((1))]))))))->imag))));
> 
> So hunting back to where SCM_COMPLEX_VALUE is defined in numbers.c, we
> get
>     168 #define SCM_COMPLEX_VALUE(z) \
>     169   (SCM_COMPLEX_REAL (z) + _Complex_I * SCM_COMPLEX_IMAG (z))
> 
> So it looks like _Complex_I is rendering as __I - and that prpbably
> isn't correct.
> 
> -- 
> #include 
> /* Kevin Brott  
>  * Unix Systems Engineer - SA Group - Provtech
>  * Providence Health Systems, Tigard, OR
>  */
> 
> 
> DISCLAIMER:
> This message is intended for the sole use of the addressee, and
> may
> 
 contain information that is privileged, confidential and exempt
> from
> 
 disclosure under applicable law. If you are not the addressee you are
> hereby
> 
 notified that you may not use, copy, disclose, or distribute to
> anyone
> 
 the message or any information contained in the message. If you
> have
> 
 received this message in error, please immediately advise the sender
> by
> 
 reply email and delete this message.
> 
> 
> _______________________________________________
> Guile-user mailing list
> Guile-user@gnu.org
> http://lists.gnu.org/mailman/listinfo/guile-user
> 




_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.8.2 Compile Error [GAH]

[Kevin Brott]

On Wed, 2007-11-14 at 11:17 -0800, Mike Gran wrote:

> You are correct. There is a value in that macro called "_Complex_I" that is, for some reason, being processed down to "__I", losing the word "Complex".
> 
> What if you replace "_Complex_I" with "(0.0 + 1.0i)" ?
> 
> Good Luck,
> 
> Mike Gran

Replacing "_Complex_I" with "(0.0 + 1.0i)"  and doing a fresh compile
works - with the caveat that I had to remove -Werror from
configure-generated CFLAGS to get past the type-punned warning.

Now I need to figure out WTH is wrong with the AIX <complex.h> that
_Complex_I is dereferencing as __I when the notes in that file clearly
state that __I shouldn't ever be called directly.

-- 
#include <stddisclaimer.h>
/* Kevin Brott <Kevin.Brott@Providence.org> 
 * Unix Systems Engineer - SA Group - Provtech
 * Providence Health Systems, Tigard, OR
 */


DISCLAIMER:
This message is intended for the sole use of the addressee, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.8.2 Compile Error [GAH]

[Ludovic Courtès]

Hi,

Mike Gran <spk121@yahoo.com> writes:

> You are correct. There is a value in that macro called "_Complex_I" that is, for some reason, being processed down to "__I", losing the word "Complex".

`Complex' in `_Complex_I' can't possibly be macro-expanded.  There must
be something else.

Thanks for your help!

Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.8.2 Compile Error [GAH]

[Kevin Brott]

On Thu, 2007-11-15 at 13:59 +0100, Ludovic Courtès wrote:
> Hi,
> 
> Mike Gran <spk121@yahoo.com> writes:
> 
> > You are correct. There is a value in that macro called "_Complex_I" that is, for some reason, being processed down to "__I", losing the word "Complex".
> 
> `Complex' in `_Complex_I' can't possibly be macro-expanded.  There must
> be something else.
> 
> Thanks for your help!
> 
> Ludovic.

For what it's worth:

/usr/include/complex.h:
     45 /* 
     46  * a constant expression of type const float _Complex with the
     47  * value of the imaginary unit. (a number i such that i**2 =-1).
     48  * __I is provided by the AIX xlc C99 compiler.
     49  * WARNING: DO NOT USE __I DIRECTLY in an application. Always
     50  * use _Complex_I .
     51  */
     52 #define _Complex_I      __I
     53 
     54 /*
     55  * _Imaginary_I should be a constant expression of type
     56  * const float _Imaginary with the value of the imaginary unit.
     57  * This is optional in C99.
     58  * This is not supported in the AIX xlc C99 compiler.
     59  */
     60 
     61 /* 
     62  * C99 requires this definition of the
     63  * very common variable "I", to use as a simpler way
     64  * to say _Complex_I. Mathematicians who would say
     65  * "3i" will now say in C "3 * I".
     66  */
     67 #undef I
     68 #define I _Complex_I
     69 

Could line 52 be expanded/dereferenced by cpp to make _Complex_I resolve
as __I?

-- 
#include <stddisclaimer.h>
/* Kevin Brott <Kevin.Brott@Providence.org> 
 * Unix Systems Engineer - SA Group - Provtech
 * Providence Health Systems, Tigard, OR
 */


DISCLAIMER:
This message is intended for the sole use of the addressee, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.8.2 Compile Error [GAH]

[Kevin Brott]

On Thu, 2007-11-15 at 10:10 -0800, Kevin Brott wrote:
> On Thu, 2007-11-15 at 13:59 +0100, Ludovic Courtès wrote:
> > 
> > `Complex' in `_Complex_I' can't possibly be macro-expanded.  There must
> > be something else.
> 
> Could line 52 be expanded/dereferenced by cpp to make _Complex_I resolve
> as __I?
> 

As it turns out - that's exactly what's happening - if I replace the
'_Complex_I' macro with the short-form 'I' macro in numbers.c - cpp
still renders it as __I, and gcc can't compile it because it's not
defined.

This leads me to believe it is a GCC issue with this code directive in
guile 1.8 (which isn't in the 1.4 or 1.6 guile source trees), in that
__I is not being defined by the gcc. AIX's complex.h says specifically
"__I is provided by the AIX xlc C99 compiler" - which argues that gcc on
AIX is not providing it, hence the failure.

My best guess is a fixincludes issue, or possibly not offered on systems
not using GNU libc.

I'm still looking into a fix - as the manual substitution of _Complex_I
in numbers.c isn't workable.  Looks like it might be time for me to
start bugging gcc devs about what could be causing this.

>From the guile end - perhaps using a detect that uses whatever the old
routine was for this function - when compiler = gcc and OS = AIX ?

-- 
#include <stddisclaimer.h>
/* Kevin Brott <Kevin.Brott@Providence.org> 
 * Unix Systems Engineer - SA Group - Provtech
 * Providence Health Systems, Tigard, OR
 */


DISCLAIMER:
This message is intended for the sole use of the addressee, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.8.2 Compile Error

[Kevin Brott]

Ludovic, et al;

On Mon, 2007-11-12 at 21:13 +0100, Ludovic Courtès wrote: 
> Hi,
> 
> "Kevin Brott" <kevin.brott@providence.org> writes:
> 
> > Hopefully I'm not out-of-line or violating protocol in some brutish
> > fashion, but regarding this query/response on the guile-user mailing
> > list archive ...
> 
> Actually nobody replied to my query so I'll ask you the same so that we
> can find out what's going on.  :-)
> 
> (Please make sure to answer on-list so that we don't lose track of
> this.)

Caveat Emptor: While I've had quite a bit of experience compiling code
and debugging basic syntax errors and os-specific mis-assumptions, I've
not had the need to be a C/C++ code-jockey of any more skill (yet) than
to write anything more complex than output hacks for something as simple
as hello.c (*toe*). :q

Recap:
I'm having a problem compiling guile 1.8.3 on AIX 5.2 using gcc
4.2.2, that's pretty much identical to the problem reported on guile
1.8.2 (and using the same gcc as previously reported on 1.8.2 I get the
same error as previously reported). The error for 1.8.3 looks like this:

In file included from ../libguile/gc.h:27,
                 from ../libguile.h:73,
                 from discouraged.c:22:
./libguile/hooks.h:43: error: expected ';', ',' or ')' before '.' token
./libguile/hooks.h:48: error: expected specifier-qualifier-list before 'scm_t_c_hook_function'
./libguile/hooks.h:62: error: expected declaration specifiers or '...' before 'scm_t_c_hook_function'
./libguile/hooks.h:63: error: expected ';', ',' or ')' before '.' token
./libguile/hooks.h:66: error: expected declaration specifiers or '...' before 'scm_t_c_hook_function'
./libguile/hooks.h:67: error: expected ';', ',' or ')' before '.' token
gmake[3]: *** [libguile_la-discouraged.lo] Error 1

Were you asking to just put the quoted code lines in a .c file and see
what happens when I apply gcc to it, or were you looking for something
more specific?  I'm willing to do whatever you like, but I might need a
more specific set of directions (possibly an example of the code you
want me to test)?

In the hopes it's something simple -- if test.c is:
---cut---

  typedef void  *(*scm_t_c_hook_function) (void *hook_data,
                                           void *func_data,
                                           void *data);

  SCM_API void scm_c_hook_add (scm_t_c_hook *hook,
                               scm_t_c_hook_function func,
                               void *func_data,
                               int appendp);

  SCM_API void scm_c_hook_remove (scm_t_c_hook *hook,
                                  scm_t_c_hook_function func,
                                  void *func_data);

---cut---

and I do gcc -o test test.c ... I get ...

test.c:6: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'
test.c:11: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'

Which are the SCM_API declarations.

Now if I include all of the subsections that report error lines from the
libguile compile, test2.c looks like (line numbers from original code -
not in .c):

---cut---
41:
42: typedef void *(*scm_t_c_hook_function) (void *hook_data,
43*                                         void *func_data,
44:                                         void *data);
45:
46: typedef struct scm_t_c_hook_entry {
47:   struct scm_t_c_hook_entry *next;
48*   scm_t_c_hook_function func;
49:   void *data;
50: } scm_t_c_hook_entry;
51...60
61: SCM_API void scm_c_hook_add (scm_t_c_hook *hook,
62*                              scm_t_c_hook_function func,
63*                              void *func_data,
64:                              int appendp);
65: SCM_API void scm_c_hook_remove (scm_t_c_hook *hook,
66*                                 scm_t_c_hook_function func,
67*                                 void *func_data);
68:
---cut---

I get ...
test2.c:12: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'
test2.c:16: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'

Which are the SCM_API declarations again.

Suggestions, correction for a more valid / informative test?

Just to head off the inevitable, Yes, the gcc build I have does build
working binaries/libs. I can build (for example) something as intensive
and make-check breakable as gmp 4.2.2 with no problems.  

Guile 1.4.1 builds cleanly and passes all of 'make check' on this
platform. Guile 1.6.8 builds a (seemingly) working copy (but 'make
check' gives about 20 errors on srfi-4.test - everything else passes
fine).

-- 
#include <stddisclaimer.h>
/* Kevin Brott <Kevin.Brott@Providence.org> 
 * Unix Systems Engineer - SA Group - Provtech
 * Providence Health Systems, Tigard, OR
 */


DISCLAIMER:
This message is intended for the sole use of the addressee, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.8.2 Compile Error

[Ludovic Courtès]

Hi,

"Kevin Brott" <kevin.brott@providence.org> writes:

> In file included from ../libguile/gc.h:27,
>                  from ../libguile.h:73,
>                  from discouraged.c:22:
> ./libguile/hooks.h:43: error: expected ';', ',' or ')' before '.' token

This is the second line of the typedef for `scm_t_c_hook_function'.  Can
you try compiling *only* that typedef?  And then this:

  typedef void * (* foo_t) (void *, void *);

Then:

  typedef void (* foo_t) (void *, void *);

The `scm_t_c_hook_function' seems perfectly valid to me so if the
compiler chokes, then I'm afraid it's a broken compiler.

> Were you asking to just put the quoted code lines in a .c file and see
> what happens when I apply gcc to it, or were you looking for something
> more specific?

The former.

> In the hopes it's something simple -- if test.c is:
> ---cut---
>
>   typedef void  *(*scm_t_c_hook_function) (void *hook_data,
>                                            void *func_data,
>                                            void *data);
>
>   SCM_API void scm_c_hook_add (scm_t_c_hook *hook,
>                                scm_t_c_hook_function func,
>                                void *func_data,
>                                int appendp);
>
>   SCM_API void scm_c_hook_remove (scm_t_c_hook *hook,
>                                   scm_t_c_hook_function func,
>                                   void *func_data);
>
> ---cut---
>
> and I do gcc -o test test.c ... I get ...
>
> test.c:6: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'
> test.c:11: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'
>
> Which are the SCM_API declarations.

So now the typedef itself doesn't yield any error?

Did you prepend "#define SCM_API extern"?  It will fail without this.

> ---cut---
> 41:
> 42: typedef void *(*scm_t_c_hook_function) (void *hook_data,
> 43*                                         void *func_data,
> 44:                                         void *data);
> 45:
> 46: typedef struct scm_t_c_hook_entry {
> 47:   struct scm_t_c_hook_entry *next;
> 48*   scm_t_c_hook_function func;
> 49:   void *data;
> 50: } scm_t_c_hook_entry;
> 51...60
> 61: SCM_API void scm_c_hook_add (scm_t_c_hook *hook,
> 62*                              scm_t_c_hook_function func,
> 63*                              void *func_data,
> 64:                              int appendp);
> 65: SCM_API void scm_c_hook_remove (scm_t_c_hook *hook,
> 66*                                 scm_t_c_hook_function func,
> 67*                                 void *func_data);
> 68:
> ---cut---
>
> I get ...
> test2.c:12: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'
> test2.c:16: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'
>
> Which are the SCM_API declarations again.

Again, no error with the typedef?

> Suggestions, correction for a more valid / informative test?

If one of the above `foo_t' typedefs works, then you can try compiling
this:

  extern void make_foo (void *x, foo_t function);

Then maybe this:

  extern void make_foo (void *x, foo_t *function);

This is all trial-and-error since I have no idea of what's wrong with
this compiler.

I quickly browsed the bug database at gcc.gnu.org and failed to find
anything related.  You might want to try that too...

Thanks,
Ludovic.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.8.2 Compile Error [GAH]

[Kevin Brott]

Bollux, let's try that again...

On Tue, 2007-11-13 at 00:14 +0100, Ludovic Courtès wrote:
..
> This is the second line of the typedef for `scm_t_c_hook_function'.  Can
> you try compiling *only* that typedef?  And then this:
> 
>   typedef void * (* foo_t) (void *, void *);
> 
> Then:
> 
>   typedef void (* foo_t) (void *, void *);
> 

All three compile without error if I wrap them in the usual main() {...}

> The `scm_t_c_hook_function' seems perfectly valid to me so if the
> compiler chokes, then I'm afraid it's a broken compiler.

I'd agree - except this is the only code it's broken on, and I went
through freshly compiled versions of gcc 3.3.6, 3.4.6, 4.0.4, 4.1.2, and
4.2.2 - and all of them have the same basic problem. FWIW - I couldn't
get 1.6.8 to compile until I had a working gcc 4.0.4, and was using
1.4.1 - which has always compiled/worked fine.

> So now the typedef itself doesn't yield any error?

not on it's own, no.

> 
> Did you prepend "#define SCM_API extern"?  It will fail without this.
> 

Nope - you got the code snippets I used.

> > ---cut---
> > 41:
> > 42: typedef void *(*scm_t_c_hook_function) (void *hook_data,
> > 43*                                         void *func_data,
> > 44:                                         void *data);
> > 45:
> > 46: typedef struct scm_t_c_hook_entry {
> > 47:   struct scm_t_c_hook_entry *next;
> > 48*   scm_t_c_hook_function func;
> > 49:   void *data;
> > 50: } scm_t_c_hook_entry;
> > 51...60
> > 61: SCM_API void scm_c_hook_add (scm_t_c_hook *hook,
> > 62*                              scm_t_c_hook_function func,
> > 63*                              void *func_data,
> > 64:                              int appendp);
> > 65: SCM_API void scm_c_hook_remove (scm_t_c_hook *hook,
> > 66*                                 scm_t_c_hook_function func,
> > 67*                                 void *func_data);
> > 68:
> > ---cut---
> >
> > I get ...
> > test2.c:12: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'
> > test2.c:16: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'
> >
> > Which are the SCM_API declarations again.
> 
> Again, no error with the typedef?

nope.

> 
> > Suggestions, correction for a more valid / informative test?
> 
> If one of the above `foo_t' typedefs works, then you can try compiling
> this:
> 
>   extern void make_foo (void *x, foo_t function);
> 
---cut---
main()
{
extern void make_foo (void *x, foo_t function);
}
---cut---

# gcc -o evt evt.c 
evt.c: In function 'main':
evt.c:3: error: expected declaration specifiers or '...' before 'foo_t'

> Then maybe this:
> 
>   extern void make_foo (void *x, foo_t *function);
> 

Same error.

> This is all trial-and-error since I have no idea of what's wrong with
> this compiler.
> 
> I quickly browsed the bug database at gcc.gnu.org and failed to find
> anything related.  You might want to try that too...

Doing that - not having a lot of luck so far ...

Was wondering if it's a bad/missing fixincludes action in gcc ... but if
that were the case then I'd think a lot more stuff wouldn't compile
besides just guile 1.8.

-- 
#include <stddisclaimer.h>
/* Kevin Brott <Kevin.Brott@Providence.org> 
 * Unix Systems Engineer - SA Group - Provtech
 * Providence Health Systems, Tigard, OR
 */


DISCLAIMER:
This message is intended for the sole use of the addressee, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.8.2 Compile Error [GAH]

[Kevin Brott]

Ludovic Courtès wrote:
> > 
> > Did you prepend "#define SCM_API extern"?  It will fail without this.
> > 

When I do that ... and this is the code:

---cut---
main ()
{
#define SCM_API extern

  typedef void  *(*scm_t_c_hook_function) (void *hook_data,
                                           void *func_data,
                                           void *data);

  SCM_API void scm_c_hook_add (scm_t_c_hook *hook,
                               scm_t_c_hook_function func,
                               void *func_data,
                               int appendp);

  SCM_API void scm_c_hook_remove (scm_t_c_hook *hook,
                                  scm_t_c_hook_function func,
                                  void *func_data);
}
---cut---

I get ...

# gcc -o test test.c
test.c: In function 'main':
test.c:9: error: expected ')' before '*' token
test.c:14: error: expected ')' before '*' token

-- 
#include <stddisclaimer.h>
/* Kevin Brott <Kevin.Brott@Providence.org> 
 * Unix Systems Engineer - SA Group - Provtech
 * Providence Health Systems, Tigard, OR
 */


DISCLAIMER:
This message is intended for the sole use of the addressee, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.8.2 Compile Error [GAH]

[Ludovic Courtès]

Hi,

"Kevin Brott" <kevin.brott@providence.org> writes:

> I'd agree - except this is the only code it's broken on, and I went
> through freshly compiled versions of gcc 3.3.6, 3.4.6, 4.0.4, 4.1.2, and
> 4.2.2 - and all of them have the same basic problem. FWIW - I couldn't
> get 1.6.8 to compile until I had a working gcc 4.0.4, and was using
> 1.4.1 - which has always compiled/worked fine.

OK.

> ---cut---
> main()
> {
> extern void make_foo (void *x, foo_t function);
> }
> ---cut---
>
> # gcc -o evt evt.c 
> evt.c: In function 'main':
> evt.c:3: error: expected declaration specifiers or '...' before 'foo_t'

It's better to put the declaration outside (to avoid cumulating
potential problems).  You could try this:

  typedef void * (* foo_t) (void *, void *);

  foo_t
  doit (foo_t x)
  {
    return x;
  }

Or this:

  typedef void * (* foo_t) (void *, void *);
  extern void make_foo (void *x, foo_t function);

  int
  stuff (int x)
  {
    return x;
  }

Then just "gcc -c the-file.c".

> Was wondering if it's a bad/missing fixincludes action in gcc ... but if
> that were the case then I'd think a lot more stuff wouldn't compile
> besides just guile 1.8.

Right.

Thanks,
Ludovic.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.8.2 Compile Error [GAH]

[Kevin Brott]

On Tue, 2007-11-13 at 00:51 +0100, Ludovic Courtès wrote:
> It's better to put the declaration outside (to avoid cumulating
> potential problems).  You could try this:
> 
>   typedef void * (* foo_t) (void *, void *);
> 
>   foo_t
>   doit (foo_t x)
>   {
>     return x;
>   }
> 
> Or this:
> 
>   typedef void * (* foo_t) (void *, void *);
>   extern void make_foo (void *x, foo_t function);
> 
>   int
>   stuff (int x)
>   {
>     return x;
>   }
> 
> Then just "gcc -c the-file.c".
> 

Those two examples compile fine.  I'll retest the original test files
the same way, and report back tomorrow, as I'm sodding off work for the
day. :)

Interesting to note that when I ported my test directory to an Ubuntu
7.10 desktop system - I got exactly the same compile errors as the AIX
box (unsurprising perhaps as it's running gcc 4.1.x).  I'll have to try
the full guile 1.8.3 code there too, and see if I can spot the config
differences (assuming it builds there).

-- 
#include <stddisclaimer.h>
/* Kevin Brott <Kevin.Brott@Providence.org> 
 * Unix Systems Engineer - SA Group - Provtech
 * Providence Health Systems, Tigard, OR
 */


DISCLAIMER:
This message is intended for the sole use of the addressee, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.8.2 Compile Error [GAH]

[Kevin Brott]

On Mon, 2007-11-12 at 16:08 -0800, Kevin Brott wrote:
> > 
> > Then just "gcc -c the-file.c".
> > 
> 
> Those two examples compile fine.  I'll retest the original test files
> the same way, and report back tomorrow, as I'm sodding off work for the
> day. :)
> 

Okay - so re-running everything via gcc -c file.c - here are the file
contents and the error output (scripted the run for uniformity):

===BEGIN: evt.c===
extern void make_foo (void *x, foo_t function);
===END: evt.c===
# gcc -c evt.c && echo OK || echo NOT OK 
evt.c:1: error: expected declaration specifiers or '...' before 'foo_t'
NOT OK


===BEGIN: evt2.c===
extern void make_foo (void *x, foo_t *function);
===END: evt2.c===
# gcc -c evt2.c && echo OK || echo NOT OK 
evt2.c:1: error: expected declaration specifiers or '...' before 'foo_t'
NOT OK


===BEGIN: test.c===
#define SCM_API extern
  typedef void  *(*scm_t_c_hook_function) (void *hook_data,
                                           void *func_data,
                                           void *data);
  SCM_API void scm_c_hook_add (scm_t_c_hook *hook,
                               scm_t_c_hook_function func,
                               void *func_data, 
                               int appendp);
  SCM_API void scm_c_hook_remove (scm_t_c_hook *hook,
                                  scm_t_c_hook_function func,
                                  void *func_data);
===END: test.c===
# gcc -c test.c && echo OK || echo NOT OK 
test.c:5: error: expected ')' before '*' token
test.c:9: error: expected ')' before '*' token
NOT OK


===BEGIN: test2.c===
#define SCM_API extern
typedef void *(*scm_t_c_hook_function) (void *hook_data,
                                         void *func_data,
                                        void *data);
typedef struct scm_t_c_hook_entry {
  struct scm_t_c_hook_entry *next;
  scm_t_c_hook_function func;
  void *data;
} scm_t_c_hook_entry;
SCM_API void scm_c_hook_add (scm_t_c_hook *hook,
                            scm_t_c_hook_function func,
                            void *func_data,
                            int appendp);
SCM_API void scm_c_hook_remove (scm_t_c_hook *hook,
                                scm_t_c_hook_function func,
                                void *func_data);
===END: test2.c===
# gcc -c test2.c && echo OK || echo NOT OK 
test2.c:10: error: expected ')' before '*' token
test2.c:14: error: expected ')' before '*' token
NOT OK


===BEGIN: test3.c===
  typedef void * (* foo_t) (void *, void *);
  foo_t
  doit (foo_t x)
  {
    return x;
  }
===END: test3.c===
# gcc -c test3.c && echo OK || echo NOT OK 
OK


===BEGIN: test4.c===
  typedef void * (* foo_t) (void *, void *);
  extern void make_foo (void *x, foo_t function);
  int
  stuff (int x)
  {
    return x;
  }
===END: test4.c===
# gcc -c test4.c && echo OK || echo NOT OK 
OK


===BEGIN: typedef1.c===
typedef void *(*scm_t_c_hook_function) (void *hook_data,
                                         void *func_data,
                                        void *data);
===END: typedef1.c===
# gcc -c typedef1.c && echo OK || echo NOT OK 
OK


===BEGIN: typedef2.c===
typedef void * (* foo_t) (void *, void *);
===END: typedef2.c===
# gcc -c typedef2.c && echo OK || echo NOT OK 
OK


===BEGIN: typedef3.c===
typedef void (* foo_t) (void *, void *);
===END: typedef3.c===
# gcc -c typedef3.c && echo OK || echo NOT OK 
OK


FWIW - guile 1.8.3 does compile, and passes all of 'make check' on
Ubuntu 7.10 (gutsy) using gcc version 4.1.3 20070929 (prerelease)
(Ubuntu 4.1.2-16ubuntu2).  

However, all of the code snippets listed above fail in exactly the same
way on Ubuntu as they did on AIX.  So I'm guessing that some config
guessing is wrong on AIX, and either it's trying to compile code
segments that isn't being compiled on Linux, or it's not including
something that is being included on Linux to stop the errors.

I'm diffing the config.h's now and will experiment a bit with changes to
see if I can find the magic "wtf" particle.

-- 
#include <stddisclaimer.h>
/* Kevin Brott <Kevin.Brott@Providence.org> 
 * Unix Systems Engineer - SA Group - Provtech
 * Providence Health Systems - 503-216-4703
 */


DISCLAIMER:
This message is intended for the sole use of the addressee, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.8.2 Compile Error [GAH]

[Ludovic Courtès]

Hi,

"Kevin Brott" <kevin.brott@providence.org> writes:

> However, all of the code snippets listed above fail in exactly the same
> way on Ubuntu as they did on AIX.  So I'm guessing that some config
> guessing is wrong on AIX, and either it's trying to compile code
> segments that isn't being compiled on Linux, or it's not including
> something that is being included on Linux to stop the errors.

Indeed, we must be on the wrong track.

Can you try adding the following line in `libguile/discouraged.c':

  #include "libguile/_scm.h"

Put it right before `#include "libguile.h"'.

I'm pretty much clueless, and I don't have access to AIX.  Maybe you
could ask a colleague familiar with C to look into it, if possible.  :-)

Thanks for your patience!

Ludovic.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.8.2 Compile Error [GAH]

[Kevin Brott]

On Tue, 2007-11-13 at 23:20 +0100, Ludovic Courtès wrote:
> "Kevin Brott" <kevin.brott@providence.org> writes:
> 
> > However, all of the code snippets listed above fail in exactly the same
> > way on Ubuntu as they did on AIX.  So I'm guessing that some config
> > guessing is wrong on AIX, and either it's trying to compile code
> > segments that isn't being compiled on Linux, or it's not including
> > something that is being included on Linux to stop the errors.
> 
> Indeed, we must be on the wrong track.
> 
> Can you try adding the following line in `libguile/discouraged.c':
> 
>   #include "libguile/_scm.h"
> 
> Put it right before `#include "libguile.h"'.
> 
> I'm pretty much clueless, and I don't have access to AIX.  Maybe you
> could ask a colleague familiar with C to look into it, if possible.  :-)
> 

I thought at first - based on the error message that it might be the
SCM_I_GSC_NEED_BRACES_ON_PTHREAD_ONCE_INIT directive - since that
defines as "1" on AIX and "0" on Linux - but changing that in
config.status and running it, and then trying a make  made no
difference. Likewise changing the define for AIX 3 of _ALL_SOURCE to
'undef' gave no joy.

Since the error was in discouraged.c - I tried configuring and compiling
--disable-discouraged and got:

deprecated.c: In function 'scm_i_object_chars':
deprecated.c:663: warning: implicit declaration of function 'SCM_SYMBOLP'
deprecated.c: In function 'scm_i_keywordsym':
deprecated.c:1239: warning: implicit declaration of function 'scm_keyword_dash_symbol'
deprecated.c:1239: warning: return makes pointer from integer without a cast
gmake[3]: *** [libguile_la-deprecated.lo] Error 1

Trying with --disable-discouraged and --disable-deprecated brought me
back to the original error in the same place - which baffles me since I
wasn't expecting a --disable to still reference discouraged.c

Trying your suggestion of just adding the "libguile/_scm.h" include gave
this error on compile:

gc.c:974: error: expected ';', ',' or ')' before '.' token
gc.c: In function 'scm_init_gc':
gc.c:1023: error: 'mark_gc_async' undeclared (first use in this function)
gc.c:1023: error: (Each undeclared identifier is reported only once
gc.c:1023: error: for each function it appears in.)

Still baffled - but haven't given up yet.  Still walking through the
diffs in config.h

-- 
#include <stddisclaimer.h>
/* Kevin Brott <Kevin.Brott@Providence.org> 
 * Unix Systems Engineer - SA Group - Provtech
 * Providence Health Systems, Tigard, OR
 */


DISCLAIMER:
This message is intended for the sole use of the addressee, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.8.2 Compile Error [GAH]

[Neil Jerram]

"Kevin Brott" <kevin.brott@providence.org> writes:

> Still baffled - but haven't given up yet.

Going back to your original report... all of the compile errors were
triggered on lines containing "func_data".  Is it possible that you're
somehow pulling in a header which #defines func_data to be something
else (including a .) ?  What happens if you change all occurrences of
"func_data" to "xxx_func_data" and then build again?

Also, looking through the thread, I became confused about which gcc
version / OS combinations exhibit this problem, and which don't.
Could you give a summary all in one place?

Regards,
        Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.8.2 Compile Error [GAH]

[Kevin Brott]

On Wed, 2007-11-14 at 00:39 +0000, Neil Jerram wrote:
> "Kevin Brott" <kevin.brott@providence.org> writes:
> 
> > Still baffled - but haven't given up yet.
> 
> Going back to your original report... all of the compile errors were
> triggered on lines containing "func_data".  Is it possible that you're
> somehow pulling in a header which #defines func_data to be something
> else (including a .) ?  What happens if you change all occurrences of
> "func_data" to "xxx_func_data" and then build again?
> 
> Also, looking through the thread, I became confused about which gcc
> version / OS combinations exhibit this problem, and which don't.
> Could you give a summary all in one place?
> 
> Regards,
>         Neil
> 

okay - fairly simple (I hope):

AIX 5.2 + gcc 4.2.2 = guile 1.8.3 w/not compile
Ubuntu 7.10 + gcc 4.1.2 = guile 1.8.3 compiles

BUT - when you try to compile the code snips out of hooks.h that the
error refers to - both the Linux and AIX gcc's spew identical errors.

I'm working through the gcc compile line that explodes - and I've found
one thing rather interesting --- the last compile line in
guile-1.8.3/libguile  that explodes is:

gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -I/opt/phs/include -D_THREAD_SAFE 
  -O2 -mcpu=power2 -pthread -Wall -Wmissing-prototypes -Werror 
  -MT libguile_la-discouraged.lo -MD -MP -MF deps/libguile_la-discouraged.Tpo 
  -c discouraged.c  -DPIC -o .libs/libguile_la-discouraged.o

Which gives this:
In file included from ../libguile/gc.h:27,
                 from ../libguile.h:73,
                 from discouraged.c:22:
./libguile/hooks.h:43: error: expected ';', ',' or ')' before '.' token
./libguile/hooks.h:48: error: expected specifier-qualifier-list before 'scm_t_c_hook_function'
./libguile/hooks.h:62: error: expected declaration specifiers or '...' before 'scm_t_c_hook_function'
./libguile/hooks.h:63: error: expected ';', ',' or ')' before '.' token
./libguile/hooks.h:66: error: expected declaration specifiers or '...' before 'scm_t_c_hook_function'
./libguile/hooks.h:67: error: expected ';', ',' or ')' before '.' token
gmake[3]: *** [libguile_la-discouraged.lo] Error 1

Now if I cd into libguile and hand-execute that line - without the -I..
elements it compiles without errors.  Which argues that something else
I'm not seeing is being included that is causing the problem.

Code-monkey friend of mine suggested that the problem is with the cpp
output, but when I do this:

  cpp discouraged.c -o foo.c && gcc -c foo.c

I get foo.o and no errors.  Now bear in mind that I'm a C/C++ newb and
that last bit probably means nada.

You sir have hit a nail on the head - at least the compile got past
discouraged.c anyway ...

perl -pi -e 's/func_data/xxx_func_data/g' libguile/hooks.h

gmake clean && gmake ... gets down to:

gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -I/opt/phs/include -I/opt/freeware/include 
  -D_THREAD_SAFE -g -O2 -Wall -Wmissing-prototypes -Werror -MT libguile_la-gc.lo 
  -MD -MP -MF .deps/libguile_la-gc.Tpo -c gc.c  -DPIC -o libs/libguile_la-gc.o

gc.c:974: error: expected ';', ',' or ')' before '.' token
gc.c: In function 'scm_init_gc':
gc.c:1023: error: 'mark_gc_async' undeclared (first use in this function)
gc.c:1023: error: (Each undeclared identifier is reported only once
gc.c:1023: error: for each function it appears in.)
gmake[3]: *** [libguile_la-gc.lo] Error 1

Oh look ! 
gc.c:974:               void *func_data SCM_UNUSED,

more perlfoo on gc.c

gmake clean && gmake ... gets down to:

gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -I/opt/phs/include -I/opt/freeware/include 
  -D_THREAD_SAFE -g -O2 -Wall -Wmissing-prototypes -Werror -MT libguile_la-hooks.lo 
  -MD -MP -MF .deps/libguile_la-hooks.Tpo -c hooks.c  -DPIC -o libs/libguile_la-hooks.o
hooks.c:53: error: expected ';', ',' or ')' before '.' token
hooks.c:70: error: expected ';', ',' or ')' before '.' token
gmake[3]: *** [libguile_la-hooks.lo] Error 1

more perlfoo on hooks.c

gmake clean && gmake ... gets down to:

gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -I/opt/phs/include -I/opt/freeware/include 
  -D_THREAD_SAFE -g -O2 -Wall -Wmissing-prototypes -Werror -MT libguile_la-numbers.lo 
  -MD -MP -MF .deps/libguile_la-numbers.Tpo -c numbers.c  -DPIC -o libs/libguile_la-numbers.o

cc1: warnings being treated as errors
numbers.c: In function 'guile_ieee_init':
numbers.c:617: warning: dereferencing type-punned pointer will break strict-aliasing rules
numbers.c:640: warning: dereferencing type-punned pointer will break strict-aliasing rules
numbers.c: In function 'scm_exp':
numbers.c:6081: error: '__I' undeclared (first use in this function)
numbers.c:6081: error: (Each undeclared identifier is reported only once
numbers.c:6081: error: for each function it appears in.)
gmake[3]: *** [libguile_la-numbers.lo] Error 1

Which is :
   6078   if (SCM_COMPLEXP (z))
   6079     {
   6080 #if HAVE_COMPLEX_DOUBLE && HAVE_CEXP
   6081       return scm_from_complex_double (cexp (SCM_COMPLEX_VALUE (z)));
   6082 #else
   6083       return scm_c_make_polar (exp (SCM_COMPLEX_REAL (z)),
   6084                                SCM_COMPLEX_IMAG (z));
   6085 #endif
   6086     }

And I'm stuck again :p

running a 'find' now to see if func_data is showing up somewhere else being sneaky.

-- 
#include <stddisclaimer.h>
/* Kevin Brott <Kevin.Brott@Providence.org> 
 * Unix Systems Engineer - SA Group - Provtech
 * Providence Health Systems, Tigard, OR
 */


DISCLAIMER:
This message is intended for the sole use of the addressee, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.8.2 Compile Error [GAH]

[Kevin Brott]

On Tue, 2007-11-13 at 17:29 -0800, Kevin Brott wrote:
> running a 'find' now to see if func_data is showing up somewhere else
> being sneaky.

Didn't find anything more in the guile source code - I did replace all
instances of "func_data" with "xxx_func_data".  The make gets a lot
further now before exploding.

Info on AIX 5.2 (amazing what you find when you look for it):

/usr/include/sys/timer.h defines func_data if ...

    177 #ifndef  _LINUX_SOURCE_COMPAT
    178 #define func_data       t_union.data
    179 #endif
    180 #define t_func_data     t_union.data
    181 #define t_func_sdata    t_union.sdata
    182 #define t_func_addr     t_union.addr

Which is (lslpp -w /usr/include/sys/timer.h):
  File                                        Fileset               Type
  ----------------------------------------------------------------------------
  /usr/include/sys/timer.h                    bos.adt.include       File

  Fileset                      Level  State      Description         
  ----------------------------------------------------------------------------
  bos.adt.include          5.2.0.107  COMMITTED  Base Application Development
                                                 Include Files

These system files ...  all #include <sys/timer.h>
  /usr/include/sys/diagex.h
  /usr/include/sys/proc.h
  /usr/include/sys/user.h
  /usr/include/sys/uthread.h

Confirmed that this also exists in AIX 5.3 as well.

-- 
#include <stddisclaimer.h>
/* Kevin Brott <Kevin.Brott@Providence.org> 
 * Unix Systems Engineer - SA Group - Provtech
 * Providence Health Systems, Tigard, OR
 */


DISCLAIMER:
This message is intended for the sole use of the addressee, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.8.2 Compile Error [GAH]

[Ludovic Courtès]

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> Going back to your original report... all of the compile errors were
> triggered on lines containing "func_data".  Is it possible that you're
> somehow pulling in a header which #defines func_data to be something
> else (including a .) ?  What happens if you change all occurrences of
> "func_data" to "xxx_func_data" and then build again?

"Kevin Brott" <kevin.brott@providence.org> writes:

> Didn't find anything more in the guile source code - I did replace all
> instances of "func_data" with "xxx_func_data".  The make gets a lot
> further now before exploding.

Great, thank you Neil!  (It'd have taken time before I could think of
such a thing...)

So, does it basically compile now?  What's left?

Thanks,
Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.8.2 Compile Error [GAH]

[Kevin Brott]

On Wed, 2007-11-14 at 14:35 +0100, Ludovic Courtès wrote:
> Hi,
> 
> Neil Jerram <neil@ossau.uklinux.net> writes:
> 
> > Going back to your original report... all of the compile errors were
> > triggered on lines containing "func_data".  Is it possible that you're
> > somehow pulling in a header which #defines func_data to be something
> > else (including a .) ?  What happens if you change all occurrences of
> > "func_data" to "xxx_func_data" and then build again?
> 
> "Kevin Brott" <kevin.brott@providence.org> writes:
> 
> > Didn't find anything more in the guile source code - I did replace all
> > instances of "func_data" with "xxx_func_data".  The make gets a lot
> > further now before exploding.
> 
> Great, thank you Neil!  (It'd have taken time before I could think of
> such a thing...)
> 
> So, does it basically compile now?  What's left?
> 

No - it bombs out now, trying to compile numbers.c  with this error:

numbers.c: In function 'scm_exp':
numbers.c:6081: error: '__I' undeclared (first use in this function)
numbers.c:6081: error: (Each undeclared identifier is reported only once
numbers.c:6081: error: for each function it appears in.)

And I'm trying to work out where that __I is hiding.

See previous post for more detail, but it looks like on AIX - to avoid
the whole mess with the func_data conflict, either the source code needs
to be tweaked to use another label, or configure needs to define
-D_LINUX_SOURCE_COMPAT.

-- 
#include <stddisclaimer.h>
/* Kevin Brott <Kevin.Brott@Providence.org> 
 * Unix Systems Engineer - SA Group - Provtech
 * Providence Health Systems, Tigard, OR
 */


DISCLAIMER:
This message is intended for the sole use of the addressee, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.8.2 Compile Error [GAH]

[Kevin Brott]

On Wed, 2007-11-14 at 09:59 -0800, Kevin Brott wrote:

> No - it bombs out now, trying to compile numbers.c  with this error:
> 
> numbers.c: In function 'scm_exp':
> numbers.c:6081: error: '__I' undeclared (first use in this function)
> numbers.c:6081: error: (Each undeclared identifier is reported only once
> numbers.c:6081: error: for each function it appears in.)
> 
> And I'm trying to work out where that __I is hiding.
> 

Found where it's manifesting, now to figure out why ... from the
guile-1.8.3 directory, if I do:

  cpp -I. -DHAVE_CONFIG_H libguile/numbers.c -o foo.cpp

I find that this line in numbers.c

6081: return scm_from_complex_double (cexp (SCM_COMPLEX_VALUE (z)));

expands to this:

      return scm_from_complex_double (cexp (((((scm_t_complex *)
((((scm_t_bits) (0? (*(SCM*)0=((((SCM *)((scm_t_cell *) (((scm_t_bits)
(0? (*(SCM*)0=((((z))))): (((z)))))))) [((1))]))): (((SCM *)((scm_t_cell
*) (((scm_t_bits) (0? (*(SCM*)0=((((z))))): (((z))))))))
[((1))]))))))->real) + __I * (((scm_t_complex *) ((((scm_t_bits) (0?
(*(SCM*)0=((((SCM *)((scm_t_cell *) (((scm_t_bits) (0?
(*(SCM*)0=((((z))))): (((z)))))))) [((1))]))): (((SCM *)((scm_t_cell *)
(((scm_t_bits) (0? (*(SCM*)0=((((z))))): (((z))))))))
[((1))]))))))->imag))));

So hunting back to where SCM_COMPLEX_VALUE is defined in numbers.c, we
get
    168 #define SCM_COMPLEX_VALUE(z) \
    169   (SCM_COMPLEX_REAL (z) + _Complex_I * SCM_COMPLEX_IMAG (z))

So it looks like _Complex_I is rendering as __I - and that prpbably
isn't correct.

-- 
#include <stddisclaimer.h>
/* Kevin Brott <Kevin.Brott@Providence.org> 
 * Unix Systems Engineer - SA Group - Provtech
 * Providence Health Systems, Tigard, OR
 */


DISCLAIMER:
This message is intended for the sole use of the addressee, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.8.2 Compile Error [GAH]

[Neil Jerram]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> Great, thank you Neil!  (It'd have taken time before I could think of
> such a thing...)

Thanks, I was lucky there.  Do you think it's worth adding something
to CVS to try to make sure that we don't accidentally use func_data
again in future?

What I have in mind is a new test in test-suite/standalone, which
would grep all Guile's C code for func_data, and cause "make check" to
fail if it found any.

Regards,
        Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.8.2 Compile Error [GAH]

[Ludovic Courtès]

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> Thanks, I was lucky there.  Do you think it's worth adding something
> to CVS to try to make sure that we don't accidentally use func_data
> again in future?
>
> What I have in mind is a new test in test-suite/standalone, which
> would grep all Guile's C code for func_data, and cause "make check" to
> fail if it found any.

Yep, sounds nice and cheap enough.

Besides, we could choose to systematically omit parameter names in
function declarations, assuming headers aren't meant to serve as an API
documentation.

(Having little spare time these days, I'd appreciate if you could take
care of it.)

Thanks,
Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile 1.8.2 Compile Error [GAH]

[Neil Jerram]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> Hi,
>
> Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> Thanks, I was lucky there.  Do you think it's worth adding something
>> to CVS to try to make sure that we don't accidentally use func_data
>> again in future?
>>
>> What I have in mind is a new test in test-suite/standalone, which
>> would grep all Guile's C code for func_data, and cause "make check" to
>> fail if it found any.
>
> Yep, sounds nice and cheap enough.

OK.

> Besides, we could choose to systematically omit parameter names in
> function declarations, assuming headers aren't meant to serve as an API
> documentation.

Not API doc, no; but in practice I find that parameter names are
useful as coding doc.

> (Having little spare time these days, I'd appreciate if you could take
> care of it.)

Will do.

     Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user