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
>>>
>>>
>
>
>
>
|