Dave Peticolas wrote:
>
> Clark Jones writes:
> > Dave Peticolas wrote:
> > >
> > > Clark Jones writes:
> > > > Developers:
> > [...]
> > > > I would suggest that whoever's the keeper of the "makefile" that's used f
> > or
> > > > the RPM please consider looking to see if you can't chop off the ".4" on
> > > > libguile.so and the ".3" on libreadline.so so that we can use the "generi
> > c"
> > > > softlinks.
> > [...]
> > > The problem is one we're really not supposed to work around. As I
> > > understand it, the idea behind changing the library major version is
> > > that it is *supposed* to break backwards compatibility, because the
> > > library developers have decided that the api has changed enough that
> > > backwards compatibility cannot be supported.
> > >
> > > In the guile case, it seems that "fooling" the system into using the
> > > new library with a soft link will still work, but in general it's not
> > > something we should be doing automatically.
> >
> > The guile package itself plants soft links for major versions 3, 5, and 6,
> > all pointing to 6.0.0. (The GnuCash problem seems to be arising from the
> > fact that it isn't planting one for version 4. To me, this suggests that
> > major version 4 had some major muck-up, and shouldn't be used at all...)
> >
> > > The correct way to solve this problem would be to build a binary package
> > > on a mandrake system, and have mandrake users use that instead. Ditto for
> > > SuSE, etc.
> >
> > Unnecisarily linking to a specific version will still be a problem. If there
> > is a good reason for tying to a specific version of a given library, then
> > it seems to me that the particular version of the library in question should
> > be copied to the application (in this case, GnuCash's) download area, to
> > assure its continued availability. I have yet to find sources for guile 4,
> > let alone an RPM (but since it works fine with 6, I've quit trying, and never
> > did try too hard -- I probably could have if I'd wanted to badly enough).
>
> Library version 4 is from guile-1.3.0. Linking to a specific major
> version is how linking is done -- I'm not aware of any other way to do
> it. Providing multiple versions in a single package is up to the guile
> package, not gnucash.
>
> As long as we build our packages on standard distributions, then
> there won't be a problem, unless a user has upgraded their libraries
> to incompatible versions. But if you're doing that, then you're on
> your own anyway.
>
> dave
This is not technically true, at least not in the RH world. I know SuSe
screws up their RPM (how the *hell* do you know which version you are
getting until after you download it!!). Mandrake should be similar to,
if not still exactly like, RedHat, as far as building/installing RPMs
are concerned.
A couple of caveats: by default, RPM requires >= libraries it compiles
against, unless a specific library requirement is written into the RPM
via a Requires: line in the RPM spec file. Rpm looks in it's database
to see if there are any packages that provide libraries >= the ones it
was compiled against. If the rpm package for said libraries fails to
update the database correctly, or if it contains incorrect "Provides"
information, then other packages which require said libraries will fail
to install at the dependency checking stage.
All that being said, let me speak to the person requesting a chopping of
the .3 and .4 on the guile and readline libraries. I'm not sure how
your system is set up, but on mine, both of those are already
softlinks. If libguile.so.4 changes, on upgrade, to libguile.so.5, then
you will need to install compatibility libraries, most likely, or
recompile you programs which use guile. That situation is the exact
same situation we faced when moving from libc5 to libc6 (glibc). You
should either stick with the current libraries, or recompile everythign
against the new libraries. <shrug> such is progress.
I think the team has done a great job, with the RH packages, at least.
I'm still waiting, however, on an answer to "how did you get the g-wrap
rpm to build with all the libgwrapguile libraries" in it? The g-wrap
tarball doesn't build hide-nor-hair of those libraries, nor does the
src.rpm. Has that situation been remedied yet (Dave's forwarded my
questions about that to someone official down the road, but I've not
heard anything but silence from that direction).
Thanks, guys
--
Matthew Vanecek
Visit my Website at http://mysite.directlink.net/linuxguy
For answers type: perl -e 'print
$i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
*****************************************************************
For 93 million miles, there is nothing between the sun and my shadow
except me. I'm always getting in the way of something...
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
