On Mon, Jul 11, 2022 at 11:50:59AM +0200, Thomas Schmitt wrote: > Hi, > > tomas@tuxteam.de wrote: > > Still, I insist it should be called <libpq-fe.h> unless you /know/ you > > want to supply your own header file. > > Question is what Igor Korot is trying to compile. > If it is postgres itself or one of its helpers, then libpq-fe.h would > probably be one of the "header files of your own program". If I understood him correctly it's "just" an app using the distro provided libpq. [...] > I wrote: > > > What does this command put out: > > > Yes, we're now all curious :-) > > We should rather look at the original post. ~:o) > > Igor Korot wrote: > > > > igor@debian:~/dbhandler/Debug/libpostgres$ pg_config --includedir > > > > /usr/include/postgresql > > So the question is whether there is > /usr/include/postgresql/libpq-fe.h > as should be if libpq-dev is installed (says apt-file). > > If it is there, then the question is why it isn't found. > Besides the suspicion of Igor Korot, that `pg_config --includedir` would > not work, there is the possibility that libpostgres/Makefile.am was > not porperly converted to libpostgres/Makefile.in and then to > libpostgres/Makefile . Yep. That's why I think it makes sense to bisect the problem at the `pg_config' point: is it delivering the correct compile flags? If yes, look into the rest of configury, if not, try to fix pg_config. Many possibilities there: wrong pg_config in $PATH, left over from some attempt to self-compile PostgreSQL could be one. We just don't know :) > This is normally done by a script which calls autoconf and automake > to create Makefile.in. Later ./configure creates Makefile from Makefile.in. > In libisoburn the script has the name ./bootstrap and contains: > aclocal -I . > libtoolize --copy --force > autoconf > automake --foreign --add-missing --copy --include-deps > Don't ask me why. I inherited it in 2006 in the course of the libburn fork. > autotools usage worldwide is nearly completely driven by hearsay. There is some amount of cargo-cult in there. But it pays to try to understand it (I didn't succeed completely, mind you, but still...) > @ Igor Korot: > It would be interesting to see the effective compiler options (which the > make run seems to hide from the user) and whether the usage-ready > Makefile contains the lines I think the compile line must be visible (in its expanded form) in the build logs. I'd urge Igor to look out for it. And tell us, of course :) Cheers -- t
Attachment:
signature.asc
Description: PGP signature