* guile-2.0.11 installation on system with 2.0.5
@ 2014-09-13 12:52 Federico Beffa
2014-09-14 1:17 ` Vernon Oberholzer
` (2 more replies)
0 siblings, 3 replies; 23+ messages in thread
From: Federico Beffa @ 2014-09-13 12:52 UTC (permalink / raw
To: guile-user
Hi,
I'm on Debian 7.6 with guile-2.0.5 installed. I would like to install
a newer version of guile. Therefore I downloaded 2.0.11 and installed
in /usr/local with
./configure
make
sudo make install
Everything appeared to be fine. However, with my surprise, when I
started the newly installed guile with
$ /usr/local/bin/guile
I was greeted with
GNU Guile 2.0.5-deb+1-3
Copyright (C) 1995-2012 Free Software Foundation, Inc.
...
which correspond to the version provided by the Debian package.
Am I doing something wrong? Is it possible to have two guile versions
on the same system?
Regards,
Fede
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-2.0.11 installation on system with 2.0.5
2014-09-13 12:52 Federico Beffa
@ 2014-09-14 1:17 ` Vernon Oberholzer
2014-09-14 14:32 ` Neil Jerram
2014-09-14 14:33 ` Ludovic Courtès
2 siblings, 0 replies; 23+ messages in thread
From: Vernon Oberholzer @ 2014-09-14 1:17 UTC (permalink / raw
To: Federico Beffa; +Cc: guile-user
[-- Attachment #1: Type: text/plain, Size: 1487 bytes --]
Hi Federico,
That is odd, on my Debian "wheezy" system, the debian packaged guile is a
symbolic link /usr/bin/guile to
/etc/alternatives/guile, which in turn is a symbolic link to
/usr/bin/guile-2.0 . What returns from the command "which guile" on your
system ?
The method I have tended to use, which may not be the ideal way, but works
for my purposes is
to create a dir, /usr/local/guile2 and then
./configure --prefix=/usr/local/guile2
make && make install
I like this method, as when further releases come out, for example 2.0.12,
I can simply create
another dir, for example, /usr/local/guile2012
I have geiser with emacs installed, so in my .emacs I have
(setq geiser-guile-binary "/usr/local/guile2/bin/guile")
Kind Regards,
Vernon Oberholzer
On Sat, Sep 13, 2014 at 12:52 PM, Federico Beffa <beffa@ieee.org> wrote:
> Hi,
>
> I'm on Debian 7.6 with guile-2.0.5 installed. I would like to install
> a newer version of guile. Therefore I downloaded 2.0.11 and installed
> in /usr/local with
>
> ./configure
> make
> sudo make install
>
> Everything appeared to be fine. However, with my surprise, when I
> started the newly installed guile with
>
> $ /usr/local/bin/guile
>
> I was greeted with
>
> GNU Guile 2.0.5-deb+1-3
> Copyright (C) 1995-2012 Free Software Foundation, Inc.
> ...
>
> which correspond to the version provided by the Debian package.
>
> Am I doing something wrong? Is it possible to have two guile versions
> on the same system?
>
> Regards,
> Fede
>
>
[-- Attachment #2: Type: text/html, Size: 2150 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-2.0.11 installation on system with 2.0.5
@ 2014-09-14 8:02 Federico Beffa
0 siblings, 0 replies; 23+ messages in thread
From: Federico Beffa @ 2014-09-14 8:02 UTC (permalink / raw
To: vo2521; +Cc: guile-user
> Hi Federico,
> That is odd, on my Debian "wheezy" system, the debian packaged guile
> is a symbolic link /usr/bin/guile to
> /etc/alternatives/guile, which in turn is a symbolic link to
> /usr/bin/guile-2.0 . What returns from the command "which guile" on
> your system ?
With the locally installed guile 2.0.11 `which guile' reports
/usr/local/bin/guile. I've now uninstalled it (`make uninstall').
Without the local copy of guile I see the same as you: /usr/bin/guile is
a symbolic link to /etc/alternatives/guile which in turn is a symlink to
/usr/bin/guile-2.0.
Regards,
Fede
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-2.0.11 installation on system with 2.0.5
2014-09-13 12:52 Federico Beffa
2014-09-14 1:17 ` Vernon Oberholzer
@ 2014-09-14 14:32 ` Neil Jerram
2014-09-14 14:33 ` Ludovic Courtès
2 siblings, 0 replies; 23+ messages in thread
From: Neil Jerram @ 2014-09-14 14:32 UTC (permalink / raw
To: Federico Beffa; +Cc: guile-user
Federico Beffa <beffa@ieee.org> writes:
> Hi,
>
> I'm on Debian 7.6 with guile-2.0.5 installed. I would like to install
> a newer version of guile. Therefore I downloaded 2.0.11 and installed
> in /usr/local with
>
> ./configure
> make
> sudo make install
>
> Everything appeared to be fine. However, with my surprise, when I
> started the newly installed guile with
>
> $ /usr/local/bin/guile
>
> I was greeted with
>
> GNU Guile 2.0.5-deb+1-3
> Copyright (C) 1995-2012 Free Software Foundation, Inc.
> ...
>
> which correspond to the version provided by the Debian package.
>
> Am I doing something wrong? Is it possible to have two guile versions
> on the same system?
This is just a guess, but what happens if you do this:
$ LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/guile
Regards,
Neil
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-2.0.11 installation on system with 2.0.5
2014-09-13 12:52 Federico Beffa
2014-09-14 1:17 ` Vernon Oberholzer
2014-09-14 14:32 ` Neil Jerram
@ 2014-09-14 14:33 ` Ludovic Courtès
2 siblings, 0 replies; 23+ messages in thread
From: Ludovic Courtès @ 2014-09-14 14:33 UTC (permalink / raw
To: Federico Beffa; +Cc: guile-user
Federico Beffa <beffa@ieee.org> skribis:
> Everything appeared to be fine. However, with my surprise, when I
> started the newly installed guile with
>
> $ /usr/local/bin/guile
>
> I was greeted with
>
> GNU Guile 2.0.5-deb+1-3
> Copyright (C) 1995-2012 Free Software Foundation, Inc.
> ...
It may be that, while /usr/local/bin/guile is indeed from the new
version, it ends up loading .scm and .go files from the old version.
You could check that by running:
strace -o log /usr/local/bin/guile --version
and grepping for .scm and .go files in ‘log’.
That could happen, for instance, if there’s a GUILE_LOAD_PATH or
GUILE_LOAD_COMPILED_PATH environment variable pointing to
/usr/share/guile/...
> Am I doing something wrong? Is it possible to have two guile versions
> on the same system?
Yes.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-2.0.11 installation on system with 2.0.5
@ 2014-09-14 15:37 Federico Beffa
2014-09-15 1:16 ` mhw
0 siblings, 1 reply; 23+ messages in thread
From: Federico Beffa @ 2014-09-14 15:37 UTC (permalink / raw
To: neil; +Cc: guile-user
Neil Jerram <neil@ossau.homelinux.net> writes:
>
> This is just a guess, but what happens if you do this:
>
> $ LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/guile
>
> Regards,
> Neil
With this it works!
I notice that there is an /etc/ld.so.cache file. Do I somehow need to update
it?
Thanks,
Fede
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-2.0.11 installation on system with 2.0.5
@ 2014-09-14 15:42 Federico Beffa
2014-09-14 23:07 ` Chris Vine
2014-09-15 7:50 ` Ludovic Courtès
0 siblings, 2 replies; 23+ messages in thread
From: Federico Beffa @ 2014-09-14 15:42 UTC (permalink / raw
To: ludo; +Cc: guile-user
ludo@gnu.org (Ludovic Courtès) writes:
> It may be that, while /usr/local/bin/guile is indeed from the new
> version, it ends up loading .scm and .go files from the old version.
>
> You could check that by running:
>
> strace -o log /usr/local/bin/guile --version
>
> and grepping for .scm and .go files in ‘log’.
>
> That could happen, for instance, if there’s a GUILE_LOAD_PATH or
> GUILE_LOAD_COMPILED_PATH environment variable pointing to
> /usr/share/guile/...
>
Yes, that's what happens. I can see libraries from /usr/share and
/usr/lib/guile being used.
I do not have any GUILE_LOAD_* environment variable defined. However, I
see in the "log" file generated as suggested that the /etc/ld.so.cache
file gets opened. Should I need somehow to update it?
Thanks,
Fede
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-2.0.11 installation on system with 2.0.5
2014-09-14 15:42 Federico Beffa
@ 2014-09-14 23:07 ` Chris Vine
2014-09-15 7:50 ` Ludovic Courtès
1 sibling, 0 replies; 23+ messages in thread
From: Chris Vine @ 2014-09-14 23:07 UTC (permalink / raw
To: guile-user
On Sun, 14 Sep 2014 17:42:58 +0200
Federico Beffa <beffa@ieee.org> wrote:
> ludo@gnu.org (Ludovic Courtès) writes:
>
> > It may be that, while /usr/local/bin/guile is indeed from the new
> > version, it ends up loading .scm and .go files from the old version.
> >
> > You could check that by running:
> >
> > strace -o log /usr/local/bin/guile --version
> >
> > and grepping for .scm and .go files in ‘log’.
> >
> > That could happen, for instance, if there’s a GUILE_LOAD_PATH or
> > GUILE_LOAD_COMPILED_PATH environment variable pointing to
> > /usr/share/guile/...
> >
>
> Yes, that's what happens. I can see libraries from /usr/share and
> /usr/lib/guile being used.
>
> I do not have any GUILE_LOAD_* environment variable defined. However,
> I see in the "log" file generated as suggested that
> the /etc/ld.so.cache file gets opened. Should I need somehow to
> update it?
If it is any use to you, to run guile-1.8 on a guile-2.0 system (which
I rarely do) I set the following environmental variables in the script
which starts guile and/or which compiles or loads anything which uses
the 1.8 version of libguile.
export LD_LIBRARY_PATH=/opt/guile18/lib
export PATH=/opt/guile18/bin:$PATH
export GUILE_LOAD_PATH=/opt/guile18/share/guile/1.8:/opt/guile18/share/guile/site:/opt/guile18/share/guile
export PKG_CONFIG_PATH=/opt/guile18/lib/pkgconfig:$PKG_CONFIG_PATH
export LDFLAGS=-L/opt/guile18/lib:$LDFLAGS
For guile-2.0 you will probably also want to set GUILE_LOAD_COMPILED_PATH.
However, generally this is not a very sensible approach if you are upgrading
the same minor version of guile. It would be better to build guile-2.0.11
using the debian build scripts and replace guile-2.0.5 entirely.
Chris
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-2.0.11 installation on system with 2.0.5
2014-09-14 15:37 guile-2.0.11 installation on system with 2.0.5 Federico Beffa
@ 2014-09-15 1:16 ` mhw
2014-09-15 9:49 ` Neil Jerram
2014-09-15 10:27 ` Chris Vine
0 siblings, 2 replies; 23+ messages in thread
From: mhw @ 2014-09-15 1:16 UTC (permalink / raw
To: Federico Beffa; +Cc: guile-user
Federico Beffa <beffa@ieee.org> writes:
> Neil Jerram <neil@ossau.homelinux.net> writes:
>
>>
>> This is just a guess, but what happens if you do this:
>>
>> $ LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/guile
>>
>> Regards,
>> Neil
>
> With this it works!
>
> I notice that there is an /etc/ld.so.cache file. Do I somehow need to update
> it?
Yes, you update it by running "ldconfig" as root. This needs to be done
when installing libraries outside of your package manager, not only for
Guile, but for essentially all packages containing libraries.
Mark
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-2.0.11 installation on system with 2.0.5
2014-09-14 15:42 Federico Beffa
2014-09-14 23:07 ` Chris Vine
@ 2014-09-15 7:50 ` Ludovic Courtès
1 sibling, 0 replies; 23+ messages in thread
From: Ludovic Courtès @ 2014-09-15 7:50 UTC (permalink / raw
To: Federico Beffa; +Cc: guile-user
Federico Beffa <beffa@ieee.org> skribis:
> ludo@gnu.org (Ludovic Courtès) writes:
>
>> It may be that, while /usr/local/bin/guile is indeed from the new
>> version, it ends up loading .scm and .go files from the old version.
>>
>> You could check that by running:
>>
>> strace -o log /usr/local/bin/guile --version
>>
>> and grepping for .scm and .go files in ‘log’.
>>
>> That could happen, for instance, if there’s a GUILE_LOAD_PATH or
>> GUILE_LOAD_COMPILED_PATH environment variable pointing to
>> /usr/share/guile/...
>>
>
> Yes, that's what happens. I can see libraries from /usr/share and
> /usr/lib/guile being used.
>
> I do not have any GUILE_LOAD_* environment variable defined. However, I
> see in the "log" file generated as suggested that the /etc/ld.so.cache
> file gets opened. Should I need somehow to update it?
You probably need to run ‘ldconfig’.
HTH,
Ludo’.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-2.0.11 installation on system with 2.0.5
2014-09-15 1:16 ` mhw
@ 2014-09-15 9:49 ` Neil Jerram
2014-09-15 10:22 ` Federico Beffa
2014-09-15 14:15 ` Mark H Weaver
2014-09-15 10:27 ` Chris Vine
1 sibling, 2 replies; 23+ messages in thread
From: Neil Jerram @ 2014-09-15 9:49 UTC (permalink / raw
To: mhw; +Cc: guile-user, Federico Beffa
On 2014-09-15 02:16, mhw@netris.org wrote:
> Federico Beffa <beffa@ieee.org> writes:
>
>> Neil Jerram <neil@ossau.homelinux.net> writes:
>>
>>>
>>> This is just a guess, but what happens if you do this:
>>>
>>> $ LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/guile
>>>
>>> Regards,
>>> Neil
>>
>> With this it works!
>>
>> I notice that there is an /etc/ld.so.cache file. Do I somehow need to
>> update
>> it?
>
> Yes, you update it by running "ldconfig" as root. This needs to be
> done
> when installing libraries outside of your package manager, not only for
> Guile, but for essentially all packages containing libraries.
I agree that this will allow /usr/local/bin/guile to load
/usr/local/lib/libguile*.
However, won't it also cause /usr/bin/guile (2.0.5) to load
/usr/local/lib/libguile* (2.0.11) ? If not, what is the mechanism that
tells /usr/bin/guile (2.0.5) to load /usr/lib/libguile* (2.0.5) instead
of /usr/local/lib/libguile* (2.0.11) ?
Thanks,
Neil
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-2.0.11 installation on system with 2.0.5
2014-09-15 9:49 ` Neil Jerram
@ 2014-09-15 10:22 ` Federico Beffa
2014-09-15 10:44 ` Chris Vine
2014-09-15 14:15 ` Mark H Weaver
1 sibling, 1 reply; 23+ messages in thread
From: Federico Beffa @ 2014-09-15 10:22 UTC (permalink / raw
To: Neil Jerram; +Cc: guile-user
On Mon, Sep 15, 2014 at 11:49 AM, Neil Jerram <neil@ossau.homelinux.net> wrote:
> On 2014-09-15 02:16, mhw@netris.org wrote:
>>
>> Federico Beffa <beffa@ieee.org> writes:
>>
>>> Neil Jerram <neil@ossau.homelinux.net> writes:
>>>
>>>>
>>>> This is just a guess, but what happens if you do this:
>>>>
>>>> $ LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/guile
>>>>
>>>> Regards,
>>>> Neil
>>>
>>>
>>> With this it works!
>>>
>>> I notice that there is an /etc/ld.so.cache file. Do I somehow need to
>>> update
>>> it?
>>
>>
>> Yes, you update it by running "ldconfig" as root. This needs to be done
>> when installing libraries outside of your package manager, not only for
>> Guile, but for essentially all packages containing libraries.
>
>
> I agree that this will allow /usr/local/bin/guile to load
> /usr/local/lib/libguile*.
>
> However, won't it also cause /usr/bin/guile (2.0.5) to load
> /usr/local/lib/libguile* (2.0.11) ? If not, what is the mechanism that
> tells /usr/bin/guile (2.0.5) to load /usr/lib/libguile* (2.0.5) instead of
> /usr/local/lib/libguile* (2.0.11) ?
>
> Thanks,
> Neil
>
yes, that's what I've found out by running ldconfig. Both versions now
show version 2.0.11 in the startup message.
Regards,
Fede
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-2.0.11 installation on system with 2.0.5
2014-09-15 1:16 ` mhw
2014-09-15 9:49 ` Neil Jerram
@ 2014-09-15 10:27 ` Chris Vine
1 sibling, 0 replies; 23+ messages in thread
From: Chris Vine @ 2014-09-15 10:27 UTC (permalink / raw
To: guile-user
On Sun, 14 Sep 2014 21:16:39 -0400
mhw@netris.org wrote:
> Federico Beffa <beffa@ieee.org> writes:
>
> > Neil Jerram <neil@ossau.homelinux.net> writes:
> >
> >>
> >> This is just a guess, but what happens if you do this:
> >>
> >> $ LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/guile
> >>
> >> Regards,
> >> Neil
> >
> > With this it works!
> >
> > I notice that there is an /etc/ld.so.cache file. Do I somehow need
> > to update it?
>
> Yes, you update it by running "ldconfig" as root. This needs to be
> done when installing libraries outside of your package manager, not
> only for Guile, but for essentially all packages containing libraries.
I would not recommend doing that where the OP has two _binary
compatible_ versions of the same library in different prefixes (as he
appears to have), otherwise the one which will be found and linked in
will depend on the dynamic linker's look-up order from
reading /etc/ld.so.conf. This could be the old micro version where in
a given case the OP in fact wants the new one, or conversely the new
micro version where he in fact wants the old one.
Presumably in the general case he wants the micro version supplied by
the distribution's package manager to be linked in, otherwise he would
simply have replaced that one with the (binary compatible) newer
version of the same library. Presumably also he wants the updated
version which he has installed to be linked in instead only when
specially called. If that is right, he is much better off putting his
updated version in a directory which is _not_ specified
in /etc/ld.so.conf, and invoking it on the occasions when he does not
want the general case to apply by setting the LD_LIBRARY_PATH
environmental variable for that invocation. Then he is guaranteed to
have the correct version loaded in.
Chris
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-2.0.11 installation on system with 2.0.5
2014-09-15 10:22 ` Federico Beffa
@ 2014-09-15 10:44 ` Chris Vine
0 siblings, 0 replies; 23+ messages in thread
From: Chris Vine @ 2014-09-15 10:44 UTC (permalink / raw
To: guile-user
On Mon, 15 Sep 2014 12:22:27 +0200
Federico Beffa <beffa@ieee.org> wrote:
> On Mon, Sep 15, 2014 at 11:49 AM, Neil Jerram
[snip]
> > However, won't it also cause /usr/bin/guile (2.0.5) to load
> > /usr/local/lib/libguile* (2.0.11) ? If not, what is the mechanism
> > that tells /usr/bin/guile (2.0.5) to load /usr/lib/libguile*
> > (2.0.5) instead of /usr/local/lib/libguile* (2.0.11) ?
> >
> > Thanks,
> > Neil
> >
>
> yes, that's what I've found out by running ldconfig. Both versions now
> show version 2.0.11 in the startup message.
I would strongly advise you not to have two binary compatible versions
of any given library on your system at the same time, unless you really
know what you are doing. Otherwise you are at the mercy of the look-up
order of the dynamic linker. It is much better simply to upgrade your
system to guile-2.0.11 using your distribution's package manager. Since
guile maintains binary compatibility between micro versions, you should
be absolutely fine (and you can always back out if not).
However if you insist on doing what you are doing, see my separate
posting and use environmental variables to achieve what you want.
Chris
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-2.0.11 installation on system with 2.0.5
@ 2014-09-15 11:46 Federico Beffa
2014-09-15 15:00 ` Chris Vine
0 siblings, 1 reply; 23+ messages in thread
From: Federico Beffa @ 2014-09-15 11:46 UTC (permalink / raw
To: chris, guile-user
Chris Vine <chris@cvine.freeserve.co.uk> writes:
> On Sun, 14 Sep 2014 21:16:39 -0400
> mhw@netris.org wrote:
>> Federico Beffa <beffa@ieee.org> writes:
>>
>> > Neil Jerram <neil@ossau.homelinux.net> writes:
>> >
>> >>
>> >> This is just a guess, but what happens if you do this:
>> >>
>> >> $ LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/guile
>> >>
>> >> Regards,
>> >> Neil
>> >
>> > With this it works!
>> >
>> > I notice that there is an /etc/ld.so.cache file. Do I somehow need
>> > to update it?
>>
>> Yes, you update it by running "ldconfig" as root. This needs to be
>> done when installing libraries outside of your package manager, not
>> only for Guile, but for essentially all packages containing libraries.
>
> I would not recommend doing that where the OP has two _binary
> compatible_ versions of the same library in different prefixes (as he
> appears to have), otherwise the one which will be found and linked in
> will depend on the dynamic linker's look-up order from
> reading /etc/ld.so.conf. This could be the old micro version where in
> a given case the OP in fact wants the new one, or conversely the new
> micro version where he in fact wants the old one.
>
> Presumably in the general case he wants the micro version supplied by
> the distribution's package manager to be linked in, otherwise he would
> simply have replaced that one with the (binary compatible) newer
> version of the same library. Presumably also he wants the updated
> version which he has installed to be linked in instead only when
> specially called. If that is right, he is much better off putting his
> updated version in a directory which is _not_ specified
> in /etc/ld.so.conf, and invoking it on the occasions when he does not
> want the general case to apply by setting the LD_LIBRARY_PATH
> environmental variable for that invocation. Then he is guaranteed to
> have the correct version loaded in.
>
> Chris
Your guess is correct: The distribution that I'm using (Debian wheezy)
ships 2.0.5 as the newest guile version and I need to keep it to satisfy
dependencies of other distribution supplied packages. However, I would
like to experiment with a newer version of guile. I will then follow
your advice and install it in a different directory.
Thanks for all the explanations!
Regards,
Fede
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-2.0.11 installation on system with 2.0.5
2014-09-15 9:49 ` Neil Jerram
2014-09-15 10:22 ` Federico Beffa
@ 2014-09-15 14:15 ` Mark H Weaver
1 sibling, 0 replies; 23+ messages in thread
From: Mark H Weaver @ 2014-09-15 14:15 UTC (permalink / raw
To: Neil Jerram; +Cc: guile-user, Federico Beffa
Neil Jerram <neil@ossau.homelinux.net> writes:
> On 2014-09-15 02:16, mhw@netris.org wrote:
>> Federico Beffa <beffa@ieee.org> writes:
>>
>>> I notice that there is an /etc/ld.so.cache file. Do I somehow need
>>> to update
>>> it?
>>
>> Yes, you update it by running "ldconfig" as root. This needs to be
>> done
>> when installing libraries outside of your package manager, not only for
>> Guile, but for essentially all packages containing libraries.
>
> I agree that this will allow /usr/local/bin/guile to load
> /usr/local/lib/libguile*.
>
> However, won't it also cause /usr/bin/guile (2.0.5) to load
> /usr/local/lib/libguile* (2.0.11) ?
True, but I don't see why anyone would want to run 2.0.5 anymore. It
has lots of bugs and other problems that are fixed in 2.0.11, so that's
probably a good thing :)
> If not, what is the mechanism
> that tells /usr/bin/guile (2.0.5) to load /usr/lib/libguile* (2.0.5)
> instead of /usr/local/lib/libguile* (2.0.11) ?
This is not a guile-specific issue. Any time you want to use two
different versions of the same shared library, you need to rely on some
other mechanism.
If you really want to preserve your ability to run the old buggy 2.0.5
libguile, then first of all you need to avoid installing 2.0.11 in a
directory that's in /etc/ld.so.conf (or /etc/ld.so.conf.d), because even
if you avoid running "ldconfig" yourself, your package manager will run
it the next time you install a library package. So, you'd have to
install 2.0.11 to a different prefix.
Then you need a way for your new PREFIX/guile to find its shared library
in a non-standard place, and for that you'd best use rpaths. See
<https://en.wikipedia.org/wiki/Rpath_%28linking%29>, but one way is to
make sure that LD_RUN_PATH is set to PREFIX/lib at the time that the
'guile' executable is linked.
Note that in GNU Guix <http://gnu.org/s/guix>, rpaths are always used
and this issue wouldn't have arisen.
Regards,
Mark
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-2.0.11 installation on system with 2.0.5
2014-09-15 11:46 Federico Beffa
@ 2014-09-15 15:00 ` Chris Vine
2014-09-16 16:26 ` Mark H Weaver
0 siblings, 1 reply; 23+ messages in thread
From: Chris Vine @ 2014-09-15 15:00 UTC (permalink / raw
To: guile-user
On Mon, 15 Sep 2014 13:46:07 +0200
Federico Beffa <beffa@ieee.org> wrote:
[snip]
> Your guess is correct: The distribution that I'm using (Debian wheezy)
> ships 2.0.5 as the newest guile version and I need to keep it to
> satisfy dependencies of other distribution supplied packages.
> However, I would like to experiment with a newer version of guile. I
> will then follow your advice and install it in a different directory.
Surely dependency requirements would be satisfied by a later library
version with the same so name? I should read up the documentation on
dpkg.
But quite honestly, if you want to experiment with newer software don't
use an archaic distribution such as debian stable, which is out of date
even when first released.
Chris
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-2.0.11 installation on system with 2.0.5
@ 2014-09-15 16:46 Federico Beffa
2014-09-15 17:33 ` David Pirotte
0 siblings, 1 reply; 23+ messages in thread
From: Federico Beffa @ 2014-09-15 16:46 UTC (permalink / raw
To: chris, guile-user
Chris Vine <chris@cvine.freeserve.co.uk> writes:
> On Mon, 15 Sep 2014 13:46:07 +0200
> Federico Beffa <beffa@ieee.org> wrote:
> [snip]
>> Your guess is correct: The distribution that I'm using (Debian wheezy)
>> ships 2.0.5 as the newest guile version and I need to keep it to
>> satisfy dependencies of other distribution supplied packages.
>> However, I would like to experiment with a newer version of guile. I
>> will then follow your advice and install it in a different directory.
>
> Surely dependency requirements would be satisfied by a later library
> version with the same so name? I should read up the documentation on
> dpkg.
>
As far as I inderstand the Debian package manager mantains a package
database. This is the place where it looks for installed packages. So,
if I have a newer version of guile which is not installed through the
package manager, the package manager will not know about it.
Regards,
Fede
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-2.0.11 installation on system with 2.0.5
2014-09-15 16:46 Federico Beffa
@ 2014-09-15 17:33 ` David Pirotte
0 siblings, 0 replies; 23+ messages in thread
From: David Pirotte @ 2014-09-15 17:33 UTC (permalink / raw
To: Federico Beffa; +Cc: guile-user
[-- Attachment #1: Type: text/plain, Size: 1202 bytes --]
Hello,
> As far as I inderstand the Debian package manager mantains a package
> database. This is the place where it looks for installed packages. So,
> if I have a newer version of guile which is not installed through the
> package manager, the package manager will not know about it.
even if you are locked in a debian stable, you can, and you should in the case of
guile really, install packages from testing, unstable and even experimental [which
is not recommended unless you know what you are doing of course].
So:
update your /etc/apt/sources.list, add a line with testing source
update you /etc/preferences
Package: *
Pin: release a=stable
Pin-Priority: 800
Package: guile
Pin: release a=testing
Pin-Priority: 600
aptitude update
aptitude
search for the guile-2.0 package aptitude entry
press enter [Menu: Package -> information]
select and install the testing version [2.0.11+1-1 as of today]
with that setting, aptitude|debian future updates will track and offer you to update
the installed guile-2.0 testing package, while keeping everything else on stable...
there are doc about that, duckduckgo for it...
Cheers,
David
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 173 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-2.0.11 installation on system with 2.0.5
@ 2014-09-16 11:09 Federico Beffa
2014-09-16 13:13 ` Federico Beffa
0 siblings, 1 reply; 23+ messages in thread
From: Federico Beffa @ 2014-09-16 11:09 UTC (permalink / raw
To: david, guile-user
David Pirotte <david@altosw.be> writes:
> Hello,
>
>> As far as I inderstand the Debian package manager mantains a package
>> database. This is the place where it looks for installed packages. So,
>> if I have a newer version of guile which is not installed through the
>> package manager, the package manager will not know about it.
>
> even if you are locked in a debian stable, you can, and you should in the case of
> guile really, install packages from testing, unstable and even experimental [which
> is not recommended unless you know what you are doing of course].
>
> So:
>
> update your /etc/apt/sources.list, add a line with testing source
> update you /etc/preferences
>
> Package: *
> Pin: release a=stable
> Pin-Priority: 800
>
> Package: guile
> Pin: release a=testing
> Pin-Priority: 600
>
> aptitude update
> aptitude
> search for the guile-2.0 package aptitude entry
> press enter [Menu: Package -> information]
> select and install the testing version [2.0.11+1-1 as of today]
>
> with that setting, aptitude|debian future updates will track and offer you to update
> the installed guile-2.0 testing package, while keeping everything else on stable...
> there are doc about that, duckduckgo for it...
>
You convinced me that I should be fine using guile from testing.
I've added the following lines in sources.list:
deb http://ftp.ch.debian.org/debian/ testing main
deb-src http://ftp.ch.debian.org/debian/ testing main
created /etc/apt/preferences.d/00-stable containing:
Package: *
Pin: release a=stable
Pin-Priority: 800
and created /etc/apt/preferences.d/20-guile containing:
Package: guile
Pin: release a=testing
Pin-Priority: 600
Now, before installing guile from testing, I wanted to check if I still
get no updatable packages as a moment before doing the change:
aptitude update
aptitude full-upgrade
This tells me that the package libxnvctrl0 can be update. If I remove
the testing entry from sources.list, then I get no updates. So, something
is coming in from testing.
Am I doing something wrong?
Regards,
Fede
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-2.0.11 installation on system with 2.0.5
2014-09-16 11:09 Federico Beffa
@ 2014-09-16 13:13 ` Federico Beffa
2014-09-16 18:16 ` David Pirotte
0 siblings, 1 reply; 23+ messages in thread
From: Federico Beffa @ 2014-09-16 13:13 UTC (permalink / raw
To: david, guile-user
On Tue, Sep 16, 2014 at 1:09 PM, Federico Beffa <beffa@ieee.org> wrote:
> David Pirotte <david@altosw.be> writes:
>
>> Hello,
>>
>>> As far as I inderstand the Debian package manager mantains a package
>>> database. This is the place where it looks for installed packages. So,
>>> if I have a newer version of guile which is not installed through the
>>> package manager, the package manager will not know about it.
>>
>> even if you are locked in a debian stable, you can, and you should in the case of
>> guile really, install packages from testing, unstable and even experimental [which
>> is not recommended unless you know what you are doing of course].
>>
>> So:
>>
>> update your /etc/apt/sources.list, add a line with testing source
>> update you /etc/preferences
>>
>> Package: *
>> Pin: release a=stable
>> Pin-Priority: 800
>>
>> Package: guile
>> Pin: release a=testing
>> Pin-Priority: 600
>>
>> aptitude update
>> aptitude
>> search for the guile-2.0 package aptitude entry
>> press enter [Menu: Package -> information]
>> select and install the testing version [2.0.11+1-1 as of today]
>>
>> with that setting, aptitude|debian future updates will track and offer you to update
>> the installed guile-2.0 testing package, while keeping everything else on stable...
>> there are doc about that, duckduckgo for it...
>>
>
> You convinced me that I should be fine using guile from testing.
>
> I've added the following lines in sources.list:
>
> deb http://ftp.ch.debian.org/debian/ testing main
> deb-src http://ftp.ch.debian.org/debian/ testing main
>
> created /etc/apt/preferences.d/00-stable containing:
>
> Package: *
> Pin: release a=stable
> Pin-Priority: 800
>
> and created /etc/apt/preferences.d/20-guile containing:
>
> Package: guile
> Pin: release a=testing
> Pin-Priority: 600
>
> Now, before installing guile from testing, I wanted to check if I still
> get no updatable packages as a moment before doing the change:
>
> aptitude update
> aptitude full-upgrade
>
> This tells me that the package libxnvctrl0 can be update. If I remove
> the testing entry from sources.list, then I get no updates. So, something
> is coming in from testing.
>
> Am I doing something wrong?
>
> Regards,
> Fede
OK, I've found out by using "apt-cache policy package-name": I need to
lower the default priorities of packages from testing other than guile
with
Package: *
Pin: release o=Debian
Pin-Priority: 10
Now I do not get other packages with "aptitude full-upgrade", but if I
pull in guile-2.0 from testing it wants to change several other
libraries:
$ sudo aptitude -t testing full-upgrade guile-2.0
The following NEW packages will be installed:
libffi6{a}
The following packages will be upgraded:
guile-2.0 guile-2.0-libs libc6 libgc1c2 libgssapi-krb5-2
libk5crypto3 libkeyutils1
libkrb5-3 libkrb5support0 libtirpc1 locales nfs-common
12 packages upgraded, 1 newly installed, 0 to remove and 1353 not upgraded.
Need to get 12.1 MB of archives. After unpacking 2,553 kB will be used.
The following packages have unmet dependencies:
krb5-user : Depends: libkrb5-3 (= 1.10.1+dfsg-5+deb7u2) but
1.12.1+dfsg-9 is to be installed.
libgc-dev : Depends: libgc1c2 (= 1:7.1-9.1) but 1:7.2d-6.3 is to be installed.
libc6-i386 : Depends: libc6 (= 2.13-38+deb7u4) but 2.19-11 is to be installed.
guile-2.0-dev : Depends: guile-2.0 (= 2.0.5+1-3) but 2.0.11+1-1 is to
be installed.
libc6-dev : Depends: libc6 (= 2.13-38+deb7u4) but 2.19-11 is to be installed.
libc-dev-bin : Depends: libc6 (< 2.14) but 2.19-11 is to be installed.
I think I will just install guile 2.0.11 "manually".
Thanks for all the help!
Fede
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-2.0.11 installation on system with 2.0.5
2014-09-15 15:00 ` Chris Vine
@ 2014-09-16 16:26 ` Mark H Weaver
0 siblings, 0 replies; 23+ messages in thread
From: Mark H Weaver @ 2014-09-16 16:26 UTC (permalink / raw
To: Chris Vine; +Cc: guile-user
Chris Vine <chris@cvine.freeserve.co.uk> writes:
> But quite honestly, if you want to experiment with newer software don't
> use an archaic distribution such as debian stable, which is out of date
> even when first released.
Umm, I think it's quite reasonable to run a distribution of older
software that has gone through a long testing period and works well
together, and then to compile more recent versions of selected packages
of particular interest.
In my experience, every time I've run a more cutting-edge distro, I
inevitably end up hitting bugs in software I don't care about when I'm
just trying to get something else done, leaving me less time to work on
the packages I choose to focus on. YMMV, of course.
Mark
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-2.0.11 installation on system with 2.0.5
2014-09-16 13:13 ` Federico Beffa
@ 2014-09-16 18:16 ` David Pirotte
0 siblings, 0 replies; 23+ messages in thread
From: David Pirotte @ 2014-09-16 18:16 UTC (permalink / raw
To: Federico Beffa; +Cc: guile-user
[-- Attachment #1: Type: text/plain, Size: 2200 bytes --]
Hello,
> ...
> OK, I've found out by using "apt-cache policy package-name": I need to
> lower the default priorities of packages from testing other than guile
> with
>
> Package: *
> Pin: release o=Debian
> Pin-Priority: 10
good to know, tx!
> Now I do not get other packages with "aptitude full-upgrade", but if I
> pull in guile-2.0 from testing it wants to change several other
> libraries:
yes, this is to be expected indeed, as guile-2.0-libs, in testing, depends on
libgc1c2 >= 7.2d, which triggers a series of dependency updates.
i am actually _very_ surprised that this would not be the case when manually
installing guile-2.0.11: I thought configure would not let you install unless ....
note also that guile-2.0-dev is not required, not sure it is the 'full-upgrade'
terribly scary beast that triggered that?
> $ sudo aptitude -t testing full-upgrade guile-2.0
> The following NEW packages will be installed:
> libffi6{a}
> The following packages will be upgraded:
> guile-2.0 guile-2.0-libs libc6 libgc1c2 libgssapi-krb5-2
> libk5crypto3 libkeyutils1
> libkrb5-3 libkrb5support0 libtirpc1 locales nfs-common
> 12 packages upgraded, 1 newly installed, 0 to remove and 1353 not upgraded.
> Need to get 12.1 MB of archives. After unpacking 2,553 kB will be used.
> The following packages have unmet dependencies:
> krb5-user : Depends: libkrb5-3 (= 1.10.1+dfsg-5+deb7u2) but
> 1.12.1+dfsg-9 is to be installed.
> libgc-dev : Depends: libgc1c2 (= 1:7.1-9.1) but 1:7.2d-6.3 is to be installed.
> libc6-i386 : Depends: libc6 (= 2.13-38+deb7u4) but 2.19-11 is to be installed.
> guile-2.0-dev : Depends: guile-2.0 (= 2.0.5+1-3) but 2.0.11+1-1 is to
> be installed.
> libc6-dev : Depends: libc6 (= 2.13-38+deb7u4) but 2.19-11 is to be installed.
> libc-dev-bin : Depends: libc6 (< 2.14) but 2.19-11 is to be installed.
>
> I think I will just install guile 2.0.11 "manually".
It should request you to update libgc1c2 as well, and actually constraints might even
be stronger [when the tarball is >=, in version, to the 1 used by debian pkg
maintainer]?
Hum, mark, ludovic, am I wrong here?
Cheers,
David
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 173 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2014-09-16 18:16 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-09-14 15:37 guile-2.0.11 installation on system with 2.0.5 Federico Beffa
2014-09-15 1:16 ` mhw
2014-09-15 9:49 ` Neil Jerram
2014-09-15 10:22 ` Federico Beffa
2014-09-15 10:44 ` Chris Vine
2014-09-15 14:15 ` Mark H Weaver
2014-09-15 10:27 ` Chris Vine
-- strict thread matches above, loose matches on Subject: below --
2014-09-16 11:09 Federico Beffa
2014-09-16 13:13 ` Federico Beffa
2014-09-16 18:16 ` David Pirotte
2014-09-15 16:46 Federico Beffa
2014-09-15 17:33 ` David Pirotte
2014-09-15 11:46 Federico Beffa
2014-09-15 15:00 ` Chris Vine
2014-09-16 16:26 ` Mark H Weaver
2014-09-14 15:42 Federico Beffa
2014-09-14 23:07 ` Chris Vine
2014-09-15 7:50 ` Ludovic Courtès
2014-09-14 8:02 Federico Beffa
2014-09-13 12:52 Federico Beffa
2014-09-14 1:17 ` Vernon Oberholzer
2014-09-14 14:32 ` Neil Jerram
2014-09-14 14:33 ` Ludovic Courtès
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).