Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Thu, 6 Nov 2014 18:49:35 +0000 (UTC)
From: "Alexander Shorin (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: <JIRA.12708503.1397563061000.436297.1415299775542@Atlassian.JIRA>
In-Reply-To: <JIRA.12708503.1397563061000@Atlassian.JIRA>
References: <JIRA.12708503.1397563061000@Atlassian.JIRA>
 <JIRA.12708503.1397563061228@arcas>
Subject: [jira] [Resolved] (COUCHDB-2225) configure should fail if system
 cannot generate shared libraries (in LT_INIT)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/COUCHDB-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Shorin resolved COUCHDB-2225.
---------------------------------------
       Resolution: Fixed
    Fix Version/s: 1.7.0

> configure should fail if system cannot generate shared libraries (in LT_INIT)
> -----------------------------------------------------------------------------
>
>                 Key: COUCHDB-2225
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-2225
>             Project: CouchDB
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: Build System
>            Reporter: Michael Marino
>            Priority: Minor
>             Fix For: 1.7.0
>
>
> The LT_INIT autoconf macro checks if the system can build shared libraries, which couch needs:
> {code:title=configure.ac}
> ...
> AC_ENABLE_SHARED                                                           
> AC_DISABLE_STATIC     
> AC_PROG_CC
> LT_INIT([win32-dll])     
> LT_INIT             
> AC_PROG_LN_S   
> ...
> {code}
> The AC_DISABLE/ENABLE_* requests that the system builds shared libraries and not static libraries, but does not enforce it.  It should.  
> An example of a failure mode is the observed configure output on a Synology (linux-based) system: 
> {code}
> ...
> checking whether the gcc linker (/usr/local/x86_64-linux-gnu/x86_64-linux-gnu/x86_64-linux-gnu/bin/ld -m elf_x86_64) supports shared libraries... no
> checking dynamic linker characteristics... GNU/Linux ld.so
> checking how to hardcode library paths into programs... unsupported
> checking whether stripping libraries is possible... no
> checking if libtool supports shared libraries... no
> checking whether to build shared libraries... no
> checking whether to build static libraries... yes
> ...
> {code}
> In this case, gcc returns a broken path to ld, but configure succeeds even though no shared libraries will/can be built.  'make' does fail later, but not in a way that makes the source of the failure obvious:
> {code}
> cp .libs/ejson.so priv/ejson.so
> cp: can't stat '.libs/ejson.so': No such file or directory
> {code}
> which arises because the so files are not built.  In this case, configuration and make succeed when the correct path to ld is given (e.g. ./configure LD=/path/to/ld).  However, generally, configure should die with an appropriate error if the system can not build shared libraries.  
> Solution:
> Change of the above lines in configure.ac:
> {code:title=configure.ac}
> ...
> LT_INIT
> AS_IF([test x"${enable_shared}" = "xno"], [
>   AC_MSG_ERROR([System as configured cannot build shared libraries.])
> ])
> ...
> {code}
> And regeneration of configure.  I'm happy to produce a pull request for this.  


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)