[Gsll-devel] Proposed modification of libgsl locations on linux' (RedHat in particular)

[Mirko Vukovic]

On Mon, May 24, 2010 at 9:27 AM, Mirko Vukovic <mirko.vukovic at gmail.com> wrote:
> On Sat, May 22, 2010 at 10:04 PM, Liam Healy <lhealy at common-lisp.net> wrote:
>> Mirko,
>>
>> This looks wrong: /usr/local/lib64/lib.  Are you sure you don't
>> mean /usr/local/lib64?  When I google for that string (with lib64/lib)
>> literally nothing show that path except your email on mail-archive.
>>
>> Liam
>
> When installing gsl 1.14, I specified the installation directory as
>
>> ./configure --prefix=/usr/local/lib64
>
> After the installation, the /usr/local/lib64/ had the following
> directories, all with gsl related stuff
>
> /usr/local/lib64/bin
> /usr/local/lib64/include
> /usr/local/lib64/lib
> /usr/local/lib64/share
>
> Can anyone else confirm this?
>
> Mirko

I guess what I should have done was to set configure as follows:

> mkdir /usr/local/gsl1.14
> ./configure --prefix=/usr/local/gsl1.14
> make install
> ln -s /usr/local/gsl1.14/lib/... /usr/local/lib64

Mirko

>
>>
>> On Tue, Apr 13, 2010 at 10:20 AM, Mirko Vukovic <mirko.vukovic at gmail.com> wrote:
>>> Hello,
>>>
>>> I propose to add the /usr/local/lib and /usr/local/lib64 directories
>>> to the libgsl search path.
>>>
>>> As RedHat states
>>> (http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-filesystem-fhs.html):
>>>
>>> "The /usr/local hierarchy is for use by the system administrator when
>>> installing software locally. It needs to be safe from being
>>> overwritten when the system software is updated. It may be used for
>>> programs and data that are shareable among a group of hosts, but not
>>> found in /usr."
>>>
>>> For example, the `official' RedHat gsl that comes with software
>>> updates from RedHat thas the version 1.10 and lives in /usr/lib64.  I
>>> need to install the latest ones into /usr/local/lib64.
>>>
>>> Here is the modified libgsl definition:
>>>
>>> (cffi:define-foreign-library libgsl
>>>    (:darwin
>>>     (:or "/opt/local/lib/libgsl.dylib" "/sw/lib/libgsl.dylib"
>>>          "/usr/local/lib/libgsl.dylib"))
>>>  (:cygwin (:or "/bin/cyggsl-0.dll"))
>>>  (:unix (:or "/usr/local/lib64/lib/libgsl.so.0"
>>> "/usr/local/lib64/lib/libgsl.so" ;;<--- New
>>>              "/usr/local/lib/libgsl.so.0" "/usr/local/lib/libgsl.so" ;; <--- New
>>>              "/usr/lib/libgsl.so.0" "/usr/lib/libgsl.so"
>>>              "/usr/lib64/libgsl.so.0" "/usr/lib64/libgsl.so"
>>>              ))
>>>  (t (:default "libgsl")))
>>>
>>> Note that I put the most specific case first.  Otherwise the system
>>> libraries get loaded.
>>>
>>> Generalizing this approach to multiple systems (i.e. Debian, RedHat,
>>> others) can result in unmanageable loading rules (I am not familiar
>>> with other linux/unix file system conventions).  In that case, it may
>>> prove useful for the user to set-up a red-hat or debian `feature', and
>>> to customize these for their particular setup.
>>>
>>> Mirko
>>>
>>> _______________________________________________
>>> Gsll-devel mailing list
>>> Gsll-devel at common-lisp.net
>>> http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
>>>
>>
>