Issue31

Title Re: GNU build: shared libraries ending up in lib not lib64
Priority bug Status chatting
Superseder Nosy List baagaard, leif
Assigned To leif Topics Build

Created on 2006-05-04.16:43:37 by leif, last changed 2007-03-22.21:16:30 by leif.

Files
File name Uploaded Type Edit
unnamed leif, 2007-03-22.21:15:02 text/html
Messages
msg300 (view) Author: leif Date: 2007-03-22.21:15:02
As it turns out, 'libexec_LTLIBRARIES' is invalid. It seems that, under 
the GNU build system, libraries will not land in 'lib64' without 
deliberate effort on the user's part. See correspondence with Brad, below.

-------- Original Message --------
Subject: 	Re: GNU build: shared libraries ending up in lib not lib64
Date: 	Mon, 26 Feb 2007 15:02:08 -0800
From: 	Leif Strand <leif@geodynamics.org>
To: 	Brad Aagaard <baagaard@usgs.gov>
References: 	<200702261351.11524.baagaard@usgs.gov> 
<45E3577C.60302@geodynamics.org> <200702261404.50395.baagaard@usgs.gov>

Brad,

OK, sorry -- scratch that.

I think this is an Autoconf issue, but Googling around, I can't find any 
indication that others think it is an issue. The best I can offer at 
present is to override the default by hand:

    ./configure --prefix=$FOO --libdir=$FOO/lib64

The libXXX convention has always been perplexing to me. There was 
already the prefix/exec_prefix convention... so now, as I understand it, 
there are two different conventions for supporting multiple 
architectures on the same filesystem.

--Leif

Brad Aagaard wrote:

>Leif-
>
>When I try
>
>libexec_LTLIBRARIES = libspatialdata.la
>
>I get
>
>'libexecdir' is not a legitimate directory for `LTLIBRARIES'
>
>Brad
>
>
>On Monday 26 February 2007, you wrote:
>  
>
>>Brad,
>>
>>I think it's simply a matter of changing 'lib' to 'libexec':
>>
>>    lib_LTLIBRARIES = libpylith.la
>>
>>becomes
>>
>>    libexec_LTLIBRARIES = libpylith.la
>>
>>--Leif
>>
>>Brad Aagaard wrote:
>>    
>>
>>>Leif-
>>>
>>>My spatialdata and pylith shared libraries are installed into lib and not
>>>lib64. Do you know how to correct this? It isn't a problem yet, but it
>>>annoys me.
>>>
>>>Brad
>>>      
>>>
>
>
>  
>
msg67 (view) Author: leif Date: 2006-05-04.16:43:37
This is essentially sequel to issue11.

Brad Aagaard pointed out to me that our libs are still going to 'lib' instead of
'lib64' on AMD x86-64.  This would seem to be the wrong place:

[lstrand@login-2-3 lstrand]$ file /usr/lib/libcups.so.2
/usr/lib/libcups.so.2: ELF 32-bit LSB shared object, Intel 80386, version 1
(SYSV), stripped
[lstrand@login-2-3 lstrand]$ file /usr/lib64/libcups.so.2
/usr/lib64/libcups.so.2: ELF 64-bit LSB shared object, AMD x86-64, version 1
(SYSV), stripped
[lstrand@login-2-3 lstrand]$

(The build process makes 64-bit binaries, at least by default.  Hmmm... I wonder
if there is a way to change this with 'configure'?)

This affects all GNU-build projects (Pythia, CitcomS, PyLith, Ellipsis3D, ...) 
All uses of lib_LTLIBRARIES (and the like) need to become libexec_LTLIBRARIES.
History
Date User Action Args
2007-03-22 21:16:30leifsetnosy: + baagaard
2007-03-22 21:15:04leifsetfiles: + unnamed
status: unread -> chatting
messages: + msg300
title: 'libdir' vs. 'libexecdir' -> Re: GNU build: shared libraries ending up in lib not lib64
2006-05-04 16:43:37leifcreate