Re: Guile 1.8.2 Compile Error [GAH]
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
/* Kevin Brott <[EMAIL PROTECTED]>
* 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
goops classes for smobs
Damn!
I discovered that if GOOPS is loaded first,
libguile/smob.c's 'scm_make_smob_type()' creates
an extended class for registered SMOB types, but
this is (AFAICT) undocumented!
Now, in extensions adding new number reps to
Guile I used everywhere:
(define-class ()
(n #:init-keyword #:smob))
I cannot replace this with the SMOB's class built
by Guile because there is no way to select a base
class. And I need it.
It is my understanding that libguile/goops.c's
'make_class_from_template()' accepts as third
argument a list of base classes; if this is the
case we can add:
SCM
scm_make_extended_class_with_supers (char const *type_name,
scm_t s_supers)
{
/* is there a class assertion to put here? */
return make_class_from_template ("<%s>", type_name,
s_supers, 0);
}
that can be called with:
scm_make_extended_class_with_supers("my",
scm_variable_ref(""));
A variant of 'scm_make_smob_type()' is needed to
use'scm_make_extended_class_with_supers()'.
Adding a 'scm_set_smob_supers()' function to
register the list of supers in the SMOB structure
breaks the protocol of SMOB type creation (create
the type, THEN call the 'scm_set_smob_*()'
functions).
But now the hardcoded limit to SMOB types slaps
me in the face. In the base library of GEE I use
a primitive SMOB [1] that implements dispatching
to sub-SMOB's driver functions, a sub-SMOB is
defined by a statically allocated custom driver
structure. It changes nothing in the interface:
the driver functions do the same thing.
A sub-SMOB is created with:
SCM_NEWSMOB2(smob, multi_smob_driver, client_data,
sub_smob_driver);
Including such a thing in the core would solve
the hardcoded SMOB limit problem and allow the
selection of base classes in the sub-SMOB driver
structure. A change in the 'scm_tcs_struct'
'switch' branch of libguile/goops.c's
'scm_class_of()' would be needed:
{
/* Goops object */
if (! scm_is_false (SCM_OBJ_CLASS_REDEF (x)))
scm_change_object_class (x, SCM_CLASS_OF (x),
SCM_OBJ_CLASS_REDEF (x));
if (SCM_SMOB_PREDICATE(multi_smob_driver, x))
{
SCM class =
((sub_smob_driver_t)SCM_SMOB_DATA_2(x))->class;
if (SCM_UNSPECIFIED != class)
return class;
}
else
return SCM_CLASS_OF (x);
}
Wadda ya think?
[1] http://download.gna.org/gee/tmp/multi-smob.tar.gz
--
Marco Maggi
"Now feel the funk blast!"
Rage Against the Machine - "Calm like a bomb"
___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
Re: Guile 1.8.2 Compile Error [GAH]
Hi, "Kevin Brott" <[EMAIL PROTECTED]> 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]
On Tue, 2007-11-13 at 23:20 +0100, Ludovic Courtès wrote: > "Kevin Brott" <[EMAIL PROTECTED]> 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 /* 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]
"Kevin Brott" <[EMAIL PROTECTED]> 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]
> From: Neil Jerram <[EMAIL PROTECTED]> > > "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]
On Wed, 2007-11-14 at 00:39 +, Neil Jerram wrote:
> "Kevin Brott" <[EMAIL PROTECTED]> 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
Re: Guile 1.8.2 Compile Error [GAH]
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_sdatat_union.sdata 182 #define t_func_addr t_union.addr Which is (lslpp -w /usr/include/sys/timer.h): FileFileset Type /usr/include/sys/timer.hbos.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 /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 /* 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: goops classes for smobs
Corrections... :(
"Marco Maggi" wrote:
>scm_make_extended_class_with_supers("my",
>scm_variable_ref(""));
This must be:
scm_make_extended_class_with_supers("my",
scm_list_1(scm_variable_ref("")));
and the change to 'scm_class_of()' must
be something like:
{
/* Goops object */
if (! scm_is_false (SCM_OBJ_CLASS_REDEF (x)))
scm_change_object_class (x, SCM_CLASS_OF (x),
SCM_OBJ_CLASS_REDEF (x));
if (SCM_SMOB_PREDICATE(multi_smob_driver, x))
{
SCM class =
((sub_smob_driver_t)SCM_SMOB_DATA_2(x))->class;
if (SCM_UNSPECIFIED != class)
return class;
}
return SCM_CLASS_OF (x);
}
--
Marco Maggi
"Now feel the funk blast!"
Rage Against the Machine - "Calm like a bomb"
___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
