Re: specifying readline location & ignoring libdir...?

[Chet Ramey]

On 11/16/16 2:26 PM, L A Walsh wrote:

>>>    1) How is the location for readline-7.0 specified?
>>>     
>>
>> Using the --with-installed-readline argument to `configure'. 
> ---
>    I note that readline puts the .a files in the top level, but
> the ".so" files are in a subdir, "shlib".  Which location
> would be needed by the 'installed-readline' option?

You're missing the point.  The `installed-readline' option handles the
post-installation case, not the look-in-the-build-directory case.  Think
of it as the location you specify to refer to where `make install' puts
the libraries.

> 
>    But maybe more importantly, why does the link step ignore
> the value of libdir used by configure (specified by the --libdir=<dir>
> argument).

Because that's not what `libdir' is for.  Look at the GNU coding standards:

https://www.gnu.org/prep/standards/standards.html#Makefile-Conventions

under the section "Variables for Installation Directories", where we find

‘libdir’

    The directory for object files and libraries of object code. Do not
install executables here, they probably ought to go in $(libexecdir)
instead. The value of libdir should normally be /usr/local/lb, but write
it as $(exec_prefix)/lib. (If you are using Autoconf, write it as
‘@libdir@’.)

> 
>    Also,  does the link step look for the version it wants, or
> does it leave the version unspecified.  I'm not sure of the syntax
> for ".a", but for .so's it would look like:

None of this is relevant.  The linking step uses -lreadline and relies
on the linker to choose which version of the library it finds in its
library search path.

There is an autoconf test that discovers the readline version, and code in
the bash configure to make sure it's new enough.  The code in the devel
branch works better than the code in bash-4.4-release.  If there is enough
demand, I will put out a patch, but I get the feeling that this option
isn't widely used, and that distributions that choose to use the installed
version of readline use other mechanisms to ensure compatibility.


> If a prog only needs major version 7, it would look
> for ".so.7" first, then try the less specific ".so"
> file next.

This is what the linker does, and it varies from system to system.

> 
> 
>> RL_LIBDIR
>> and
>> RL_LIBSRC
>>
>> which are the build and source directories for your local version of
>> readline, respectively.
>>   
> ---
>    That might be the best workaround in the near term,
> but fixing the build procedure to use the dir specified by
> the --libdir arg to configure would really be better in the
> long term...

As above, the libdir argument doesn't do that. It's a variable to
control installation, not where to look for libraries during build
There are other ways to do that, and I gave you one.

Just because something doesn't work the way you think it should is
not evidence of something that needs "fixing".


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/