> 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
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
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
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 rememberi
Bruce Korb <[EMAIL PROTECTED]> 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 comp
Rob Browning wrote:
Bruce Korb <[EMAIL PROTECTED]> 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 matt
Rob Browning <[EMAIL PROTECTED]> writes:
>
> SLIB fixes for 1.8 are still pending.
You could stick those in whenever you're ready. I dropped the
slib.test because ice-9 slib at the moment bombs with the current
slib.
___
Guile-devel mailing list
Guile
Bruce Korb <[EMAIL PROTECTED]> 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
Kevin Ryde <[EMAIL PROTECTED]> writes:
> You could stick those in whenever you're ready. I dropped the
> slib.test because ice-9 slib at the moment bombs with the current
> slib.
OK, sounds good. I'm still in discussions with Aubrey Jaffer. It
looks like the changes in SLIB behavior for 1.8 ma
I did the dreaded merge. The 1.8 branch now has a tag
branch_release-1-8_last-merged-to-head
as described in the cvs manual, ready for the next merge.
You can see the 1.8 to head diff with
cvs diff -r branch_release-1-8 -r HEAD
The current differences are just version number
Now that libguile-ltdl is unused, I think I might cvs remove it from
1.8 and the head, in the interests of less extraneous stuff. (The old
contents are still in the cvs of course, just not checked out.)
___
Guile-devel mailing list
Guile-devel@gnu.org
Bruce Korb <[EMAIL PROTECTED]> 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*)<_preloaded_symbols);
Just for reference, it also
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Now that libguile-ltdl is unused, I think I might cvs remove it from
> 1.8 and the head, in the interests of less extraneous stuff. (The old
> contents are still in the cvs of course, just not checked out.)
Sounds good to me.
--
Rob Browning
rlb @defaul
Kevin Ryde <[EMAIL PROTECTED]> writes:
> You could stick those in whenever you're ready. I dropped the
> slib.test because ice-9 slib at the moment bombs with the current
> slib.
How did you drop the test? A run of "make check" still fails here.
I'm assuming that you might have just removed sl
14 matches
Mail list logo
