Обсуждение: 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

On 1/17/2016 8:17 PM, Igal @ Lucee.org wrote:<br /><blockquote cite="mid:569C6740.2060407@lucee.org" type="cite"> On
1/17/20163:24 PM, Igal @ Lucee.org wrote:<br /><blockquote cite="mid:569C22C0.70404@lucee.org" type="cite"> When
runningmake I encounter the following error:<br /><br /><tt>gcc.exe: error: libpqdll.def: No such file or directory<br
/>/home/Admin/sources/postgresql-9.5.0/src/Makefile.shlib:393: recipe for target 'libpq.dll' failed<br /> make[3]: ***
[libpq.dll]Error 1<br /> make[3]: Leaving directory '/home/Admin/builds/postgresql-9.5.0/src/interfaces/libpq'<br />
Makefile:17:recipe for target 'all-libpq-recurse' failed<br /> make[2]: *** [all-libpq-recurse] Error 2<br /> make[2]:
Leavingdirectory '/home/Admin/builds/postgresql-9.5.0/src/interfaces'<br /> Makefile:34: recipe for target
'all-interfaces-recurse'failed<br /> make[1]: *** [all-interfaces-recurse] Error 2<br /> make[1]: Leaving directory
'/home/Admin/builds/postgresql-9.5.0/src'<br/> GNUmakefile:11: recipe for target 'all-src-recurse' failed<br /> make:
***[all-src-recurse] Error 2</tt><br /><br /> But /home/Admin/builds/postgresql-9.5.0/src/interfaces/libpq does contain
thefile libpqdll.def<br /></blockquote><br /> The file <tt>/home/Admin/sources/postgresql-9.5.0/src/Makefile.shlib</tt>
existsas well.<br /><br /> It's hard for me to decipher which file is reporting the error and which file is not
found.<br/><br /> Any feedback would be greatly appreciated, thanks!<br /></blockquote> So when I try to run `make` I
stillget 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:<br /><pre style="color: rgb(0, 0, 0); font-style: normal; font-variant: normal;
font-weight:normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px;
text-transform:none; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; white-space:
pre-wrap;">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</pre> I found a script that builds postgresql via MinGW-w64, and in it the author
specificallycreates symlinks to libpqdll.def<br /><a class="moz-txt-link-freetext"
href="https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-postgresql/PKGBUILD#L72">https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-postgresql/PKGBUILD#L72</a>
--excerpt below:<br /><br /><tt>  # Make DLL definition file visible during each arch build</tt><tt><br /></tt><tt>  ln
-s"${srcdir}/postgresql-$pkgver/src/interfaces/libpq/libpqdll.def" src/interfaces/libpq/</tt><tt><br /></tt><tt>  ln -s
"${srcdir}/postgresql-$pkgver/src/interfaces/ecpg/ecpglib/libecpgdll.def"src/interfaces/ecpg/ecpglib/</tt><tt><br
/></tt><tt> ln -s "${srcdir}/postgresql-$pkgver/src/interfaces/ecpg/pgtypeslib/libpgtypesdll.def"
src/interfaces/ecpg/pgtypeslib/</tt><tt><br/></tt><tt>  ln -s
"${srcdir}/postgresql-$pkgver/src/interfaces/ecpg/compatlib/libecpg_compatdll.def"
src/interfaces/ecpg/compatlib/</tt><br/><br /> Why are the symlinks needed to make the definition files visible?<br
/><br/> Is this an issue with VPATH builds?  It is not mentioned in the docs where VPATH builds are discussed (section
15.4<a class="moz-txt-link-freetext"
href="http://www.postgresql.org/docs/9.5/static/install-procedure.html">http://www.postgresql.org/docs/9.5/static/install-procedure.html</a>
)<br/><br /> What is my best solutions?<br /><br /> Thanks!<br /><br /><br /> 

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