Re: make error - libpqdll.def No such file or directory

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

Any ideas?

--

Igal Sapir
Lucee Core Developer
Lucee.org <http://lucee.org/>

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!
>
> Any ideas?
>
> --
>
> Igal Sapir
> Lucee Core Developer
> Lucee.org <http://lucee.org/>
>

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

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?

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&dt=2016-01-19%2013%3A00%3A09>

cheers

andrew

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

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&dt=2016-01-19%2013%3A00%3A09>

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

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&dt=2016-01-19%2013%3A00%3A09>
> 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

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

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