Re: [ntp:hackers/Guile devel] ntp-dev changes

Re: [ntp:hackers/Guile devel] ntp-dev changes

[Bruce Korb]

Hi Harlan, Reg, NTP developers (via relay) & Guile developers:

This is a problem.  I (almost) only ever use pre-built Guile
packages and let others struggle with the porting issue.
Occasionally, I do build it just to verify that current
versions haven't wiggled too much for AutoGen to operate,
but otherwise, no.

So, Reg, can you please tell us all the platform and compiler
you used that triggered the Guile build failure?

Thank you.

Regards, Bruce

Harlan Stenn wrote:
> Subject: Re: [ntp:hackers] ntp-dev changes
> From: Reg Clemens <reg@dwf.com>
> Date: Thu, 13 Apr 2006 11:57:48 -0600
> To: Harlan Stenn <stenn@ntp.isc.org> 
> 
>>Autogen will not be required until next week, as I'm not going to be
>>adding the AutoGen stuff until after 4.2.2 is out (4.2.1 is now being
>>called 4.2.2 as the last number is now 'even' for 'stable' releases).
>>
>>It's a GNU tool, so any GNU archive should have it.
>>
>>Bruce Korb is the author, and he is (kindly) working with me on this
>>project as we're doing some new things with it.
> 
> Just a quick note, Ive got to take a shower and get down to the lab.
> 
> But, pulled autogen from www.gnu.org, tried compiling it.
> It wanted libguile, which I also dont have.
> I pulled guile-1.6.7 from the same place, that seemed to be what I wanted.
> It died during the build with
> guile.c:91: error: array type has incomplete element type
> 
> Ill look at that when I get home this evening, but this could cause
> folks to be unhappy with the change...

P.S. Reg, it should be possible to Google around and find a pre-built
Guile package for your platform.  AutoGen has been jiggered and re-jiggered
to work with Guile 1.4.7(?) through 1.8 (latest AutoGen only).
BTW, AutoGen should only be required for constructing a distribution, and
not required for building the distribution itself.  It is a development tool.


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

Re: [ntp:hackers/Guile devel] ntp-dev changes

[Reg Clemens]

> Hi Harlan, Reg, NTP developers (via relay) & Guile developers:
> 
> This is a problem.  I (almost) only ever use pre-built Guile
> packages and let others struggle with the porting issue.
> Occasionally, I do build it just to verify that current
> versions haven't wiggled too much for AutoGen to operate,
> but otherwise, no.
> 
> So, Reg, can you please tell us all the platform and compiler
> you used that triggered the Guile build failure?
> 

I tried building 
    guile-1.6.7
from the gnu site.
Not knowing anything about the options available, I did a straight
    ./configure
    make
The configure runs with no errors, but the make terminates with

---

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
make[2]: Leaving directory `/mnt/home/reg/Source/System/Autogen/guile-1.6.7/libguile'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/mnt/home/reg/Source/System/Autogen/guile-1.6.7'
make: *** [all] Error 2

---

This is on Linux Fedora4, with gcc-4.0.2-8.fc4

am I missing something?
I looked arround, and didnt see a prebuilt package anywhere.

-- 
                                        Reg.Clemens
                                        reg@dwf.com




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

Re: [ntp:hackers/Guile devel] ntp-dev changes

[Bruce Korb]

Someone, please correct me if I am wrong, but I think GCC-4 is
still too green for industrial use.  Have you a GCC-3.x handy?

Reg Clemens wrote:
>>Hi Harlan, Reg, NTP developers (via relay) & Guile developers:
>>
>>This is a problem.  I (almost) only ever use pre-built Guile
>>packages and let others struggle with the porting issue.
>>Occasionally, I do build it just to verify that current
>>versions haven't wiggled too much for AutoGen to operate,
>>but otherwise, no.
>>
>>So, Reg, can you please tell us all the platform and compiler
>>you used that triggered the Guile build failure?
>>
> 
> 
> I tried building 
>     guile-1.6.7
> from the gnu site.
> Not knowing anything about the options available, I did a straight
>     ./configure
>     make
> The configure runs with no errors, but the make terminates with
> 
> ---
> 
> 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
> make[2]: Leaving directory `/mnt/home/reg/Source/System/Autogen/guile-1.6.7/libguile'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/mnt/home/reg/Source/System/Autogen/guile-1.6.7'
> make: *** [all] Error 2
> 
> ---
> 
> This is on Linux Fedora4, with gcc-4.0.2-8.fc4
> 
> am I missing something?
> I looked arround, and didnt see a prebuilt package anywhere.

I Googled for ``guile package|rpm redhat|fedora''.  You have to look around a bit:

http://ccrma.stanford.edu/planetccrma/software/redupdates.html
http://dir.filewatcher.com/d/Fedora/i386/Development/Languages/guile-1.6.4-14.i386.rpm.763778.html


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

Re: [ntp:hackers/Guile devel] ntp-dev changes

[Reg Clemens]

Humm.
Linux Fedora4 came with gcc 4.00 and was upgraded to 4.0.2 as some point,
so I dont easily have access to an older version on my home machines.
Checking at the Lab, where I still have Fedora2 loaded, I find gcc 3.3.3,
and guile-1.6.7 DOES compile there.

Still, the error reported sounds more like something has changed between
OS levels than a problem with the compiler itself.  I can try moving the
compiled version back home, but from what Harlan says, I wont be able
to test it for a week or so.

-- 
                                        Reg.Clemens
                                        reg@dwf.com




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

Re: [ntp:hackers/Guile devel] ntp-dev changes

[Bruce Korb]

Reg Clemens wrote:
> Humm.
> Linux Fedora4 came with gcc 4.00 and was upgraded to 4.0.2 as some point,
> so I dont easily have access to an older version on my home machines.
> Checking at the Lab, where I still have Fedora2 loaded, I find gcc 3.3.3,
> and guile-1.6.7 DOES compile there.
> 
> Still, the error reported sounds more like something has changed between
> OS levels than a problem with the compiler itself.  I can try moving the
> compiled version back home, but from what Harlan says, I wont be able
> to test it for a week or so.

Chasing through Guile sources, I get this:

> #ifdef DYNAMIC_LINKING
>   /* libtool automagically inserts this variable into your executable... */
>   extern const scm_lt_dlsymlist lt_preloaded_symbols[]; // Line 91
>   scm_lt_dlpreload_default (lt_preloaded_symbols);
> #endif

The message is:

> guile.c: In function 'main':
> guile.c:91: error: array type has incomplete element type
> guile.c:91: warning: unused variable 'lt_preloaded_symbols'

So, it seems to me that there is an inconsistency in the build environment
and the defining of DYNAMIC_LINKING.  The problem is almost certainly
in Guile.  But, I have heard complaints (that I only fuzzily remember)
that Guile does not build with GCC-4.  Assuming I am remembering
correctly :) , the headers that GCC-4 bring along with itself are
causing "scm_lt_dlsymlist" to be an incomplete type and "scm_lt_dlpreload_default"
to be a macro that expands to the empty string (unreferenced variable).

I'll poke into this a bit more, but I do wish a Guile developer could
chime in with a word or two.

Thanks - Bruce


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

Re: [ntp:hackers/Guile devel] ntp-dev changes

[Bruce Korb]

Bruce Korb wrote:

>
> So, it seems to me that there is an inconsistency in the build 
> environment
> and the defining of DYNAMIC_LINKING. The problem is almost certainly
> in Guile. But, I have heard complaints (that I only fuzzily remember)
> that Guile does not build with GCC-4. Assuming I am remembering
> correctly :) , the headers that GCC-4 bring along with itself are
> causing "scm_lt_dlsymlist" to be an incomplete type and 
> "scm_lt_dlpreload_default"
> to be a macro that expands to the empty string (unreferenced variable).
>
> I'll poke into this a bit more, but I do wish a Guile developer could
> chime in with a word or two. 

In guile-ltdl.h:

 > typedef struct scm_i_lt_dlsymlist_struct scm_lt_dlsymlist;

In guile-ltdl.c /* NOTE: ".c" not ".h" */:

 > #define SCM_INSERTED_DLSYMLIST_STRUCT_DECL scm_i_lt_dlsymlist_struct

In raw-ltdl.h:

> /* --- PRELOADED MODULE SUPPORT --- */
> /* 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;

Guile folks, please, how is this supposed to work? The guile.c module
needs to see all three of these code fragments to compile correctly.
Anyway, for me it builds with GCC 3.x and fails with 4.x, but looks
like it should fail no matter what the compiler. What gives?

Thanks - Bruce


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

Re: [ntp:hackers/Guile devel] ntp-dev changes

[Rob Browning]

Bruce Korb <bkorb@gnu.org> writes:

> Guile folks, please, how is this supposed to work? The guile.c
> module needs to see all three of these code fragments to compile
> correctly.  Anyway, for me it builds with GCC 3.x and fails with
> 4.x, but looks like it should fail no matter what the compiler. What
> gives?

I think this may have been fixed in 1.6 CVS.  If so, the 1.6.8-rc1
test archive that I recently announced should contain the changes.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


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

Re: [ntp:hackers/Guile devel] ntp-dev changes

[Bruce Korb]

Rob Browning wrote:
> Bruce Korb <bkorb@gnu.org> writes:
> 
> 
>>Guile folks, please, how is this supposed to work? The guile.c
>>module needs to see all three of these code fragments to compile
>>correctly.  Anyway, for me it builds with GCC 3.x and fails with
>>4.x, but looks like it should fail no matter what the compiler. What
>>gives?
> 
> 
> I think this may have been fixed in 1.6 CVS.  If so, the 1.6.8-rc1
> test archive that I recently announced should contain the changes.

I haven't pulled CVS, but if this crucial "fix" is simply:

$ diff -u $(find guile-1.6.7  guile-1.6.7-build -name guile.c)
--- guile-1.6.7/libguile/guile.c        2002-12-07 14:41:32.000000000 -0800
+++ guile-1.6.7-build/libguile/guile.c  2006-04-16 09:48:21.402050194 -0700
@@ -88,8 +88,8 @@
  {
  #ifdef DYNAMIC_LINKING
    /* libtool automagically inserts this variable into your executable... */
-  extern const scm_lt_dlsymlist lt_preloaded_symbols[];
-  scm_lt_dlpreload_default (lt_preloaded_symbols);
+  extern const int lt_preloaded_symbols;
+  scm_lt_dlpreload_default ((scm_lt_dlsymlist*)&lt_preloaded_symbols);
  #endif
    scm_boot_guile (argc, argv, inner_main, 0);
    return 0; /* never reached */

then it would be "really nice" to bump out a 1.6 & 1.8 patch asap
and include any other more destabilizing fixes in a later patch.
Thanks - Bruce


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

Re: [ntp:hackers/Guile devel] ntp-dev changes

[Kevin Ryde]

Bruce Korb <bkorb@gnu.org> writes:
>
> Anyway, for me it builds with GCC 3.x and fails with 4.x, but looks
> like it should fail no matter what the compiler. What gives?

Guile in main.c doesn't look at the structure fields so doesn't need
the actual definition.  gcc 3 was happy to throw around pointers to an
undefined struct (I think that was traditional among cc's too), but
gcc 4 has got strict :-(.


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

Re: [ntp:hackers/Guile devel] ntp-dev changes

[Kevin Ryde]

Bruce Korb <bkorb@gnu.org> writes:
>
> -  extern const scm_lt_dlsymlist lt_preloaded_symbols[];
> -  scm_lt_dlpreload_default (lt_preloaded_symbols);
> +  extern const int lt_preloaded_symbols;
> +  scm_lt_dlpreload_default ((scm_lt_dlsymlist*)&lt_preloaded_symbols);

Just for reference, it also works to delete those two lines, the
module preloads array is empty on an elf system.  (And actually I
suspect guile hasn't got the right libtool incantations for a system
that does need that stuff.)


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