libguile-ltdl

libguile-ltdl

[Han-Wen Nienhuys]

Can someone remind why GUILE uses a separate branch of the ltdl
library? I'm trying to compile GUILE 1.7.1 on Cygwin (something that
we very much want for the pending LilyPond 2.4 release), but GUILE
bombs out with "Application fails to initialize properly
(0xc0000005). Press OK to terminate application," which I suspect is
due to LTDL intricacies.

Could it be that an update of the libguile-ltdl is in place? I notice
that the 1.6.5 has an merge from upstream

(For chrissakes, when will 1.6.5 be released?)

-- 

 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: libguile-ltdl

[Rob Browning]

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

> Can someone remind why GUILE uses a separate branch of the ltdl
> library?

There were bugs in libltdl (serious ones) that were stalled upstream
for a long time.  Since then, I believe all of them have been fixed,
so our code is now essentially identical to upstream libtool.
However, we'll need to discuss what to do next because there's still
the possiblity that we might want to add a versioned dlopen to our
copy, and that the upstream libtool developers wouldn't be interested.

> (For chrissakes, when will 1.6.5 be released?)

Should be by next week (perhaps later this week).  There were some
fixes I noticed last week that had to go in, and then I had to go out
of town.  I'm now finishing an update of the debian/ tree and then I
think it'll be ready.

-- 
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: libguile-ltdl

[Han-Wen Nienhuys]

rlb@defaultvalue.org writes:
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> 
> > Can someone remind why GUILE uses a separate branch of the ltdl
> > library?
> 
> There were bugs in libltdl (serious ones) that were stalled upstream
> for a long time.  Since then, I believe all of them have been fixed,
> so our code is now essentially identical to upstream libtool.
> However, we'll need to discuss what to do next because there's still
> the possiblity that we might want to add a versioned dlopen to our
> copy, and that the upstream libtool developers wouldn't be interested.

Frankly, I find it hard to believe that there are packages that move
more slowly than GUILE.

The following patch solves the problem with GUILE on
Cygwin. Essentially, it completely removes the branched version of
ltdl from GUILE, substituting the system-installed ltdl.  Putting the
branch into GUILE itself has caused headaches for other platforms -in
particular, Cygwin- so I propose we stop doing it.

If there is a need for urgent bugfixes or more features in ltdl, then
they can contributed to libtool, or (in extreme cases) libtool itself
can be forked.





Index: guile-ltdl.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile-ltdl/guile-ltdl.c,v
retrieving revision 1.2
diff -u -r1.2 guile-ltdl.c
--- guile-ltdl.c	9 Oct 2002 21:16:12 -0000	1.2
+++ guile-ltdl.c	6 Oct 2004 22:37:38 -0000
@@ -27,21 +27,8 @@
 
 #include "guile-ltdl.h"
 
-#define lt_dlhandle_struct scm_i_lt_dlhandle_struct
-#define SCM_INSERTED_DLSYMLIST_STRUCT_DECL scm_i_lt_dlsymlist_struct
 
-#define LT_SCOPE static
-#define SCMLTXT static
-#define SCMLTSTATIC static
-
-#ifdef __GNUC__
-#define SCM_UNUSED __attribute__ ((unused))
-#else
-#define SCM_UNUSED
-#endif
 
-#include "raw-ltdl.h"
-#include "raw-ltdl.c"
 
 void
 scm_lt_dlpreload_default (const scm_lt_dlsymlist *preloads)
Index: guile-ltdl.h
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile-ltdl/guile-ltdl.h,v
retrieving revision 1.2
diff -u -r1.2 guile-ltdl.h
--- guile-ltdl.h	9 Oct 2002 21:16:18 -0000	1.2
+++ guile-ltdl.h	6 Oct 2004 22:37:38 -0000
@@ -26,8 +26,10 @@
 #ifndef SCM_LTDL_H
 #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;
+#include "ltdl.h"
+
+typedef lt_dlhandle scm_lt_dlhandle;
+typedef lt_dlsymlist scm_lt_dlsymlist;
 typedef void * scm_lt_ptr;
 
 void            scm_lt_dlpreload_default (const scm_lt_dlsymlist *preloads);




-- 

 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: libguile-ltdl

[Rob Browning]

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

> If there is a need for urgent bugfixes or more features in ltdl, then
> they can contributed to libtool, or (in extreme cases) libtool itself
> can be forked.

This is exactly what happened.  There were a number of attempts to
talk to the libtool upstream over a substantial period of time without
any response, though from a look at the eventual fixes that made it
in, they did eventually receive and apply our fixes.  If it hadn't
been for those communication difficulties, we probably never would
have created libguile-ltdl.

In any case, other than the possibility that we might want to add a
versioned dlopen (and that's only relevant if we're still sure we want
that, and if the libtool upstream wouldn't be interested), it looks
like the other reasons for having libguile-ltdl have been eliminited
by upstream fixes.

I'd like to see what Marius thinks, but we might be able to remove
libguile-ltdl in 1.7 now.  I'd be more hesitant to do so in 1.6,
unless it was only for cygwin.  Removing a library isn't a backward
compatible change.

-- 
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: libguile-ltdl

[Han-Wen Nienhuys]

rlb@defaultvalue.org writes:
> 
> In any case, other than the possibility that we might want to add a
> versioned dlopen (and that's only relevant if we're still sure we want
> that, and if the libtool upstream wouldn't be interested), it looks

what is versioned dlopen, and for which GUILE release is it desired? 


-- 

 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: libguile-ltdl

[Rob Browning]

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

> what is versioned dlopen

The idea would be to add a function that would let you specify the
soname ("interface number") of the library you want to open, and that
function would then use the same algorithm that ld.so does when trying
to find a suitable library.

With the current dlopen, you can't do that.  If you say
dlopen("libfoo"), you have no control over whether you might get
libfoo.so.4, libfoo.so.12, or something else. So you have to resort to
other means, like putting the version in the library name,
i.e. libfoo4 (or libguile-srfi-srfi-4-v-1).  Then you can say
dlopen("libfoo4") and make sure you get libfoo "version" 4, but this
isn't as flexible as saying dlopen_ext("libfoo", 4), which ideally
would find the most recent version of libfoo satisfying interface 4
(just as ld.so does).

Of course we haven't gotten to the point of seeing what would be
involved here, especially cross-platform.  The most basic approach
(for at least linux/elf) would probably involve a search based on the
expected libtool soname.

> and for which GUILE release is it desired? 

No particular release in mind yet, though in the past we had talked
about it for 1.8.  However, now that we've worked around the issue by
putting the soname/version in the name for all of the libs that we
expect to dlopen, it's not as urgent, though it might be nice for
other projects that don't want to have to mangle their library names.

-- 
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: libguile-ltdl

[Han-Wen Nienhuys]

rlb@defaultvalue.org writes:
> I'd like to see what Marius thinks, but we might be able to remove
> libguile-ltdl in 1.7 now.  I'd be more hesitant to do so in 1.6,
> unless it was only for cygwin.  Removing a library isn't a backward
> compatible change.

Why not make it a configuration option? Then we don't throw away the
work of infrastructure for making the forked libtool.

-- 

 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: libguile-ltdl

[Rob Browning]

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

> rlb@defaultvalue.org writes:
>> I'd like to see what Marius thinks, but we might be able to remove
>> libguile-ltdl in 1.7 now.  I'd be more hesitant to do so in 1.6,
>> unless it was only for cygwin.  Removing a library isn't a backward
>> compatible change.
>
> Why not make it a configuration option? Then we don't throw away the
> work of infrastructure for making the forked libtool.

I'm OK with dumping libguile-ltdl altogether in 1.7, if we don't think
we're going to pursue enhancements anytime soon.  We can always add it
back later, and a --disable-libguile-ltdl option sounds like it might
be a reasonable way to handle the problem in 1.6 if the fix for
libguile-ldtl for cygwin is too hard.

Although if it's just cygwin, and if libguile-ltdl has *never* worked
there, then another alternative might be to just disable it when
cygwin is detected.

Ideally though, I'd still much rather just have a fix for
libguile-ltdl on cygwin if that were possible, and not too difficult.

-- 
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: libguile-ltdl

[Han-Wen Nienhuys]

rlb@defaultvalue.org writes:
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> 
> > rlb@defaultvalue.org writes:
> >> I'd like to see what Marius thinks, but we might be able to remove
> >> libguile-ltdl in 1.7 now.  I'd be more hesitant to do so in 1.6,
> >> unless it was only for cygwin.  Removing a library isn't a backward
> >> compatible change.
> >
> > Why not make it a configuration option? Then we don't throw away the
> > work of infrastructure for making the forked libtool.
> 
> I'm OK with dumping libguile-ltdl altogether in 1.7, if we don't think
> we're going to pursue enhancements anytime soon.  We can always add it
> back later, and a --disable-libguile-ltdl option sounds like it might
> be a reasonable way to handle the problem in 1.6 if the fix for
> libguile-ldtl for cygwin is too hard.
> 
> Although if it's just cygwin, and if libguile-ltdl has *never* worked
> there, then another alternative might be to just disable it when
> cygwin is detected.

The problem is that both the platform (cygwin / gcc conventions) and
libtool are heavily in flux. I believe you need to get either the
latest Cygwin source release, or libtool CVS to get it working
correctly.  I don't know which one, and frankly, I don't want to know.

This is also why I think it is a bad idea to put libtool in GUILE: it
is a lowlevel library and it can change rapidly in response to
platform changes.

-- 

 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: libguile-ltdl

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> I'd like to see what Marius thinks, but we might be able to remove
> libguile-ltdl in 1.7 now.

Without having given it too much tought, I'd say that we should
probably return to a standard libltdl setup now.  The bugs are fixed,
and when we want to fork libltdl again, we can do it then.  No need to
carry the current setup around only to cause trouble.

> I'd be more hesitant to do so in 1.6, unless it was only for cygwin.
> Removing a library isn't a backward compatible change.

We could update libguile-ltdl in 1.6 from the libtool CVS, if that
helps.


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

Re: libguile-ltdl

[Marius Vollmer]

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

> The following patch solves the problem with GUILE on
> Cygwin. Essentially, it completely removes the branched version of
> ltdl from GUILE, substituting the system-installed ltdl.  Putting the
> branch into GUILE itself has caused headaches for other platforms -in
> particular, Cygwin- so I propose we stop doing it.

Yep, we can do that.  I still curious, tho, about the difference
between Cygwin libltdl and the latest released libltdl.  Can you say
something about this?


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