Menu ▾ ▴

gmp version checking in autoconf too strict

Help getting started
Juergen Weber
2017-01-05
2017-01-05

  • Juergen Weber

    Juergen Weber - 2017-01-05

    Hi,

    I tried to build gnu-cobol-2.0_rc-2.tar.gz.

    configure fails with

    checking for __gmpz_init in -lgmp... yes
    checking matching GMP version... no (6.1 / 6.0.0)
    configure: error: Unable to use GMP - Please check config.log

    I have gmp-6.1.2, shouldn't that be sufficient?

    Where ist the required version defined?

    Thx,
    Juergen

     

  • Simon Sobisch

    Simon Sobisch - 2017-01-05

    The problem is simple: the library is version 6.1 while the header is 6.0.0 - set CFLAGS during configure to adjust the C search path. See config.log for details what is found.

     

  • Juergen Weber

    Juergen Weber - 2017-01-05

    I had set CFLAGS :

    configure:14133: gcc -std=gnu99 -o conftest -g -O2 -I/projekte/gmp-6.1.2/include -L/projekte/gmp-6.1.2/lib conftest.c -lgmp >&5
    configure:14133: $? = 0
    configure:14133: ./conftest
    configure:14133: $? = 0
    configure:14146: checking matching GMP version
    configure:14155: result: no (6.1 / 6.0.0)
    configure:14157: error: Unable to use GMP - Please check config.log

     

    • Simon Sobisch

      Simon Sobisch - 2017-01-05

      I see. I've changed configure.ac locally, it would now output: 

      configure:14146: checking matching GMP version
configure:14155: result: no (header: 6.1 / library: 6.0.0)
configure:14157: error: Unable to use GMP - Please check config.log

      It seems to link against version 6.1 and runs the 6.0 library.
      So I suggest to do

      export LD_LIBRARY_PATH=projekte/gmp-6.1.2/lib:$LD_LIBRARY_PATH (I assume the libgmp*.so will be found here, if it is in bin change it)
./configure CFLAGS="-I/projekte/gmp-6.1.2/include" LD_FLAGS="-L/projekte/gmp-6.1.2/lib"

      Remark: you will have to set LD_LIBRARY_PATH always when you want to use cobc/cobcrun later (including running the testsuite).

      Simon

       

  • Juergen Weber

    Juergen Weber - 2017-01-05

    No, there is no 6.0 on the machine. And setting LD_LIBRARY_PATH does not change the error.

     

    • Simon Sobisch

      Simon Sobisch - 2017-01-05

      You may upload config.log and I'll recheck - but it's quite likely that the libgmp reports version 6.0.0

      Simon

       

  • Juergen Weber

    Juergen Weber - 2017-01-05

    Actually there is a 6.0 on the machine, but in /lib64
    and without headers, probably as dependencies of another package.
    So I got 6.0.0 sources and used it for CFLAGS
    Now configure is happy.

    Thx, Jürgen

     

  • Brian Tiffin

    Brian Tiffin - 2017-01-05

    I bumped into a similar problem when testing out MPIR last night. I built a --enable-gmpcompat version, installed to /usr/local/ but gcc is stubbornly picking up libgmp.so from a multiarch setup from /usr/lib/x86_64-linux-gnu/. Try as I might, no /etc/ld.so,conf.d configurations seem to effect the search order in a way to scan /usr/local/lib/ for libgmp.so before the 64 bit multi arch. So, now I've got a header file in /usr/local/include for MPIR version 6 and conflicting with a version 5 system install of GMP (along with a proper matching MPIR compat library in /usr/local/lib).

    Exactly the same error condition from ./configure

    configure: Checks for GMP ...
checking gmp.h usability... yes
checking gmp.h presence... yes
checking for gmp.h... yes
checking for __gmpz_init in -lgmp... yes
checking matching GMP version... no (5.1 / 6.1.0)
configure: error: Unable to use GMP - Please check config.log

    Yayy, linkers.

    Not asking for any assistance, just griping.

    The fix for ./configure with a test build of GnuCOBOL was LDFLAGS=-L/usr/local/lib ./configure .... The upside, ./configure works. The downside is that that version of GnuCOBOL now emits -L/usr/local/lib -L/usr/local/lib for every compile (with a /usr/local install). Not harmful, but not optimal.

    I still can't get gcc standalone to recognize the local install unless overriding. And I've done a few laps around the ldconfig tree. Something, somewhere in the multiarch 32bit/64bit setup on this machine is trying to protect me from myself. It will be defeated. :-)

    As an aside. Adding PDCurses and VBISAM to our source tree and tarball adds about 20% to compressed delivery sizes, (which will allow testing against known versions). MPIR adds about 200%, so I say we skip that part and link to it for Windows folk. After decompression, and build, MPIR expands out to a fair huge 50 meg tree here, for what is a final 500K shared library. Quite a bit of baggage, but well tested.

    Go ahead and ignore this post, just griping about ldconfig and multiarch voodoo when it comes to duplicate sonames.

    Cheers,
    Brian

     

Anonymous
Anonymous

Add attachments
Cancel





MongoDB Logo MongoDB