* packaging the add-on libs... @ 2002-10-10 5:03 Rob Browning 2002-10-10 7:12 ` tomas 2002-10-10 12:51 ` Greg Troxel 0 siblings, 2 replies; 12+ messages in thread From: Rob Browning @ 2002-10-10 5:03 UTC (permalink / raw) I spoke with Marius a little while back about some of the complexities involved in properly managing the versioning of our add-on libs, both those we provide, and those provided by others, and working on packaging guile 1.6 makes some of these issues clearer and more immediate. Consider libguile-srfi-srfi-4-v-1 which will be linked against a particular libguile. What guarantees are we going to make about future releases of this add-on lib? Do we guarantee that we'll always change its major number whenever we release a new libguile? It seems like we must, since otherwise we could have outside apps or libs linked against a set of add-on libs that point to a mixed set of libguile versions. As an example, say libguile13 ships with libguile-foo-v-1 and libguile-bar-v-7, and libguile14 ships with libguile-foo-v-2 and libguile-bar-v-7. At this point we have a problem. Any older app on the system that was originally linked against libguile13, libguile-foo-v-1, and libguile-bar-v-7 would still have all its package depdendencies satisfied and would link at runtime without any problems (at least I think it would), but it would be using libguile13 via foo and libguile14 via bar. Presuming my analysis is right, I guess maybe we can just try to make sure the rules about versioning your add-on libraries are clear, but I'm concerned that a lot of people (especially people writing add-on libs outside the core -- if we end up with a lot of them) may not always remember or know the rules, and it seems like the resulting bugs could be subtle and hard to track down. One clear solution might be to just establish the convention that you always embed the libguile major version number in the add-on lib's name. This seems like it would eliminate the possibility for error on this front, but is a little unusual. i.e. instead of libguile-srfi-srfi-4-v-1, etc., you'd have: libguile12-srfi-srfi-4-v-1 libguile12-srfi-srfi-13-14-v-3 libguile12-foo-bar-v-4 etc. Thoughts? -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: packaging the add-on libs... 2002-10-10 5:03 packaging the add-on libs Rob Browning @ 2002-10-10 7:12 ` tomas 2002-10-10 15:22 ` Rob Browning 2002-10-10 12:51 ` Greg Troxel 1 sibling, 1 reply; 12+ messages in thread From: tomas @ 2002-10-10 7:12 UTC (permalink / raw) Cc: guile-devel On Thu, Oct 10, 2002 at 12:03:42AM -0500, Rob Browning wrote: > > I spoke with Marius a little while back about some of the complexities > involved in properly managing the versioning of our add-on libs [...] [snip] > As an example, say libguile13 ships with libguile-foo-v-1 and > libguile-bar-v-7, and libguile14 ships with libguile-foo-v-2 and > libguile-bar-v-7. [snip] > [the system] would be using libguile13 > via foo and libguile14 > via bar. > > One clear solution might be to just establish the convention that you > always embed the libguile major version number in the add-on lib's > name. [snip] > libguile12-srfi-srfi-4-v-1 > libguile12-srfi-srfi-13-14-v-3 > libguile12-foo-bar-v-4 Looks viable to me (but not excitingly beautiful, mind you ;) At the risk of boring you all (or even of being flamed out of the list ;-) I'd like to repeat what has been (or is being) discussed in another thread. The Big Guys (those with the P in the name, you remember) have version-dependent [1] subdirectories where they stuff the modules into which `belong' to the interpreter [2]. This is a strategy also followed by Emacs. I think this approach might minimize the problems you expose above. Of course, Marius is right in not wanting to introduce gratuitous dependencies and trying to distribute modules which are usable as either guile extensions or as shared libs on their own. But those shouldn't care about which guile version they are linked against (or even whether there is guile around at all), and I'd expect them to provide some (even if stripped down) functionality in any case. --------- [1] Dependent on the version of the main interpreter, that is. [2] I see two criteria to decide whether a module `belongs' to the interpreter: (a) it cares enough about the version of the interpreter it gets (dependencies on the API or ABI), and (b) it doesn't make much sense (or wouldn't even work) without *some* version of the interpreter (e.g. a debugger or profiler for guile). Note that (a) is stronger -- still I'd plea to stuff modules satisfiyng (b) into a guile-specific (maybe not version-specific) directory. Note that your example above libguile-foo-v-1 satifies (a). Hope I've been clear Thanks -- tomas _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: packaging the add-on libs... 2002-10-10 7:12 ` tomas @ 2002-10-10 15:22 ` Rob Browning 2002-10-11 9:41 ` tomas 0 siblings, 1 reply; 12+ messages in thread From: Rob Browning @ 2002-10-10 15:22 UTC (permalink / raw) Cc: guile-devel tomas@fabula.de writes: > At the risk of boring you all (or even of being flamed out of the > list ;-) I'd like to repeat what has been (or is being) discussed > in another thread. The Big Guys (those with the P in the name, you > remember) have version-dependent [1] subdirectories where they > stuff the modules into which `belong' to the interpreter [2]. This > is a strategy also followed by Emacs. I think this approach might > minimize the problems you expose above. It's been stated that we're going to keep all the directly linkable libs in the "normal place". That means /usr/lib, and that would apply to all the add-on libs so far (i.e. we don't have any non-directly C linkable) add-on libs right now. I guess you could argue for a versioned directory for any new shared libs that aren't supposed to be directly linkable by any other apps or libs. > Of course, Marius is right in not wanting to introduce gratuitous > dependencies and trying to distribute modules which are usable as > either guile extensions or as shared libs on their own. But those > shouldn't care about which guile version they are linked against (or > even whether there is guile around at all), and I'd expect them to > provide some (even if stripped down) functionality in any case. These libraries *have* to care about which guile version they're linked against. For example, libguile-srfi-srfi-4-v-1 *has* to be linked against libguile12 so it can use even primitive operations like car and cdr. And of course libguile12 depends intimately on the particular source in ice-9/ that it comes with. There's no such thing as a stand-alone guile module/shared-lib. If they don't depdend on libguileX, they can't *do* anything -- no car, no cdr, no GC, etc. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: packaging the add-on libs... 2002-10-10 15:22 ` Rob Browning @ 2002-10-11 9:41 ` tomas 2002-10-11 15:59 ` Rob Browning 2002-10-11 16:14 ` Rob Browning 0 siblings, 2 replies; 12+ messages in thread From: tomas @ 2002-10-11 9:41 UTC (permalink / raw) Cc: guile-devel On Thu, Oct 10, 2002 at 10:22:42AM -0500, Rob Browning wrote: > tomas@fabula.de writes: > [...] > It's been stated that we're going to keep all the directly linkable > libs in the "normal place". Yes, I know (that's why I know I was taking risks ;-). I felt uneasy then and still feel uneasy abut it (see below). > That means /usr/lib, and that would apply > to all the add-on libs so far (i.e. we don't have any non-directly C > linkable) add-on libs right now. > > I guess you could argue for a versioned directory for any new shared > libs that aren't supposed to be directly linkable by any other apps or > libs. Yes, kind of. Only that I'd substitute ``that aren't supposed to be directly linkable by'' for ``that have to go with guile to be linked by...'' In other words, if you need guile in conjunction with libfoo, then libfoo has no business in /usr/lib or /usr/local/lib -- but rather in /usr/lib/guile/1.6/ (or something like that). IMHO, of course. [snip] > These libraries *have* to care about which guile version they're > linked against. For example, libguile-srfi-srfi-4-v-1 *has* to be > linked against libguile12 so it can use even primitive operations like > car and cdr. And of course libguile12 depends intimately on the > particular source in ice-9/ that it comes with. There's no such thing > as a stand-alone guile module/shared-lib. If they don't depdend on > libguileX, they can't *do* anything -- no car, no cdr, no GC, etc. Well -- one could imagine (say) some regexp library or some DBM library which is delivered with guile but would make sense as a stand-alone. If it's possible to keep the glue code separate, it might be possible to make it guile-independent (my hazy memory suggests SDBM from Perl as an example, but may be I'm forgetting important bits here). Regards -- tomas _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: packaging the add-on libs... 2002-10-11 9:41 ` tomas @ 2002-10-11 15:59 ` Rob Browning 2002-10-14 11:34 ` tomas 2002-10-11 16:14 ` Rob Browning 1 sibling, 1 reply; 12+ messages in thread From: Rob Browning @ 2002-10-11 15:59 UTC (permalink / raw) Cc: guile-devel tomas@fabula.de writes: > Yes, I know (that's why I know I was taking risks ;-). I felt uneasy > then and still feel uneasy abut it (see below). Well FWIW, I did some experimentation, and at least on debian systems, during the process of re-building/uploading which would happen every time we release a new major version of libguile, I determined that you are likely to end up with cross-version-links. In my example (imagine libbase is libguile): $ ldd .libs/some-app-2 libuses-base-foo2.so.2 => not found libbase2.so.2 => not found libuses-base-bar.so.1 => not found libbase1.so.1 => not found libc.so.6 => /lib/libc.so.6 (0x40027000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Note that in the expirimental tree, some-app-2 was only linked via libtool against libuses-base-bar and libuses-base-foo2, the two libbase links were pulled in because uses-base-foo2 and uses-base-bar were originally linked against two different versions of libbase. I don't know if how this would work on other platforms, but what's interesting is that at runtime, it appears that the loader resolves any duplicate symbols in favor of the first library listed on the libtool link line. In this case, even though libuses-base-foo2 was linked against libbase2, when it calls libbase_init, it prints the message I put in libbase1's libbase_init. There are no linkage warnings. libuses-base-bar was listed first on the libtool link line, and if I reverse that so that libuses-base-foo2 comes first, then we see the messages from libbase2. In some sense, this could be seen as a good thing, and would hide most problems, i.e. even though you have dual linkage, you always get the symbols from just one version of the libs, but in reality I believe it's a potential disaster since (for example) libuses-base-foo2 was built using libbase2's headers, and libuses-base-bar was built using libbase1's headers. This means that one of them is going to be operating on libbase data structures with the wrong set of macros. Another potential problems comes if libbase2 adds new functions or deletes old ones, then depending on whether libbase2 or libbase1 takes precedence in the "dual link", you'll have some functions from one version of libbase and some from another. > Yes, kind of. Only that I'd substitute ``that aren't supposed to be > directly linkable by'' for ``that have to go with guile to be linked > by...'' > > In other words, if you need guile in conjunction with libfoo, then > libfoo has no business in /usr/lib or /usr/local/lib -- but rather > in /usr/lib/guile/1.6/ (or something like that). IMHO, of course. The main problem with this is that any apps or libs linked against these "add-on" libs will have to do something special to access the libs, i.e. -rpath, mangling LD_LIBRARY_PATH, etc. and as we've discussed, there are some definite issues with doing that portably, and in a way that doesn't have the potential to interact badly with other libs that might do the same thing, so we'd have to be cautious when considering this approach. For libs no-one's ever allowed to link directly to, there's no problem. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: packaging the add-on libs... 2002-10-11 15:59 ` Rob Browning @ 2002-10-14 11:34 ` tomas 0 siblings, 0 replies; 12+ messages in thread From: tomas @ 2002-10-14 11:34 UTC (permalink / raw) Cc: tomas, guile-devel On Fri, Oct 11, 2002 at 10:59:53AM -0500, Rob Browning wrote: > tomas@fabula.de writes: > > > Yes, I know (that's why I know I was taking risks ;-). I felt uneasy > > then and still feel uneasy abut it (see below). > > Well FWIW, I did some experimentation [...] [enlightening example snipped] I totally agree with you in that this double linkage leads to undefined behaviour (different from system to system and probably not explicitly documented on most systems, so that e.g. ld-linux.so might feel free to change its behaviour some day without saying so). It's most undesirable, so I think the ideas you posted elsewhere (checking the lib version I'm linked against to catch this case) are definitely worth a try. [...] > The main problem with this is that any apps or libs linked against > these "add-on" libs will have to do something special to access the > libs, i.e. -rpath, mangling LD_LIBRARY_PATH, etc. That was more or less what I was pleading for: in the cases we can (that is: for what can be considered a guile ``plugin''), do it -- in the cases we can't (that is: ``standard system libs''), well, don't -- just use system standard searching and loading mechanism. That imposes the burden of differentiating plugins from simple libraries (in a way less elegant). But it buys us something. > and as we've > discussed, there are some definite issues with doing that portably, > and in a way that doesn't have the potential to interact badly with > other libs that might do the same thing, so we'd have to be cautious > when considering this approach. For libs no-one's ever allowed to > link directly to, there's no problem. You have more experience with those issues than me, so I'm ready to shut up, having made enough noise already ;-) Regards -- tomas _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: packaging the add-on libs... 2002-10-11 9:41 ` tomas 2002-10-11 15:59 ` Rob Browning @ 2002-10-11 16:14 ` Rob Browning 2002-10-11 17:10 ` Greg Troxel 1 sibling, 1 reply; 12+ messages in thread From: Rob Browning @ 2002-10-11 16:14 UTC (permalink / raw) Cc: guile-devel tomas@fabula.de writes: >> It's been stated that we're going to keep all the directly linkable >> libs in the "normal place". > > Yes, I know (that's why I know I was taking risks ;-). I felt uneasy > then and still feel uneasy abut it (see below). Actually, one other thing I wanted to mention (and have already mentioned to Marius). Even though this library issue seems to me like a potentially serious impediment to being able to upgrade from one version of guile to another gracefully, especially if guile has a lot of add-on libs provided by third parties, after talking to Bill, it seems that although going with libguile12-foo-bar would be likely fix the problem for guile, it still wouldn't address the same problem for all the other non-guile libs on the system. i.e. what about opengl, libc, X etc. So I'm wondering if perhaps I'm just coming to fully apprehend what is in fact a common unix problem (when inter-library dependencies are involved), one that people just don't think about very often, and one that perhaps it's not guile's job to fix. Not sure. What do others think? The problem is that if we don't do anything, there *will* likely be trouble if we release guile-XY, with a new major version of libguile and the system has some library or app blarg that depends on libguile-someones-foo and libguile-someone-elses-bar. If lib*foo gets upgraded on the system before lib*bar does, then blarg will likely end up being indirectly linked against 2 different major versions of libguile until a new major version of lib*bar is released. I was hoping we could avoid intermediate brokenness like that, but perhaps we can't. I guess in debian that would just mean another one of those periods during a major interpreter migration where things are very shaky. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: packaging the add-on libs... 2002-10-11 16:14 ` Rob Browning @ 2002-10-11 17:10 ` Greg Troxel 2002-10-11 18:26 ` Rob Browning 0 siblings, 1 reply; 12+ messages in thread From: Greg Troxel @ 2002-10-11 17:10 UTC (permalink / raw) Cc: guile-devel Even though this library issue seems to me like a potentially serious impediment to being able to upgrade from one version of guile to another gracefully, especially if guile has a lot of add-on libs provided by third parties, after talking to Bill, it seems that although going with libguile12-foo-bar would be likely fix the problem for guile, it still wouldn't address the same problem for all the other non-guile libs on the system. i.e. what about opengl, libc, X etc. So I'm wondering if perhaps I'm just coming to fully apprehend what is in fact a common unix problem (when inter-library dependencies are involved), one that people just don't think about very often, and one that perhaps it's not guile's job to fix. Not sure. What do others think? I think all grief due to linking with guile really is guile's problem to solve. The other packages have to support either multiple versions or be nearly 100% compile-time compatible with correct older source. With libc, for example, there is a notion that programs compile against the latest headers/libs, and that this latest version is compile-time compatible with programs written for previous versions. Then, one keeps old e.g. libc.so.3 around. For libc, X11 and things like that (at least on BSD - I haven't used Linux in a while) this really is the case and things work fine. With guile, the problem is that a program written for guile 1.4 will not necessarily compile against guile 1.6, due to removal of deprecated stuff and interface changes. While it might be nice to avoid this, guile isn't as mature as libc. This lack of compatibility causes guile to have the obligation to support simultaneous installation of 1.4 and 1.6, at least until all the packages that want 1.4 have --without-guile added to their control files :-) Seriously - that's what I suspect would happen. I think we should strive for a situation where package maintainers can easily have them both, and then programs can get upgraded to use 1.6 'soon', rather than having a huge flag day. I'm less worried about guile-gtk, since that tends to get dynamically loaded from a scheme script. It's things like gnumeric, which on FreeBSD links with 47 libraries, but not guile. Gnumeric source supports guile, but the pkg maintainer turned it off for some reason. This is what I'd like to avoid - IMHO guile should strive to make it easy for others to not only write code to use it, but to package with it. I suggest glib 1.2 and glib 2.0 as an example that is similar to guile - a library used by lots of things, where 1.2 is still in wide use due to programs that haven't been updated yet. Of course, glib has more mindshare than guile, but I think this is where we want to go. We might even use pkgconfig, which has support for finding versions at least/most various values, and would avoid the guile-config name collision. Really, I'm arguing for putting the guile version number in the names ($(prefix)/include/guile16 and all). Programs using guile-config and later pkg-config hopefully should not be put out by this. Sorry for rambling on again... Greg Troxel <gdt@ir.bbn.com> _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: packaging the add-on libs... 2002-10-11 17:10 ` Greg Troxel @ 2002-10-11 18:26 ` Rob Browning 2002-10-11 20:37 ` Greg Troxel 0 siblings, 1 reply; 12+ messages in thread From: Rob Browning @ 2002-10-11 18:26 UTC (permalink / raw) Cc: guile-devel Greg Troxel <gdt@ir.bbn.com> writes: > With libc, for example, there is a notion that programs compile > against the latest headers/libs, and that this latest version is > compile-time compatible with programs written for previous versions. > Then, one keeps old e.g. libc.so.3 around. For libc, X11 and things > like that (at least on BSD - I haven't used Linux in a while) this > really is the case and things work fine. > > With guile, the problem is that a program written for guile 1.4 will > not necessarily compile against guile 1.6, due to removal of > deprecated stuff and interface changes. It's not just the compilation issue. To take your libc example, the issue in question is what happens if app blarg uses both libfoo1 and libbar1, and both of these are compiled against libc6, and then libc7 comes out. Say shortly thereafter libfoo2 comes out, compiled against libc7. If blarg is now recompiled, it'll get libfoo2 and libbar1 and hence will be indirectly linked against both libc6 and libc7 until/unless a new libfoo comes out that's linked against libc7. Is the answer "well, then blarg will just have a potential problem until libbar is updated"? > I think we should strive for a situation where package maintainers > can easily have them both, and then programs can get upgraded to use > 1.6 'soon', rather than having a huge flag day. Being able to have both installed would keep us from stalling all the developers during the transition period, but it won't really help with the problem above. I believe the libguileX-somelib naming convention would fix the problem, but as mentioned, only for guile. It wouldn't address the broader unix inter-lib version problem, and so perhaps we should just suffer along with everyone else through the (hopefully brief) transition periods. The transition period would consist of the time between when a new libguileX comes out, and when all the "add-on libs" that depend on the old version of libguile are rebuilt against the new version of guile. Actually it's only the add-on libs that are actually used by some other app or lib that also uses some other add-on lib that cause trouble, but we can't predict that. Of course, if it takes a long time for add-on libs that are commonly used in conjunction with other guile libs to get updated, then the "transition period" could be long. For example, if there were a libguile-gobject that languished, that could really hold things up. > I'm less worried about guile-gtk, since that tends to get dynamically > loaded from a scheme script. Right. Guile-gtk's not really a good example, but an external libguile-gobject that you could call from other C libs/programs would be a good example, say one that provided scm_gobject_create_obj () or whatever. > I suggest glib 1.2 and glib 2.0 as an example that is similar to guile > - a library used by lots of things, where 1.2 is still in wide use due > to programs that haven't been updated yet. Of course, glib has more > mindshare than guile, but I think this is where we want to go. glib's only a good example if you consider it in a broader context. Imagine after glib 2.0 is released, libgnome-vfs has been upgraded to compile against glib 2.0 but libgnome-print has not. Where does this leave evolution when it recompiles (presuming it links against both libs)? (I'm not sure this particular case would be a problem, but it's an example of the broader issue...) > Sorry for rambling on again... Not at all. I appreciate the effort. This is too complicated for me to even want to try to figure out on my own. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: packaging the add-on libs... 2002-10-11 18:26 ` Rob Browning @ 2002-10-11 20:37 ` Greg Troxel 0 siblings, 0 replies; 12+ messages in thread From: Greg Troxel @ 2002-10-11 20:37 UTC (permalink / raw) Cc: guile-devel It's not just the compilation issue. To take your libc example, the issue in question is what happens if app blarg uses both libfoo1 and libbar1, and both of these are compiled against libc6, and then libc7 comes out. Say shortly thereafter libfoo2 comes out, compiled against libc7. If blarg is now recompiled, it'll get libfoo2 and libbar1 and hence will be indirectly linked against both libc6 and libc7 until/unless a new libfoo comes out that's linked against libc7. Is the answer "well, then blarg will just have a potential problem until libbar is updated"? I don't think we can solve everything. But here, if one rebuilds all the packages from source, libbar1 will get linked against libc7 and things will be ok. The transition period would consist of the time between when a new libguileX comes out, and when all the "add-on libs" that depend on the old version of libguile are rebuilt against the new version of guile. Actually it's only the add-on libs that are actually used by some other app or lib that also uses some other add-on lib that cause trouble, but we can't predict that. A bit of pain while guile add-ons are revved is one thing, but I would really like to avoid pain on guile-using apps, since they'll just stop. guile add-on writers are guile weenies who will not give up so easily. glib's only a good example if you consider it in a broader context. Imagine after glib 2.0 is released, libgnome-vfs has been upgraded to compile against glib 2.0 but libgnome-print has not. Where does this leave evolution when it recompiles (presuming it links against both libs)? This leaves evolution broken, I think. I think the gnome folks may create libgnome-vfs2, so that gnome2 apps can use that, and the older apps can use libgnome-vfs. As an example, orbit2 uses glib 2.0, so when switching from glib 1.2 to glib 2.0, one switches to orbit2. This would be easier if f.i. guile-gtk went under $(prefix)/share/guile/1.6 rather than $(prefix)/share/guile directly. But, I don't think such add-ons are super critical in terms of total pain and worry about guile market share loss. I agree that the problem is not completely solveable. But, I think the real question is What can guile do that minimizes pain to people who write applications using guile, and people that maintains pkgsrc/ports/deb/rpm of such programs and guile itself. (For what it's worth, I have guile 1.6 installed in /usr/projectname for a project I'm working on that uses a guile-gtk GUI to monitor things. This doesn't conflict with /usr/pkg/bin/guile, which is 1.4 for gnome etc., as long as I use the change to look up helper libs at absolute pathnames. But a different prefix isn't ok for NetBSD's pkgsrc, and I bet it's not ok for Debian either.) Greg Troxel <gdt@ir.bbn.com> _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: packaging the add-on libs... 2002-10-10 5:03 packaging the add-on libs Rob Browning 2002-10-10 7:12 ` tomas @ 2002-10-10 12:51 ` Greg Troxel 2002-10-10 15:37 ` Rob Browning 1 sibling, 1 reply; 12+ messages in thread From: Greg Troxel @ 2002-10-10 12:51 UTC (permalink / raw) Cc: guile-devel Putting the guile version in the name makes sense to me, and I'd go so far as to think about making libguile.a be libguile16.a. Given how many things link to guile 1.4 (e.g. gnomeish stuff), it seems critical to make it easy for package systems to install both guile14 and guile16, and that therefore these must have totally disjoint sets of files, with the possible exception of the guile-config link to guile16-config. A nice guile.m4 to find the 'right' version might also be an exception. IIRC {Free,Net}BSD took this approach when packaging glib, so that glib10 and glib12 could coexist. Now, glib-2.0 (which is to glib 1.2 as guile 1.6 is to 1.4, more or less, I think) has a different name: > l /usr/pkg/lib/libglib* -rw-r--r-- 1 root wheel 497840 Jun 20 15:27 /usr/pkg/lib/libglib-2.0.a -rwxr-xr-x 1 root wheel 774 Jun 20 15:27 /usr/pkg/lib/libglib-2.0.la lrwxr-xr-x 1 root wheel 18 Jun 20 15:27 /usr/pkg/lib/libglib-2.0.so -> libglib-2.0.so.0.1 lrwxr-xr-x 1 root wheel 18 Jun 20 15:27 /usr/pkg/lib/libglib-2.0.so.0 -> libglib-2.0.so.0.1 -rwxr-xr-x 1 root wheel 430869 Jun 20 15:27 /usr/pkg/lib/libglib-2.0.so.0.1 -rw-r--r-- 1 root wheel 183560 Nov 21 2001 /usr/pkg/lib/libglib.a -rwxr-xr-x 1 root wheel 733 Nov 21 2001 /usr/pkg/lib/libglib.la lrwxr-xr-x 1 root wheel 16 Nov 21 2001 /usr/pkg/lib/libglib.so -> libglib.so.13.10 lrwxr-xr-x 1 root wheel 16 Nov 21 2001 /usr/pkg/lib/libglib.so.13 -> libglib.so.13.10 -rwxr-xr-x 1 root wheel 151468 Nov 21 2001 /usr/pkg/lib/libglib.so.13.10 It's kludgy for packagers to add this, and causes extra differences, where if guile itself does it, it is just the way the world is and will be the same everywhere. On the other hand, putting all the dependent libs in $(prefix)/libexec/guile/1.6/ also seems quite sensible to me, as long as they are dlopened with an absolute path and no one is asked to put this in LD_LIBRARY_PATH :-) Following the path of the P crowd seems somewhat sensible, especially if there hasn't been large amounts of pain from that approach. But this still leaves the issue of libguile.a, which currently would collide on my NetBSD system if I had 1.4 and 1.6 in the same prefix. It is necessary to have both installed for compiling with, not just running, since people need to be able to build programs from source that link against older guile versions. Greg Troxel <gdt@ir.bbn.com> _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: packaging the add-on libs... 2002-10-10 12:51 ` Greg Troxel @ 2002-10-10 15:37 ` Rob Browning 0 siblings, 0 replies; 12+ messages in thread From: Rob Browning @ 2002-10-10 15:37 UTC (permalink / raw) Cc: guile-devel Greg Troxel <gdt@ir.bbn.com> writes: > Putting the guile version in the name makes sense to me, and I'd go > so far as to think about making libguile.a be libguile16.a. (we'd probably want to use libguile12, not 16, unless you're talking about some future version, or unless we're planning to change guile's actual version number to track libguile's) I've been wondering about this myself -- you'd also have libguile12.so which would make it much easier to install multiple libguileX-dev packages, but we'd still have to do something about the headers. Perhaps /usr/include/guile/1.6. > Given how many things link to guile 1.4 (e.g. gnomeish stuff), it > seems critical to make it easy for package systems to install both > guile14 and guile16, and that therefore these must have totally > disjoint sets of files, with the possible exception of the > guile-config link to guile16-config. A nice guile.m4 to find the > 'right' version might also be an exception. I'm planning to allow something like this on debian systems, though as mentioned I haven't decided on all the details yet, with whether or not we can/should allow multiple development version packages to be installed at the same time being an open question. > It's kludgy for packagers to add this, and causes extra differences, > where if guile itself does it, it is just the way the world is and > will be the same everywhere. I'm inclined to agree here. > On the other hand, putting all the dependent libs in > $(prefix)/libexec/guile/1.6/ also seems quite sensible to me, as long > as they are dlopened with an absolute path and no one is asked to put > this in LD_LIBRARY_PATH :-) Following the path of the P crowd seems > somewhat sensible, especially if there hasn't been large amounts of > pain from that approach. This still won't work if people are supposed to be allowed to link directly against these libs, and they are (at least not without -rpath, etc.) -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2002-10-14 11:34 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-10-10 5:03 packaging the add-on libs Rob Browning 2002-10-10 7:12 ` tomas 2002-10-10 15:22 ` Rob Browning 2002-10-11 9:41 ` tomas 2002-10-11 15:59 ` Rob Browning 2002-10-14 11:34 ` tomas 2002-10-11 16:14 ` Rob Browning 2002-10-11 17:10 ` Greg Troxel 2002-10-11 18:26 ` Rob Browning 2002-10-11 20:37 ` Greg Troxel 2002-10-10 12:51 ` Greg Troxel 2002-10-10 15:37 ` Rob Browning
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).