GUILE 1.6 CVS doesn't compile

GUILE 1.6 CVS doesn't compile

[Han-Wen Nienhuys]

hi,

GUILE CVS,  today. After  cvs up, autogen, configure, I get

guile.c: In function 'main':
guile.c:91: error: array type has incomplete element type
guile.c:91: warning: unused variable 'lt_preloaded_symbols'
make[2]: *** [guile.o] Error 1

scm_lt_dlsymlist  only appears in this place in the libguile/ directory.

-- 
  Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen


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

Re: GUILE 1.6 CVS doesn't compile

[Han-Wen Nienhuys]

Han-Wen Nienhuys wrote:
> 
> hi,
> 
> GUILE CVS,  today. After  cvs up, autogen, configure, I get
> 
> guile.c: In function 'main':
> guile.c:91: error: array type has incomplete element type
> guile.c:91: warning: unused variable 'lt_preloaded_symbols'
> make[2]: *** [guile.o] Error 1
> 
> scm_lt_dlsymlist  only appears in this place in the libguile/ directory.
> 

this is with Fedora Core 4 test 3.

-- 
  Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen


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

Re: GUILE 1.6 CVS doesn't compile

[Kevin Ryde]

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>
> guile.c:91: error: array type has incomplete element type
>
> this is with Fedora Core 4 test 3.

What gcc is that, has it got pickier about pointers to unspecified
structs?


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

Re: GUILE 1.6 CVS doesn't compile

[Han-Wen Nienhuys]

Kevin Ryde wrote:
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> 
>>guile.c:91: error: array type has incomplete element type
>>
>>this is with Fedora Core 4 test 3.
> 
> 
> What gcc is that, has it got pickier about pointers to unspecified
> structs?
> 

GCC 4.0.0



-- 
  Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen


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

Re: GUILE 1.6 CVS doesn't compile

[Han-Wen Nienhuys]

Kevin Ryde wrote:
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> 
>>guile.c:91: error: array type has incomplete element type
>>
>>this is with Fedora Core 4 test 3.
> 
> 
> What gcc is that, has it got pickier about pointers to unspecified
> structs?

I have changed it to use a pointer. It seems to work, and it seems to 
compile.




-- 
  Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen


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

Re: GUILE 1.6 CVS doesn't compile

[Kevin Ryde]

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>
> I have changed it to use a pointer. It seems to work, and it seems to 
> compile.

That can't be right can it?  It's supposed to be an array of structs,
not a pointer.


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

Re: GUILE 1.6 CVS doesn't compile

[Han-Wen Nienhuys]

Kevin Ryde wrote:
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> 
>>I have changed it to use a pointer. It seems to work, and it seems to 
>>compile.
> 
> 
> That can't be right can it?  It's supposed to be an array of structs,
> not a pointer.

   make check

isn't complaining.

-- 
  Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen


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

Re: GUILE 1.6 CVS doesn't compile

[Kevin Ryde]

[-- Attachment #1: Type: text/plain, Size: 653 bytes --]

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>
>   make check
>
> isn't complaining.

I think it works only because that preload array is empty.  There's a
terminating zero entry, so the fetch from there gives NULL, and
lt_dlpreload_default can tolerate NULL (it looks like NULL is what's
there if you never call lt_dlpreload_default at all).

If the array wasn't empty the fetch would be the address of the first
symbol name string, and interpreting that as structs would bomb.

I suppose the fix is to define the struct, perhaps per below.  Or
perhaps the lt_dlpreload_default call isn't needed at all if there's
no -dlopen or -dlpreopen in the link.


[-- Attachment #2: libguile-ltdl.diff --]
[-- Type: text/plain, Size: 1443 bytes --]

Index: guile-ltdl.h
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile-ltdl/guile-ltdl.h,v
retrieving revision 1.2.2.2
diff -u -r1.2.2.2 guile-ltdl.h
--- guile-ltdl.h	23 May 2005 20:15:31 -0000	1.2.2.2
+++ guile-ltdl.h	10 Jul 2005 23:58:57 -0000
@@ -27,8 +27,11 @@
 #define SCM_LTDL_H 1
 
 typedef struct scm_i_lt_dlhandle_struct *scm_lt_dlhandle;
-typedef struct scm_i_lt_dlsymlist_struct scm_lt_dlsymlist;
 typedef void * scm_lt_ptr;
+typedef struct scm_i_lt_dlsymlist_struct {
+  const char *name;
+  scm_lt_ptr address;
+} scm_lt_dlsymlist;
 
 void            scm_lt_dlpreload_default (const scm_lt_dlsymlist *preloads);
 int             scm_lt_dlinit (void);
Index: raw-ltdl.h
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile-ltdl/raw-ltdl.h,v
retrieving revision 1.2.2.2
diff -u -r1.2.2.2 raw-ltdl.h
--- raw-ltdl.h	23 May 2005 20:15:31 -0000	1.2.2.2
+++ raw-ltdl.h	10 Jul 2005 23:58:57 -0000
@@ -211,10 +211,7 @@
 
 /* A preopened symbol. Arrays of this type comprise the exported
    symbols for a dlpreopened module. */
-typedef struct SCM_INSERTED_DLSYMLIST_STRUCT_DECL {
-  const char *name;
-  lt_ptr      address;
-} lt_dlsymlist;
+typedef struct scm_i_lt_dlsymlist_struct lt_dlsymlist;
 
 SCMLTXT	int	lt_dlpreload	LT_PARAMS((const lt_dlsymlist *preloaded));
 SCMLTXT	int	lt_dlpreload_default

[-- Attachment #3: Type: text/plain, Size: 143 bytes --]

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

Re: GUILE 1.6 CVS doesn't compile

[Han-Wen Nienhuys]

Kevin Ryde wrote:
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> 
>>  make check
>>
>>isn't complaining.
> 
> 
> I think it works only because that preload array is empty.  There's a

Shouldn't this be excercised by a test as well?



-- 
  Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen


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

Re: GUILE 1.6 CVS doesn't compile

[Han-Wen Nienhuys]

Kevin Ryde wrote:
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> 
>>  make check
>>
>>isn't complaining.
> 
> 
> I think it works only because that preload array is empty.  There's a
> terminating zero entry, so the fetch from there gives NULL, and
> lt_dlpreload_default can tolerate NULL (it looks like NULL is what's
> there if you never call lt_dlpreload_default at all).
> 
> If the array wasn't empty the fetch would be the address of the first
> symbol name string, and interpreting that as structs would bomb.

I'm loosing you here, AFAIK, the C compiler treats

   extern struct bla foo[] ;
   extern struct bla *foo ;

exactly the same in a function call of the form

   preload (foo)

the only potential problem I see is with nitpicking compilers/linkers.

Anyway, it seems to work. Will you commit?

> I suppose the fix is to define the struct, perhaps per below.  Or
> perhaps the lt_dlpreload_default call isn't needed at all if there's
> no -dlopen or -dlpreopen in the link.


-- 
  Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen


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

Re: GUILE 1.6 CVS doesn't compile

[Kevin Ryde]

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>
> Shouldn't this be excercised by a test as well?

Maybe, but I don't see an easy way to do that in the normal svr4
linker case.  If we had a static-only platform and were using libtool
-dlopen the way it's meant to be then I guess it'd bomb.

> I'm loosing you here, AFAIK, the C compiler treats
>
>   extern struct bla foo[] ;
>   extern struct bla *foo ;
>
> exactly the same in a function call of the form
>
>   preload (foo)

No, the first says at foo you'll find a struct bla (or several).  The
second says at foo you'll find 4 bytes, those being an address (of a
struct, or several).  The generated code differs accordingly (an extra
fetch for the latter).

> Anyway, it seems to work. Will you commit?

My change?  Yes, I think so.  The radical alternative would be to
ditch the private ltdl the same as in the head, but Rob can thin about
that.


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