Re: Guile 1.8.2 Compile Error [GAH]
Hi, Neil Jerram <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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]
On Wed, 2007-11-14 at 14:35 +0100, Ludovic Courtès wrote: > Hi, > > Neil Jerram <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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 /* Kevin Brott <[EMAIL PROTECTED]> * 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]
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 <[EMAIL PROTECTED]> * 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]
> From: Kevin Brott <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> > To: Guile-User > 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]
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 that _Complex_I is dereferencing as __I when the notes in that file clearly state that __I shouldn't ever be called directly. -- #include /* Kevin Brott <[EMAIL PROTECTED]> * 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
