Re: GCC error and libmpfr.so.4 not found

From: Jimmy Yih <jyih(at)pivotal(dot)io>
To: Asma Riyaz <asmariyaz23(at)gmail(dot)com>
Cc: Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: GCC error and libmpfr.so.4 not found
Date: 2015-06-11 19:18:27
Message-ID: CAOMx_OAR0=7Ynf0cD4_4R4CcRcKa4MS42cFvv1aAnFZJWVcb0A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hey Asma,

Did you check the linkage with ldd? For example on my blank RHEL 6.5 AWS
VM using gcc 4.4.7:

[jyih(at)test1 ~]$ ldd /usr/libexec/gcc/x86_64-redhat-linux/4.4.4/cc1
linux-vdso.so.1 => (0x00007fff9b9ff000)
libmpfr.so.1 => /usr/lib64/libmpfr.so.1 (0x00000033b8400000)
libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x00000033b8000000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003c1e400000)
libc.so.6 => /lib64/libc.so.6 (0x0000003c1e800000)
/lib64/ld-linux-x86-64.so.2 (0x0000003c1e000000)

Most likely you should have an empty/broken libmpfr.so linkage. You can
play around with LD_LIBRARY_PATH like so:
## create another libmpfr.so link in a different directory for example
[jyih(at)test1 ~]$ ls -al /usr/lib64/libmpfr*
lrwxrwxrwx. 1 root root 16 Jun 7 2014 /usr/lib64/libmpfr.so.1 ->
libmpfr.so.1.2.0
-rwxr-xr-x. 1 root root 318408 Jun 23 2010 /usr/lib64/libmpfr.so.1.2.0
[jyih(at)test1 ~]$ ln -s /usr/lib64/libmpfr.so.1.2.0 /tmp/libmpfr.so.1

## show that LD_LIBRARY_PATH is empty and then add new paths
[jyih(at)test1 ~]$ echo $LD_LIBRARY_PATH

[jyih(at)test1 ~]$ export LD_LIBRARY_PATH=/tmp:$LD_LIBRARY_PATH

## ldd shows new linking
[jyih(at)test1 ~]$ ldd /usr/libexec/gcc/x86_64-redhat-linux/4.4.4/cc1
linux-vdso.so.1 => (0x00007fff06dff000)
libmpfr.so.1 => /tmp/libmpfr.so.1 (0x00000033b8400000)
libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x00000033b8000000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003c1e400000)
libc.so.6 => /lib64/libc.so.6 (0x0000003c1e800000)
/lib64/ld-linux-x86-64.so.2 (0x0000003c1e000000)

Hope that helps!

- Jimmy

On Thu, Jun 11, 2015 at 11:44 AM, Asma Riyaz <asmariyaz23(at)gmail(dot)com> wrote:

> Hi Jimmy,
>
> Here is what I did upon your suggestion;
>
> in bashrc:-
>
> LD_LIBRARY_PATH=/seq/annotation/bio_tools/BOOST/boost_1_46_1/lib
>
> LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/seq/regev_genome_portal/lib
>
> sourced it and then exceuted /.configure as below:
>
> ./configure --prefix=/../../DATABASE/postgres
>
> I get the same error log as before.
>
> Asma
>
>
>
>
>
> On Thu, Jun 11, 2015 at 1:30 PM, Jimmy Yih <jyih(at)pivotal(dot)io> wrote:
>
>> Hey Asma,
>>
>> Have you tried running ldd and checking the library linkage? You might
>> be able to just add the different location to your LD_LIBRARY_PATH as a
>> quick way to get this working.
>>
>> - Jimmy
>>
>> On Thu, Jun 11, 2015 at 7:46 AM, Asma Riyaz <asmariyaz23(at)gmail(dot)com>
>> wrote:
>>
>>> I have a libmpfr.so.4 under a different location, which setting in
>>> configure should I use so that it uses the required library from that
>>> directory?
>>>
>>> I have used ./configure --prefix=/path/directory
>>> LIB=/path/to/libmpfr.so.4 but the config.log still shows that its looking
>>> for libmpfr.so.4 under the shared location as before. Any advice will be
>>> helpful.
>>>
>>> Thank you,
>>> Asma
>>>
>>> On Thu, Jun 11, 2015 at 10:34 AM, Geoff Winkless <pgsqladmin(at)geoff(dot)dj>
>>> wrote:
>>>
>>>> On 11 June 2015 at 15:20, Asma Riyaz <asmariyaz23(at)gmail(dot)com> wrote:
>>>>
>>>>> I have seen an earlier post with gcc errors, however I couldn't figure
>>>>> out what the actual problem here is: is it that libmpfr.so.4 is not found?
>>>>> or gcc needs to be installed fresh?
>>>>>
>>>>
>>>> libmpfr. Unless I've misunderstood, the other errors are simply
>>>> configure trying to work out which compiler you're running - -V and
>>>> -qversion simply aren't valid flags to gcc - so those "error" lines are
>>>> expected result.
>>>>
>>>> Geoff
>>>>
>>>>
>>>
>>
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2015-06-11 19:27:44 Re: database-level lockdown
Previous Message Filipe Pina 2015-06-11 19:06:42 database-level lockdown