make error - libpqdll.def No such file or directory

p.s. --

On 1/17/2016 3:24 PM, Igal @ Lucee.org wrote:

When running make I encounter the following error:

gcc.exe: error: libpqdll.def: No such file or directory
/home/Admin/sources/postgresql-9.5.0/src/Makefile.shlib:393: recipe
for target 'libpq.dll' failed
make[3]: *** [libpq.dll] Error 1
make[3]: Leaving directory
'/home/Admin/builds/postgresql-9.5.0/src/interfaces/libpq'
Makefile:17: recipe for target 'all-libpq-recurse' failed
make[2]: *** [all-libpq-recurse] Error 2
make[2]: Leaving directory
'/home/Admin/builds/postgresql-9.5.0/src/interfaces'
Makefile:34: recipe for target 'all-interfaces-recurse' failed
make[1]: *** [all-interfaces-recurse] Error 2
make[1]: Leaving directory '/home/Admin/builds/postgresql-9.5.0/src'
GNUmakefile:11: recipe for target 'all-src-recurse' failed
make: *** [all-src-recurse] Error 2

But /home/Admin/builds/postgresql-9.5.0/src/interfaces/libpq does
contain the file libpqdll.def

The file /home/Admin/sources/postgresql-9.5.0/src/Makefile.shlib exists
as well.

It's hard for me to decipher which file is reporting the error and which
file is not found.

Any feedback would be greatly appreciated, thanks!

On 1/17/2016 8:17 PM, Igal @ Lucee.org wrote:

On 1/17/2016 3:24 PM, Igal @ Lucee.org wrote:

When running make I encounter the following error:

gcc.exe: error: libpqdll.def: No such file or directory
/home/Admin/sources/postgresql-9.5.0/src/Makefile.shlib:393: recipe
for target 'libpq.dll' failed
make[3]: *** [libpq.dll] Error 1
make[3]: Leaving directory
'/home/Admin/builds/postgresql-9.5.0/src/interfaces/libpq'
Makefile:17: recipe for target 'all-libpq-recurse' failed
make[2]: *** [all-libpq-recurse] Error 2
make[2]: Leaving directory
'/home/Admin/builds/postgresql-9.5.0/src/interfaces'
Makefile:34: recipe for target 'all-interfaces-recurse' failed
make[1]: *** [all-interfaces-recurse] Error 2
make[1]: Leaving directory '/home/Admin/builds/postgresql-9.5.0/src'
GNUmakefile:11: recipe for target 'all-src-recurse' failed
make: *** [all-src-recurse] Error 2

But /home/Admin/builds/postgresql-9.5.0/src/interfaces/libpq does
contain the file libpqdll.def

The file /home/Admin/sources/postgresql-9.5.0/src/Makefile.shlib
exists as well.

It's hard for me to decipher which file is reporting the error and
which file is not found.

Any feedback would be greatly appreciated, thanks!

So when I try to run `make` I still get that error. Please note that I
am doing a VPATH build (the build in a separate directory from the
downloaded sources), which might play a role here:

x86_64-w64-mingw32-gcc.exe: error: libpqdll.def: No such file or directory
make[3]: *** [libpq.dll] Error 1
make[2]: *** [all-libpq-recurse] Error 2
make[1]: *** [all-interfaces-recurse] Error 2
make: *** [all-src-recurse] Error 2

I found a script that builds postgresql via MinGW-w64, and in it the
author specifically creates symlinks to libpqdll.def
https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-postgresql/PKGBUILD#L72
-- excerpt below:

# Make DLL definition file visible during each arch build
ln -s
"${srcdir}/postgresql-$pkgver/src/interfaces/libpq/libpqdll.def"
src/interfaces/libpq/
ln -s
"${srcdir}/postgresql-$pkgver/src/interfaces/ecpg/ecpglib/libecpgdll.def" src/interfaces/ecpg/ecpglib/
ln -s
"${srcdir}/postgresql-$pkgver/src/interfaces/ecpg/pgtypeslib/libpgtypesdll.def"
src/interfaces/ecpg/pgtypeslib/
ln -s
"${srcdir}/postgresql-$pkgver/src/interfaces/ecpg/compatlib/libecpg_compatdll.def"
src/interfaces/ecpg/compatlib/

Why are the symlinks needed to make the definition files visible?

Is this an issue with VPATH builds? It is not mentioned in the docs
where VPATH builds are discussed (section 15.4
http://www.postgresql.org/docs/9.5/static/install-procedure.html )

What is my best solutions?

Thanks!

Igal @ Lucee.org wrote:

So when I try to run `make` I still get that error. Please note that I am
doing a VPATH build (the build in a separate directory from the downloaded
sources), which might play a role here:

x86_64-w64-mingw32-gcc.exe: error: libpqdll.def: No such file or directory
make[3]: *** [libpq.dll] Error 1
make[2]: *** [all-libpq-recurse] Error 2
make[1]: *** [all-interfaces-recurse] Error 2
make: *** [all-src-recurse] Error 2

I too tried mingw compile in VPATH a few days ago, and found that it
behaves in stupid ways -- sometimes it would just loop re-running
configure over and over, and when it (seemingly randomly) stopped doing
that, it failed because of missing errcodes.h or something related.
(When I make- distcleaned and started from scratch, it would work, so I
simply did that.)

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 1/19/2016 10:17 AM, Alvaro Herrera wrote:

Igal @ Lucee.org wrote:

So when I try to run `make` I still get that error. Please note that I am
doing a VPATH build (the build in a separate directory from the downloaded
sources), which might play a role here:

x86_64-w64-mingw32-gcc.exe: error: libpqdll.def: No such file or directory
make[3]: *** [libpq.dll] Error 1
make[2]: *** [all-libpq-recurse] Error 2
make[1]: *** [all-interfaces-recurse] Error 2
make: *** [all-src-recurse] Error 2

I too tried mingw compile in VPATH a few days ago, and found that it
behaves in stupid ways -- sometimes it would just loop re-running
configure over and over, and when it (seemingly randomly) stopped doing
that, it failed because of missing errcodes.h or something related.
(When I make- distcleaned and started from scratch, it would work, so I
simply did that.)

Alvaro -- thank you for your reply!

So to clarify (in the hopes that it would allow me to keep some hair on
my head by the end of this process, as I already pulled out most of it
by now)...
your process was as follows?

build-dir$ ~/source-dir/configure --host=x86_64-w64-mingw32
...
build-dir$ make
...
errors
build-dir$ make distclean
...
build-dir$ ~/source-dir/configure --host=x86_64-w64-mingw32
...
build-dir$ make
...

?

Or did you not do a VPATH build the second time?

Did you use any other options?

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 01/19/2016 01:08 PM, Igal @ Lucee.org wrote:

On 1/17/2016 8:17 PM, Igal @ Lucee.org wrote:

On 1/17/2016 3:24 PM, Igal @ Lucee.org wrote:

When running make I encounter the following error:

gcc.exe: error: libpqdll.def: No such file or directory
/home/Admin/sources/postgresql-9.5.0/src/Makefile.shlib:393: recipe
for target 'libpq.dll' failed
make[3]: *** [libpq.dll] Error 1
make[3]: Leaving directory
'/home/Admin/builds/postgresql-9.5.0/src/interfaces/libpq'
Makefile:17: recipe for target 'all-libpq-recurse' failed
make[2]: *** [all-libpq-recurse] Error 2
make[2]: Leaving directory
'/home/Admin/builds/postgresql-9.5.0/src/interfaces'
Makefile:34: recipe for target 'all-interfaces-recurse' failed
make[1]: *** [all-interfaces-recurse] Error 2
make[1]: Leaving directory '/home/Admin/builds/postgresql-9.5.0/src'
GNUmakefile:11: recipe for target 'all-src-recurse' failed
make: *** [all-src-recurse] Error 2

But /home/Admin/builds/postgresql-9.5.0/src/interfaces/libpq does
contain the file libpqdll.def

The file /home/Admin/sources/postgresql-9.5.0/src/Makefile.shlib
exists as well.

It's hard for me to decipher which file is reporting the error and
which file is not found.

Any feedback would be greatly appreciated, thanks!

So when I try to run `make` I still get that error. Please note that
I am doing a VPATH build (the build in a separate directory from the
downloaded sources), which might play a role here:
x86_64-w64-mingw32-gcc.exe: error: libpqdll.def: No such file or directory
make[3]: *** [libpq.dll] Error 1
make[2]: *** [all-libpq-recurse] Error 2
make[1]: *** [all-interfaces-recurse] Error 2
make: *** [all-src-recurse] Error 2
I found a script that builds postgresql via MinGW-w64, and in it the
author specifically creates symlinks to libpqdll.def
https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-postgresql/PKGBUILD#L72
-- excerpt below:

# Make DLL definition file visible during each arch build
ln -s
"${srcdir}/postgresql-$pkgver/src/interfaces/libpq/libpqdll.def"
src/interfaces/libpq/
ln -s
"${srcdir}/postgresql-$pkgver/src/interfaces/ecpg/ecpglib/libecpgdll.def"
src/interfaces/ecpg/ecpglib/
ln -s
"${srcdir}/postgresql-$pkgver/src/interfaces/ecpg/pgtypeslib/libpgtypesdll.def"
src/interfaces/ecpg/pgtypeslib/
ln -s
"${srcdir}/postgresql-$pkgver/src/interfaces/ecpg/compatlib/libecpg_compatdll.def"
src/interfaces/ecpg/compatlib/

Why are the symlinks needed to make the definition files visible?

Is this an issue with VPATH builds? It is not mentioned in the docs
where VPATH builds are discussed (section 15.4
http://www.postgresql.org/docs/9.5/static/install-procedure.html )

jacana does VPATH builds with pretty much this setup all the time. See
for example
<http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=jacana&amp;dt=2016-01-19%2013%3A00%3A09&gt;

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Igal @ Lucee.org wrote:

Alvaro -- thank you for your reply!

So to clarify (in the hopes that it would allow me to keep some hair on my
head by the end of this process, as I already pulled out most of it by
now)...
your process was as follows?

build-dir$ ~/source-dir/configure --host=x86_64-w64-mingw32
...
build-dir$ make
...
errors
build-dir$ make distclean
...
build-dir$ ~/source-dir/configure --host=x86_64-w64-mingw32
...
build-dir$ make
...

?

Yes, probably something like that. I think it failed the first time
because there was a bug (the one I introduced in a967613911f7), then
probably changed to src/backend and ran compiles there which probably
worked fine, leading to commit fa838b555f90. I might or might not have
removed the complete build dir instead of "make distclean"; not sure
TBH. As I recall, I tried a couple of builds after I pushed the fix
commit and couldn't get them to run at all. But since I saw in
buildfarm that other mingw builds were working, I lost interest. Then I
deleted the mingw build tree and didn't get back to retrying.

TBH the only reason I mingled with mingw at all is that nobody seems
interested in fixing Win32 issues, and this patch had been lingering for
far too long.

Or did you not do a VPATH build the second time?

I never build in the source tree, so this is pretty unlikely.

Did you use any other options?

None.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Andrew Dunstan wrote:

jacana does VPATH builds with pretty much this setup all the time. See for
example <http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=jacana&amp;dt=2016-01-19%2013%3A00%3A09&gt;

Yes, it builds a tree *once*, then deletes the result, and the next BF
run uses a completely new build directory. So any issues resulting from
re-building an existing tree are never seen.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 01/19/2016 02:01 PM, Alvaro Herrera wrote:

Andrew Dunstan wrote:

jacana does VPATH builds with pretty much this setup all the time. See for
example <http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=jacana&amp;dt=2016-01-19%2013%3A00%3A09&gt;

Yes, it builds a tree *once*, then deletes the result, and the next BF
run uses a completely new build directory. So any issues resulting from
re-building an existing tree are never seen.

Oh. odd. I don't think I've seen that even when developing on Windows
(e.g. parallel pg_restore). Maybe I always did that in-tree.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 1/19/2016 10:58 AM, Alvaro Herrera wrote:

Yes, probably something like that. I think it failed the first time
because there was a bug (the one I introduced in a967613911f7), then
probably changed to src/backend and ran compiles there which probably
worked fine, leading to commit fa838b555f90. I might or might not have
removed the complete build dir instead of "make distclean"; not sure
TBH. As I recall, I tried a couple of builds after I pushed the fix
commit and couldn't get them to run at all. But since I saw in
buildfarm that other mingw builds were working, I lost interest. Then
I deleted the mingw build tree and didn't get back to retrying. TBH
the only reason I mingled with mingw at all is that nobody seems
interested in fixing Win32 issues, and this patch had been lingering
for far too long.

Ok, so your comments here made me think that maybe there is a bug
somewhere in the distribution that I was using ( from
http://www.postgresql.org/ftp/source/v9.5.0/ ), so I went ahead and
cloned the git repo and used the sources from there.

I am happy to announce that I was finally able to build and run
PostgreSQL on MinGW-w64, but it only worked with the sources from the
git repo, and not with the official downloads from the links above. I'm
not sure if there is a bug there that was resolved, or if it is packaged
differently, but I was using the official download because I read in
several places that it should be easier to build from that distribution
as opposed to the git repo.

Thank you for your help,

Igal

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Igal @ Lucee.org wrote:

On 1/19/2016 10:58 AM, Alvaro Herrera wrote:

Yes, probably something like that. I think it failed the first time
because there was a bug (the one I introduced in a967613911f7), then
probably changed to src/backend and ran compiles there which probably
worked fine, leading to commit fa838b555f90. I might or might not have
removed the complete build dir instead of "make distclean"; not sure TBH.
As I recall, I tried a couple of builds after I pushed the fix commit and
couldn't get them to run at all. But since I saw in buildfarm that other
mingw builds were working, I lost interest. Then I deleted the mingw build
tree and didn't get back to retrying. TBH the only reason I mingled with
mingw at all is that nobody seems interested in fixing Win32 issues, and
this patch had been lingering for far too long.

Ok, so your comments here made me think that maybe there is a bug somewhere
in the distribution that I was using ( from
http://www.postgresql.org/ftp/source/v9.5.0/ ), so I went ahead and cloned
the git repo and used the sources from there.

I am happy to announce that I was finally able to build and run PostgreSQL
on MinGW-w64, but it only worked with the sources from the git repo, and not
with the official downloads from the links above. I'm not sure if there is
a bug there that was resolved, or if it is packaged differently, but I was
using the official download because I read in several places that it should
be easier to build from that distribution as opposed to the git repo.

Hmm, I guess this makes sense. A tree obtained from a shipped tarball
has "make distprep" already run, which means it contains a bunch more
files than clean Git workspace -- probably errcodes.h among them, for
example. This smells like a makefile bug of some kind to me.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers