Cygwin patch for 1.6.4 [WAS: When is 1.8 going to be released]

Cygwin patch for 1.6.4 [WAS: When is 1.8 going to be released]

[Jan Nieuwenhuizen]

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

Han-Wen Nienhuys writes:

>> However, Jan is getting annoyed at having to patch GUILE to get it
>> compiling on cygwin.
>
> I'm not aware of Cygwin patches (which is enterily my fault).

Well, I sent patches for cross compilation and Cygwin just before 1.6:

    http://mail.gnu.org/archive/html/guile-devel/2002-07/msg00014.html

and they were, with some small modifications, included in HEAD.  So,
strictly speaking there are no pending patches but rather a small
1.6.x annoyance.

It should have been OK for me to patch guile-1.6.x for Cygwin, had it
not been for the fact that my build process for Cygwin included:

    libtoolize --force --copy --automake --ltdl

(using a Cygwin prerelease or libtool CVS), because libtool is under
active development for Cygwin.  This broke when guile included a
modified copy of libtool in 1.6.x.

> Please mail them to me and I'll have a look.

Attached.  The biggest part is the libtool diff, you'll want to skip
that and just look at the small upstream/ltdl*diff instead.

Also note that most of this is in HEAD and some of it has already been
modified again a few months ago.

Greetings,
Jan.


[-- Attachment #2: guile-1.6.4-cygwin.gz --]
[-- Type: application/octet-stream, Size: 28315 bytes --]

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


-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

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

Re: Cygwin patch for 1.6.4

[Rob Browning]

Jan Nieuwenhuizen <janneke@gnu.org> writes:

> Attached.  The biggest part is the libtool diff, you'll want to skip
> that and just look at the small upstream/ltdl*diff instead.
>
> Also note that most of this is in HEAD and some of it has already been
> modified again a few months ago.

OK, so just to make sure I follow, this is a patch against 1.6.4, and
it would be appropriate for the upcoming 1.6.5.  Further, if I'm going
ot apply it to 1.6 before 1.6.5, I should ignore the libool bits.  Did
I get that right?

Thanks much.
-- 
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://mail.gnu.org/mailman/listinfo/guile-devel

Re: Cygwin patch for 1.6.4

[Kevin Ryde]

Jan Nieuwenhuizen <janneke@gnu.org> writes:
>
> Attached.

We dropped the --enable-cc-for-build option, in favour of just setting
CC_FOR_BUILD.  The latter is also used by config.guess.

I'd like to similarly drop --enable-guile-for-build, just take a
GUILE_FOR_BUILD variable, but haven't yet got around to proposing
that.

AC_ARG_VAR is good for both CC_FOR_BUILD and GUILE_FOR_BUILD too.


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

Re: Cygwin patch for 1.6.4

[Jan Nieuwenhuizen]

Rob Browning writes:

> OK, so just to make sure I follow, this is a patch against 1.6.4,

Yes,

> it would be appropriate for the upcoming 1.6.5.

Yes,

> Further, if I'm going ot apply it to 1.6 before 1.6.5, I should
> ignore the libool bits.
> Did I get that right?

Maybe, but I'm not sure what happens when you 'ignore the libtool
bits'.  What I meant to say whas that I'd like to have the libtool
part of the patch in too, but that it makes the patch against 1.6.4
deceptively large.  That's because I updated to libtool CVS.

The new guile diffs against libtool, generated automagically in
libguile-ltdl/upstream, are more readable, because they are very
small.

The fact that guile 1.6.x is no longer a standard libtoolized package
(where the user can upgrade libtool with a single command if
necessary) but ships a modified copy that needs some work to upgrade
is what cost me most time.  But maybe I missed something.

Sorry for the confusion.
Greetings,
Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org



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

Re: Cygwin patch for 1.6.4

[Rob Browning]

Jan Nieuwenhuizen <janneke@gnu.org> writes:

>> Further, if I'm going ot apply it to 1.6 before 1.6.5, I should
>> ignore the libool bits.  Did I get that right?
>
> Maybe, but I'm not sure what happens when you 'ignore the libtool
> bits'.  What I meant to say whas that I'd like to have the libtool
> part of the patch in too, but that it makes the patch against 1.6.4
> deceptively large.  That's because I updated to libtool CVS.

Would updating the 1.6 branch using the latest libtool help (though we
may still need to use our libguile-ltdl, depending on what they've
changed), or are you saying you already did that update (hence the
large patch)?  If the latter, then did you just libtoolize to get the
latest bits of everything but libltdl, or did you merge the upstream
libltdl changes into libguile-ltdl as well?

Also do you follow libtool upstream well enough to have a sense that
libtool CVS is be stable enough for a 1.6 point release for all our
other platforms?

> The new guile diffs against libtool, generated automagically in
> libguile-ltdl/upstream, are more readable, because they are very
> small.

> The fact that guile 1.6.x is no longer a standard libtoolized
> package (where the user can upgrade libtool with a single command if
> necessary) but ships a modified copy that needs some work to upgrade
> is what cost me most time.  But maybe I missed something.

Unfortunately, we didn't really have an alternative.  We can still use
libtoolize to bring the guile tree up to date; we just can't use the
upstream libltdl until/unless they've fixed the important bugs.

Thanks for the help.
-- 
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://mail.gnu.org/mailman/listinfo/guile-devel

Re: Cygwin patch for 1.6.4

[Jan Nieuwenhuizen]

Rob Browning writes:

> Would updating the 1.6 branch using the latest libtool help

Yes.

> did you just libtoolize to get the latest bits of everything but
> libltdl, or did you merge the upstream libltdl changes into
> libguile-ltdl as well?

Yes, that was the 'annoying bit'.  I checked and found that most
changes in ./upstream had been merged into libtool already.  It went
something like:

patching file ltdl.c
Hunk #3 succeeded at 124 (offset 32 lines).
Hunk #4 FAILED at 192.
Hunk #5 succeeded at 389 (offset 54 lines).
Hunk #6 FAILED at 435.
Hunk #7 succeeded at 478 with fuzz 2 (offset 51 lines).
Hunk #8 FAILED at 870.
Hunk #9 FAILED at 2036.
Hunk #10 FAILED at 2782.
Hunk #11 FAILED at 3048.
Hunk #12 FAILED at 3075.
7 out of 12 hunks FAILED -- saving rejects to file ltdl.c.rej

[headache]

The only sensible change that was not yet in, as far as I could see,
was to avoid a type warning:

-      dest[i] = src[i];
+      ((char *) dest)[i] = ((char *) src)[i];

With the next version of libtool, I merely updated ltdl.c and ltdl.h
from libtool CVS, as were in the previous patch I sent.  Attached
seperately now.

> Also do you follow libtool upstream well enough to have a sense that
> libtool CVS is be stable enough for a 1.6 point release for all our
> other platforms?

No, I just updated when requested for new Cygwin packages.  With
libtool+Cygwin it's been: fresher checkouts, more stable ;-)

Maybe best to ask the libtool developers.  1.5.1 was released on
August 8, and there was only one Cygwin patch after that, so upgrading
to that would already help a lot.

> Unfortunately, we didn't really have an alternative.  We can still use
> libtoolize to bring the guile tree up to date; we just can't use the
> upstream libltdl until/unless they've fixed the important bugs.

You mean one can do 'libtoolize' but not 'libtoolize --ltdl', but that
doesn't help me.

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org



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

Re: Cygwin patch for 1.6.4

[Jan Nieuwenhuizen]

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

Jan Nieuwenhuizen writes:

> With the next version of libtool, I merely updated ltdl.c and ltdl.h
> from libtool CVS, as were in the previous patch I sent.  Attached
> seperately now.

Really.  So, I'm not sure what guile needs (on other platforms?)
besides these diffs.

Jan.


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

--- /netrel/src/guile-1.6.4-14/libguile-ltdl/upstream/ltdl.h	2003-10-01 19:49:03.000000000 +0200
+++ raw-ltdl.guilemod.h	2003-10-01 20:59:24.000000000 +0200
@@ -28,6 +28,7 @@
 #ifndef LTDL_H
 #define LTDL_H 1
 
+#include "guile-ltdl.h"
 #include <sys/types.h>		/* for size_t declaration */
 
 \f
@@ -206,9 +207,11 @@
    libltdl relies on a featureful realloc, but if you are sure yours
    has the right semantics then you can assign it directly.  Generally,
    it is safe to assign just a malloc() and a free() function.  */
+#if 0
 LT_SCOPE  lt_ptr   (*lt_dlmalloc)	LT_PARAMS((size_t size));
 LT_SCOPE  lt_ptr   (*lt_dlrealloc)	LT_PARAMS((lt_ptr ptr, size_t size));
 LT_SCOPE  void	   (*lt_dlfree)		LT_PARAMS((lt_ptr ptr));
+#endif
 
 
 

[-- Attachment #3: ltdl.c.diff --]
[-- Type: text/plain, Size: 425 bytes --]

--- /netrel/src/guile-1.6.4-14/libguile-ltdl/upstream/ltdl.c	2003-10-01 19:48:56.000000000 +0200
+++ raw-ltdl.guilemod.c	2003-10-01 20:31:34.000000000 +0200
@@ -26,7 +26,7 @@
 */
 
 #if HAVE_CONFIG_H
-#  include <config.h>
+#  include "config.h"
 #endif
 
 #if HAVE_UNISTD_H
@@ -124,7 +124,7 @@
 #  define assert(arg)	((void) 0)
 #endif
 
-#include "ltdl.h"
+#include "raw-ltdl.h"
 
 #if WITH_DMALLOC
 #  include <dmalloc.h>

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]



-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

[-- Attachment #5: Type: text/plain, Size: 142 bytes --]

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

Re: Cygwin patch for 1.6.4

[Rob Browning]

Jan Nieuwenhuizen <janneke@gnu.org> writes:

> Rob Browning writes:
>
>> Would updating the 1.6 branch using the latest libtool help
>
> Yes.

OK, I've updated the 1.6 branch to the latest stable libtool (1.5).
Could you generate a new diff against that containing what you need?
I'd prefer to stick with the stable libtool code if possible, since
it's (hopefully) better tested against all of the supported platforms.

Also, for all those hacking on libguile-ltdl -- bear in mind that
upstream/*.diff don't contain our complete diffs against the upstream
libtool source in ltdl.[hc].  When creating the diffs in
upstream/Makefile.am, we filter out a bunch of scoping related stuff
that's uniniteresting outside of Guile.

Thanks
-- 
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://mail.gnu.org/mailman/listinfo/guile-devel