[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Missing and out-of-date information in guile.1, the Guile man page
From: |
Ken Raeburn |
Subject: |
Re: Missing and out-of-date information in guile.1, the Guile man page |
Date: |
Wed, 19 Jan 2011 14:50:29 -0500 |
On Jan 16, 2011, at 14:38, Mark Harig wrote:
>>
>> I'd say too OS-dependent; or more to do with how guile should be
>> properly installed, than how to use it once it is installed.
>>
>> But on the other hand, I might be misunderstanding what you had in
> mind;
>> if you'd like to propose some specific text...
>>
>
> If a user has followed the instructions in the section "Obtaining and
> Installing Guile", and installed guile in the "/usr/local/" directory
> tree, then, on systems that use the dynamic linker/loader ld.so or
> ld-linux.so*, the instructions in the section "Linking Guile into
> Programs" will fail because the new program 'simple-guile' will not be
> able to locate the shared library 'libguile-2.0.so*'.
I think the right answer for that is not to tell people that they have to set
environment variables in order to run Guile programs, but to tell developers
how to link programs properly so that they find the library at run time. This
tends to be somewhat platform-dependent, but often arguments like "-R" or
"-rpath" are needed; libtool should just Do The Right Thing, if it's used. I'm
less familiar with pkg-config, but expect it should be have similarly. In
fact, the man page for pkg-config on my system (Mac OS X with MacPorts
installed) says the "--libs-only-L" option "prints the -L/-R part" of the link
options, which suggests to me that pkg-config is indeed supposed to be printing
options to set the run-time load path. If it's not doing that for you, then we
should figure out why not.
In short, don't document how to work around a bug, if you can just fix the bug.
:-)
Ken
Re: Missing and out-of-date information in guile.1, the Guile man page, Andy Wingo, 2011/01/24