24 |
interface number (i.e. libguilereadline-15) and needs to be done |
interface number (i.e. libguilereadline-15) and needs to be done |
25 |
before 1.6 is released. 2) is harder to do and should be deferred to |
before 1.6 is released. 2) is harder to do and should be deferred to |
26 |
1.8. |
1.8. |
27 |
|
|
28 |
|
With respect to (2) above, |
29 |
|
|
30 |
|
A proposal: |
31 |
|
|
32 |
|
(1) Write our own lt_dlopen(char *name, unsigned int interface) |
33 |
|
which will DTRT, when called like this |
34 |
|
|
35 |
|
scm_lt_dlopen("libfoo", 12) |
36 |
|
|
37 |
|
How we can do this will depend in part on how libltdl works, but |
38 |
|
if at all possible, we should probably try to use the same |
39 |
|
algorithm to choose the appropriate shared lib from the |
40 |
|
available X.Y.Z library versions that ldso does for normal |
41 |
|
dynamically linked (not dlopend) libs. |
42 |
|
|
43 |
|
One fairly simple possibility that *might* work, would be to |
44 |
|
require that all guile shared libs install a versioned .la file, |
45 |
|
perhaps by copying the build-time libfoo.la to libfoo.la.X.Y.Z |
46 |
|
or similar. Then our scm_lt_dlopen function would use the |
47 |
|
interface number, and ltdl's * exact* algorithm to find a suitable |
48 |
|
.la.* file and directly lt_dlopen that. |
49 |
|
|
50 |
|
(2) Provide a scheme level interface that allows you to ask for a |
51 |
|
particular interface, something like (some-link-func |
52 |
|
"libguile-foo" 3) and uses scm_lt_dlopen to make sure you get |
53 |
|
the right lib. |
54 |
|
|
55 |
|
(3) Once we're finished with (1), see if the ltdl people are |
56 |
|
interested. |
57 |
|
|
58 |
|
(4) Whatever we do, we should still allow people to call lt_dlopen |
59 |
|
directly if they want to -- we'd provide this as part of a |
60 |
|
"lower-level" linker interface. |