Обсуждение: Could not build from source /usr/bin/ld: cannot find -lpgcommon_shlib
Hi everyone,
I am attempting to build postgres from source with a custom prefix directory and I am faced with the following error:
/usr/bin/ld: cannot find -lpgcommon_shlib
collect2: error: ld returned 1 exit status
collect2: error: ld returned 1 exit status
This is the command that I ran:
# Under /home/dennis/workspace/postgresql
mkdir build_dir
cd build_dir
../configure --enable-cassert --enable-debug --prefix /home/dennis/workspace/pgsql
make
mkdir build_dir
cd build_dir
../configure --enable-cassert --enable-debug --prefix /home/dennis/workspace/pgsql
make
I have attached the extended version of the error I to this email
Thank you for your help.
Dennis Suratna
Вложения
Dennis Suratna <dennis.suratna@gmail.com> writes: > I am attempting to build postgres from source with a custom prefix > directory and I am faced with the following error: > /usr/bin/ld: cannot find -lpgcommon_shlib > collect2: error: ld returned 1 exit status What platform is that, exactly? > This is the command that I ran: > # Under /home/dennis/workspace/postgresql > mkdir build_dir > cd build_dir > ../configure --enable-cassert --enable-debug --prefix > /home/dennis/workspace/pgsql > make Hm ... it's not standard practice for the VPATH build directory to be inside the source directory, I think --- usually the motivation for using VPATH at all is to avoid modifying the source tree. Having said that, I tried such a setup (on a Fedora 30 box) and it built fine for me. I think there might be something wonky about your platform's linker, or maybe make is broken? Is src/common/libpgcommon_shlib.a present in your build tree? regards, tom lane
I am using Ubuntu 18.04.
I tried building in another directory outside of the source directory like so:
```
# Under /home/dennis/workspace
# Source is under /home/dennis/workspace/postgresql
mkdir pgsql_build
cd pgsql_build
../postgresql/configure --enable-cassert --enable-debug --prefix /home/dennis/workspace/pgsql
make
cd pgsql_build
../postgresql/configure --enable-cassert --enable-debug --prefix /home/dennis/workspace/pgsql
make
```
And I got the same error. I have attached the full make output to this reply.
I also ran `find . -name "*libpgcommon_shlib*"` under my build directory, `/home/dennis/workspace/pgsql_build` and I got no result.
This is my make's and ld's version
```
make --version
GNU Make 4.1
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
GNU Make 4.1
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
ld --version
GNU ld (GNU Binutils for Ubuntu) 2.30
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
GNU ld (GNU Binutils for Ubuntu) 2.30
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
```
On Sat, Nov 30, 2019 at 10:31 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Dennis Suratna <dennis.suratna@gmail.com> writes:
> I am attempting to build postgres from source with a custom prefix
> directory and I am faced with the following error:
> /usr/bin/ld: cannot find -lpgcommon_shlib
> collect2: error: ld returned 1 exit status
What platform is that, exactly?
> This is the command that I ran:
> # Under /home/dennis/workspace/postgresql
> mkdir build_dir
> cd build_dir
> ../configure --enable-cassert --enable-debug --prefix
> /home/dennis/workspace/pgsql
> make
Hm ... it's not standard practice for the VPATH build directory to be
inside the source directory, I think --- usually the motivation for
using VPATH at all is to avoid modifying the source tree. Having said
that, I tried such a setup (on a Fedora 30 box) and it built fine for
me. I think there might be something wonky about your platform's
linker, or maybe make is broken? Is src/common/libpgcommon_shlib.a
present in your build tree?
regards, tom lane
Вложения
Dennis Suratna <dennis.suratna@gmail.com> writes: > And I got the same error. I have attached the full make output to this > reply. Well, this is pretty interesting: make -C src all make[1]: Entering directory '/home/dennis/workspace/pgsql_build/src' make -C common all make[2]: Entering directory '/home/dennis/workspace/pgsql_build/src/common' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/home/dennis/workspace/pgsql_build/src/common' "make" didn't find anything to do there. However, digging through the rest of the make log, I find that the backend link went through successfully with /home/dennis/workspace/pgsql_build/../postgresql/src/backend/../../src/common/libpgcommon_srv.a If I'm counting ".."'s correctly, that's pointing at /home/dennis/workspace/postgresql/src/common/libpgcommon_srv.a that is, something in your source tree not your build tree. Extrapolating, I'd guess that you have a partial build laying about in your source tree that includes libpgcommon_shlib.a, and depending on just how a particular Makefile is worded, the VPATH mechanism might find that file when libpgcommon_shlib.a is asked for; it's certainly enough to discourage make itself from building a new copy in the build tree. But the linker doesn't know enough to find that from "-lpgcommon_shlib". In short, you need to clean out your source tree before trying to do a VPATH build. If using git, "git clean -dfx" would do it. Otherwise you might be best advised to blow away the tree and re-extract the tarball you started from. regards, tom lane
Hi Tom,
Just did what you suggested and everything works as expected. You're right, I tried installing from source without specifying the VPATH at first and then realize that I already have postgres installed from package manager and decided to install in a different directory.
So what I ended up doing was I re-cloned the source directory and deleted the build directory and start from scratch.
Thanks for the help.
On Sat, Nov 30, 2019 at 1:22 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Dennis Suratna <dennis.suratna@gmail.com> writes:
> And I got the same error. I have attached the full make output to this
> reply.
Well, this is pretty interesting:
make -C src all
make[1]: Entering directory '/home/dennis/workspace/pgsql_build/src'
make -C common all
make[2]: Entering directory '/home/dennis/workspace/pgsql_build/src/common'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/dennis/workspace/pgsql_build/src/common'
"make" didn't find anything to do there. However, digging through the
rest of the make log, I find that the backend link went through
successfully with
/home/dennis/workspace/pgsql_build/../postgresql/src/backend/../../src/common/libpgcommon_srv.a
If I'm counting ".."'s correctly, that's pointing at
/home/dennis/workspace/postgresql/src/common/libpgcommon_srv.a
that is, something in your source tree not your build tree.
Extrapolating, I'd guess that you have a partial build laying about in
your source tree that includes libpgcommon_shlib.a, and depending on just
how a particular Makefile is worded, the VPATH mechanism might find that
file when libpgcommon_shlib.a is asked for; it's certainly enough to
discourage make itself from building a new copy in the build tree. But
the linker doesn't know enough to find that from "-lpgcommon_shlib".
In short, you need to clean out your source tree before trying to do a
VPATH build. If using git, "git clean -dfx" would do it. Otherwise
you might be best advised to blow away the tree and re-extract the
tarball you started from.
regards, tom lane