[Gsll-devel] Proposed modification of libgsl locations on linux' (RedHat in particular)
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-filesyste...): "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
Hi Mirko, Debian is also using the same Filesystem Hierarchy Standard (FHS) as RedHat: http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#USRLOCALLOCALHI... So I don't think it is necessary to differentiate between the two distributions with respect to the location of libraries. In fact, it looks like most distributions are using the FHS these days including Ubuntu and SuSE Linux, at least according to Wikipedia: http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard Cheers, Russell On Tue, 2010-04-13 at 10:20 -0400, Mirko Vukovic 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-filesyste...):
"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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
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 On Tue, Apr 13, 2010 at 10:20 AM, Mirko Vukovic <mirko.vukovic@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-filesyste...):
"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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
On Sat, May 22, 2010 at 10:04 PM, Liam Healy <lhealy@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
On Tue, Apr 13, 2010 at 10:20 AM, Mirko Vukovic <mirko.vukovic@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-filesyste...):
"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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
On Mon, May 24, 2010 at 9:27 AM, Mirko Vukovic <mirko.vukovic@gmail.com> wrote:
On Sat, May 22, 2010 at 10:04 PM, Liam Healy <lhealy@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@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-filesyste...):
"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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
participants (3)
-
Liam Healy -
Mirko Vukovic -
Russell Kliese