Re: [HACKERS] pkg-config files for libpq and ecpg
Peter Eisentraut pete...@gmx.net writes: So here is my updated patch, with the ecpg business changed as explained above, and the extra magic removed from the Cflags lines. No objections to this version. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pkg-config files for libpq and ecpg
Peter Eisentraut pete...@gmx.net writes: Right, we need to keep libpq in CPPFLAGS, but we can remove it from SHLIB_LINK. Buildfarm member anole says otherwise. I suspected something like that might happen --- if memory serves, there are platforms where you have to list all required libraries on the link line, even if some of them are only indirect dependencies of shlibs you are linking in. I think you need to revert 3780fc6. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pkg-config files for libpq and ecpg
On Wed, 2013-03-27 at 17:06 -0400, Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: On 3/24/13 1:55 PM, Tom Lane wrote: I experimented a bit with this version of the patch. The hunk that removes -I$(libpq_srcdir) and $(libpq) from the ecpg/compatlib build breaks the build for me, so I took it out. What was the error message? Probably not important, but curious. ecpg's #include of libpq-fe.h failed. I speculate that you didn't notice because you tested on a machine where libpq-fe.h exists in /usr/include. Right, we need to keep libpq in CPPFLAGS, but we can remove it from SHLIB_LINK. At least for the libraries we are currently proposing to pkgconfig-ify, it seems to me that we only want a -I for where we are installing our own headers; there is no need for anything else. That is, echo 'Cflags: -I$(includedir)' seems like plenty. We aren't exposing any other packages' headers in the public header files for these libraries, so there's no need to tell client packages about them. libpq exposes at least openssl and gssapi, so we need those at least. No, it does not. A client might choose to #include those of its own accord, but then it's the client's problem. Our exported headers do not #include anything more exotic than stdio.h, and it's not the business of the pkg-config switches to provide for anything beyond allowing inclusions of our headers to succeed. I was actually thinking of PQgetssl(), which is documented to require OpenSSL, but that was actually changed a long time ago and the documentation not updated. So actually you are right, we don't need to provided any extra -I flags (if we ignore libpq-int.h). We do need that whole logic for Libs.private however. So here is my updated patch, with the ecpg business changed as explained above, and the extra magic removed from the Cflags lines. diff --git a/.gitignore b/.gitignore index 4df314c..8e227a2 100644 --- a/.gitignore +++ b/.gitignore @@ -22,6 +22,7 @@ lcov.info win32ver.rc *.exe lib*dll.def +lib*.pc # Local excludes in root directory /GNUmakefile diff --git a/doc/src/sgml/ecpg.sgml b/doc/src/sgml/ecpg.sgml index 4d904cd..68bcb13 100644 --- a/doc/src/sgml/ecpg.sgml +++ b/doc/src/sgml/ecpg.sgml @@ -5715,6 +5715,15 @@ titleProcessing Embedded SQL Programs/title /para para + You can + use commandpg_config/commandindextermprimarypg_config/primarysecondary sortas=ecpgwith + ecpg/secondary/indexterm + or commandpkg-config/commandindextermprimarypkg-config/primarysecondary sortas=ecpgwith + ecpg/secondary/indexterm with package name literallibecpg/literal to + get the paths for your installation. + /para + + para If you manage the build process of a larger project using applicationmake/application, it might be convenient to include the following implicit rule to your makefiles: diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml index 1a09c1c..3b6ada0 100644 --- a/doc/src/sgml/libpq.sgml +++ b/doc/src/sgml/libpq.sgml @@ -7641,6 +7641,18 @@ titleBuilding applicationlibpq/application Programs/title /para para + If you + have commandpkg-config/commandindextermprimarypkg-config/primarysecondary sortas=libpqwith + libpq/secondary/indexterm installed, you can run instead: +screen +prompt$/prompt pkg-config --cflags libpq +computeroutput-I/usr/local/include/computeroutput +/screen + Note that this will already include the option-I/option in front of + the path. + /para + + para Failure to specify the correct option to the compiler will result in an error message such as: screen @@ -7675,6 +7687,15 @@ titleBuilding applicationlibpq/application Programs/title /para para + Or again use commandpkg-config/command: +screen +prompt$/prompt pkg-config --libs libpq +computeroutput-L/usr/local/pgsql/lib -lpq/computeroutput +/screen + Note again that this prints the full options, not only the path. + /para + + para Error messages that point to problems in this area could look like the following: screen diff --git a/src/Makefile.shlib b/src/Makefile.shlib index 4da2f10..2a0c7a9 100644 --- a/src/Makefile.shlib +++ b/src/Makefile.shlib @@ -87,6 +87,7 @@ shlib_bare = lib$(NAME)$(DLSUFFIX) # Testing the soname variable is a reliable way to determine whether a # linkable library is being built. soname = $(shlib_major) +pkgconfigdir = $(libdir)/pkgconfig else # Naming convention for dynamically loadable modules shlib = $(NAME)$(DLSUFFIX) @@ -305,6 +306,7 @@ all-lib: all-shared-lib ifdef soname # no static library when building a dynamically loadable module all-lib: all-static-lib +all-lib: lib$(NAME).pc endif all-static-lib: $(stlib) @@ -388,6 +390,23 @@ $(stlib): $(shlib) $(DLL_DEFFILE) | $(SHLIB_PREREQS) endif # PORTNAME == cygwin || PORTNAME == win32 +%.pc: $(MAKEFILE_LIST) + echo 'Name: lib$(NAME)' $@ + echo 'Description: PostgreSQL
Re: [HACKERS] pkg-config files for libpq and ecpg
On 3/24/13 1:55 PM, Tom Lane wrote: I experimented a bit with this version of the patch. The hunk that removes -I$(libpq_srcdir) and $(libpq) from the ecpg/compatlib build breaks the build for me, so I took it out. What was the error message? Probably not important, but curious. With that gone, I noted that I got this when building in a Fedora RPM environment (ie, the same way I would package PG for Fedora): Name: libpq Description: PostgreSQL libpq library Url: http://www.postgresql.org/ Version: 9.3devel Requires: Requires.private: Cflags: -I/usr/include -I/usr/include/libxml2 Libs: -L/usr/lib64 -lpq Libs.private: -lssl -lcrypto -lkrb5 -lcom_err -lgssapi_krb5 -lcrypt -lldap_r -lpthread The -I for libxml2 seems pretty darn bogus; can't we avoid that? We could, but only in a hardcoded way. As it is, it's part of the general set of flags that we use to build. libxml isn't special in this regard. It only shows up because you have it in a nondefault path. If you had openssl somewhere funny, it would show up as well. At least for the libraries we are currently proposing to pkgconfig-ify, it seems to me that we only want a -I for where we are installing our own headers; there is no need for anything else. That is, echo 'Cflags: -I$(includedir)' seems like plenty. We aren't exposing any other packages' headers in the public header files for these libraries, so there's no need to tell client packages about them. libpq exposes at least openssl and gssapi, so we need those at least. So in general, it won't work so easily to trim this list intelligently. That's something that could perhaps be tuned in the future, but I'd rather offer a few flags too many than not enough. One way to look at this for now is: It's not worse than what pg_config does. Also, I'm underwhelmed by the usefulness of the automatically-generated description lines. It might be better to ask the individual makefiles to set a PKG_CONFIG_DESCRIPTION macro. I think nobody reads that, so it would be a waste of time to maintain it. The URL is more important. I'd be more interested if some Windows thing had already put in the need for a package description (see PGFILEDESC). I'm not strictly against it, though. Lastly, I wonder whether it's worth adding a configure option or some such to control whether pkgconfig files are built, or at least whether they're installed. In a lot of environments this would just be adding useless clutter to the $(libdir). Considering how much other clutter we install without any options, I think it's fine as is. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pkg-config files for libpq and ecpg
Peter Eisentraut pete...@gmx.net writes: On 3/24/13 1:55 PM, Tom Lane wrote: I experimented a bit with this version of the patch. The hunk that removes -I$(libpq_srcdir) and $(libpq) from the ecpg/compatlib build breaks the build for me, so I took it out. What was the error message? Probably not important, but curious. ecpg's #include of libpq-fe.h failed. I speculate that you didn't notice because you tested on a machine where libpq-fe.h exists in /usr/include. At least for the libraries we are currently proposing to pkgconfig-ify, it seems to me that we only want a -I for where we are installing our own headers; there is no need for anything else. That is, echo 'Cflags: -I$(includedir)' seems like plenty. We aren't exposing any other packages' headers in the public header files for these libraries, so there's no need to tell client packages about them. libpq exposes at least openssl and gssapi, so we need those at least. No, it does not. A client might choose to #include those of its own accord, but then it's the client's problem. Our exported headers do not #include anything more exotic than stdio.h, and it's not the business of the pkg-config switches to provide for anything beyond allowing inclusions of our headers to succeed. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pkg-config files for libpq and ecpg
Peter Eisentraut pete...@gmx.net writes: On 1/15/13 6:53 PM, Tom Lane wrote: This bit: + echo 'Libs.private: $(filter-out $(PKG_CONFIG_REQUIRES_PRIVATE:lib%=-l%),$(filter-out -L..%, $(SHLIB_LINK)))' $@ appears to assume that SHLIB_LINK contains nothing except -L and -l switches. Updated patch addressing this concern. Also added comments and documentation. I experimented a bit with this version of the patch. The hunk that removes -I$(libpq_srcdir) and $(libpq) from the ecpg/compatlib build breaks the build for me, so I took it out. With that gone, I noted that I got this when building in a Fedora RPM environment (ie, the same way I would package PG for Fedora): Name: libpq Description: PostgreSQL libpq library Url: http://www.postgresql.org/ Version: 9.3devel Requires: Requires.private: Cflags: -I/usr/include -I/usr/include/libxml2 Libs: -L/usr/lib64 -lpq Libs.private: -lssl -lcrypto -lkrb5 -lcom_err -lgssapi_krb5 -lcrypt -lldap_r -lpthread The -I for libxml2 seems pretty darn bogus; can't we avoid that? At least for the libraries we are currently proposing to pkgconfig-ify, it seems to me that we only want a -I for where we are installing our own headers; there is no need for anything else. That is, echo 'Cflags: -I$(includedir)' seems like plenty. We aren't exposing any other packages' headers in the public header files for these libraries, so there's no need to tell client packages about them. Also, I'm underwhelmed by the usefulness of the automatically-generated description lines. It might be better to ask the individual makefiles to set a PKG_CONFIG_DESCRIPTION macro. Lastly, I wonder whether it's worth adding a configure option or some such to control whether pkgconfig files are built, or at least whether they're installed. In a lot of environments this would just be adding useless clutter to the $(libdir). Otherwise it seems about ready from here. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pkg-config files for libpq and ecpg
On 1/15/13 6:53 PM, Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: I'll take another stab at providing pkg-config files for the client-side libraries. This bit: +echo 'Libs.private: $(filter-out $(PKG_CONFIG_REQUIRES_PRIVATE:lib%=-l%),$(filter-out -L..%, $(SHLIB_LINK)))' $@ appears to assume that SHLIB_LINK contains nothing except -L and -l switches. I don't think I trust that a whole lot --- in fact, it looks guaranteed to fail on HPUX because of -print-libgcc-file-name. There might be other platform-specific bogosity on other platforms; PTHREAD_LIBS seems like a likely source for instance. Updated patch addressing this concern. Also added comments and documentation. diff --git a/.gitignore b/.gitignore index 4df314c..8e227a2 100644 --- a/.gitignore +++ b/.gitignore @@ -22,6 +22,7 @@ lcov.info win32ver.rc *.exe lib*dll.def +lib*.pc # Local excludes in root directory /GNUmakefile diff --git a/doc/src/sgml/ecpg.sgml b/doc/src/sgml/ecpg.sgml index 4d904cd..68bcb13 100644 --- a/doc/src/sgml/ecpg.sgml +++ b/doc/src/sgml/ecpg.sgml @@ -5715,6 +5715,15 @@ titleProcessing Embedded SQL Programs/title /para para + You can + use commandpg_config/commandindextermprimarypg_config/primarysecondary sortas=ecpgwith + ecpg/secondary/indexterm + or commandpkg-config/commandindextermprimarypkg-config/primarysecondary sortas=ecpgwith + ecpg/secondary/indexterm with package name literallibecpg/literal to + get the paths for your installation. + /para + + para If you manage the build process of a larger project using applicationmake/application, it might be convenient to include the following implicit rule to your makefiles: diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml index aa2ec2a..1794f9b 100644 --- a/doc/src/sgml/libpq.sgml +++ b/doc/src/sgml/libpq.sgml @@ -7641,6 +7641,18 @@ titleBuilding applicationlibpq/application Programs/title /para para + If you + have commandpkg-config/commandindextermprimarypkg-config/primarysecondary sortas=libpqwith + libpq/secondary/indexterm installed, you can run instead: +screen +prompt$/prompt pkg-config --cflags libpq +computeroutput-I/usr/local/include/computeroutput +/screen + Note that this will already include the option-I/option in front of + the path. + /para + + para Failure to specify the correct option to the compiler will result in an error message such as: screen @@ -7675,6 +7687,15 @@ titleBuilding applicationlibpq/application Programs/title /para para + Or again use commandpkg-config/command: +screen +prompt$/prompt pkg-config --libs libpq +computeroutput-L/usr/local/pgsql/lib -lpq/computeroutput +/screen + Note again that this prints the full options, not only the path. + /para + + para Error messages that point to problems in this area could look like the following: screen diff --git a/src/Makefile.shlib b/src/Makefile.shlib index 4da2f10..2527fe9 100644 --- a/src/Makefile.shlib +++ b/src/Makefile.shlib @@ -87,6 +87,7 @@ shlib_bare= lib$(NAME)$(DLSUFFIX) # Testing the soname variable is a reliable way to determine whether a # linkable library is being built. soname = $(shlib_major) +pkgconfigdir = $(libdir)/pkgconfig else # Naming convention for dynamically loadable modules shlib = $(NAME)$(DLSUFFIX) @@ -305,6 +306,7 @@ all-lib: all-shared-lib ifdef soname # no static library when building a dynamically loadable module all-lib: all-static-lib +all-lib: lib$(NAME).pc endif all-static-lib: $(stlib) @@ -388,6 +390,25 @@ $(stlib): $(shlib) $(DLL_DEFFILE) | $(SHLIB_PREREQS) endif # PORTNAME == cygwin || PORTNAME == win32 +%.pc: $(MAKEFILE_LIST) + echo 'Name: lib$(NAME)' $@ + echo 'Description: PostgreSQL lib$(NAME) library' $@ + echo 'Url: http://www.postgresql.org/' $@ + echo 'Version: $(VERSION)' $@ + echo 'Requires: ' $@ + echo 'Requires.private: $(PKG_CONFIG_REQUIRES_PRIVATE)' $@ +# Record -I flags that the user might have passed in to the PostgreSQL +# build to locate third-party libraries (e.g., ldap, ssl). Filter out +# those that point inside the build or source tree. Use sort to +# remove duplicates. + echo 'Cflags: -I$(includedir) $(sort $(filter-out -I.% -I$(top_srcdir)/%,$(filter -I%,$(CPPFLAGS' $@ + echo 'Libs: -L$(libdir) -l$(NAME)' $@ +# Record -L flags, as above for Cflags. Also record the -l flags +# necessary for static linking, but not those already covered by +# Requires.private. + echo 'Libs.private: $(sort $(filter-out -L.% -L$(top_srcdir)/%,$(filter -L%,$(LDFLAGS) $(SHLIB_LINK $(filter-out $(PKG_CONFIG_REQUIRES_PRIVATE:lib%=-l%),$(filter -l%,$(SHLIB_LINK)))' $@ + + # We need several not-quite-identical variants of .DEF files to build # DLLs for Windows. These are made from the single source file # exports.txt. Since we can't assume that
Re: [HACKERS] pkg-config files for libpq and ecpg
On Tue, Jan 15, 2013 at 02:16:01PM -0500, Peter Eisentraut wrote: A side issue that arose: libecpg_compat is linked with libpq, but doesn't seem to use it. This was added many years ago in cd75f94dafd43358305811b7576ad75d889097e3, but it doesn't appear to be required anymore. Needs some checking. libecpg_compat doesn't directly need libpq IIRC, but it does indirectly There are a couple functions from libecpg that are used in libecpg_compat and libecpg itself does need libpq. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pkg-config files for libpq and ecpg
I'll take another stab at providing pkg-config files for the client-side libraries. The main reason this time around is that this works a lot better (or at all) for multi-arch library installations. Another is that pkg-config has become a lot smarter and flexible over the years, and it's probably a better choice for users who are already used to its interface. There is a lot of confusion, for example, about what pg_config --libs really means. We often evade that by saying, well, those are the libraries we linked with, but there is a lack of clarity in that context about what libraries a user should link with. The way it's implemented, it doesn't require manual maintenance, so it should not be much of a bother. A side issue that arose: libecpg_compat is linked with libpq, but doesn't seem to use it. This was added many years ago in cd75f94dafd43358305811b7576ad75d889097e3, but it doesn't appear to be required anymore. Needs some checking. diff --git a/.gitignore b/.gitignore index 1e15ce5..b2854d9 100644 --- a/.gitignore +++ b/.gitignore @@ -21,6 +21,7 @@ lcov.info win32ver.rc *.exe lib*dll.def +lib*.pc # Local excludes in root directory /GNUmakefile diff --git a/src/Makefile.shlib b/src/Makefile.shlib index 4da2f10..d9728ba 100644 --- a/src/Makefile.shlib +++ b/src/Makefile.shlib @@ -87,6 +87,7 @@ shlib_bare= lib$(NAME)$(DLSUFFIX) # Testing the soname variable is a reliable way to determine whether a # linkable library is being built. soname = $(shlib_major) +pkgconfigdir = $(libdir)/pkgconfig else # Naming convention for dynamically loadable modules shlib = $(NAME)$(DLSUFFIX) @@ -305,6 +306,7 @@ all-lib: all-shared-lib ifdef soname # no static library when building a dynamically loadable module all-lib: all-static-lib +all-lib: lib$(NAME).pc endif all-static-lib: $(stlib) @@ -388,6 +390,18 @@ $(stlib): $(shlib) $(DLL_DEFFILE) | $(SHLIB_PREREQS) endif # PORTNAME == cygwin || PORTNAME == win32 +%.pc: $(MAKEFILE_LIST) + echo 'Name: lib$(NAME)' $@ + echo 'Description: PostgreSQL lib$(NAME) library' $@ + echo 'Url: http://www.postgresql.org/' $@ + echo 'Version: $(VERSION)' $@ + echo 'Requires: ' $@ + echo 'Requires.private: $(PKG_CONFIG_REQUIRES_PRIVATE)' $@ + echo 'Cflags: -I$(includedir)' $@ + echo 'Libs: -L$(libdir) -l$(NAME)' $@ + echo 'Libs.private: $(filter-out $(PKG_CONFIG_REQUIRES_PRIVATE:lib%=-l%),$(filter-out -L..%, $(SHLIB_LINK)))' $@ + + # We need several not-quite-identical variants of .DEF files to build # DLLs for Windows. These are made from the single source file # exports.txt. Since we can't assume that Windows boxes will have @@ -430,8 +444,12 @@ endif # SHLIB_EXPORTS install-lib: install-lib-shared ifdef soname install-lib: install-lib-static +install-lib: install-lib-pc endif +install-lib-pc: lib$(NAME).pc installdirs-lib + $(INSTALL_DATA) $ '$(DESTDIR)$(pkgconfigdir)/lib$(NAME).pc' + install-lib-static: $(stlib) installdirs-lib $(INSTALL_STLIB) $ '$(DESTDIR)$(libdir)/$(stlib)' ifeq ($(PORTNAME), darwin) @@ -467,7 +485,7 @@ endif installdirs-lib: ifdef soname - $(MKDIR_P) '$(DESTDIR)$(libdir)' + $(MKDIR_P) '$(DESTDIR)$(libdir)' '$(DESTDIR)$(pkgconfigdir)' else $(MKDIR_P) '$(DESTDIR)$(pkglibdir)' endif @@ -483,7 +501,8 @@ ifdef soname rm -f '$(DESTDIR)$(libdir)/$(stlib)' rm -f '$(DESTDIR)$(libdir)/$(shlib_bare)' \ '$(DESTDIR)$(libdir)/$(shlib_major)' \ - '$(DESTDIR)$(libdir)/$(shlib)' + '$(DESTDIR)$(libdir)/$(shlib)' \ + '$(DESTDIR)$(pkgconfigdir)/lib$(NAME).pc' else # no soname rm -f '$(DESTDIR)$(pkglibdir)/$(shlib)' endif # no soname @@ -495,7 +514,7 @@ endif # no soname .PHONY: clean-lib clean-lib: - rm -f $(shlib) $(shlib_bare) $(shlib_major) $(stlib) $(exports_file) + rm -f $(shlib) $(shlib_bare) $(shlib_major) $(stlib) $(exports_file) lib$(NAME).pc ifneq (,$(SHLIB_EXPORTS)) maintainer-clean-lib: diff --git a/src/interfaces/ecpg/compatlib/Makefile b/src/interfaces/ecpg/compatlib/Makefile index 00adcdb..6ae1493 100644 --- a/src/interfaces/ecpg/compatlib/Makefile +++ b/src/interfaces/ecpg/compatlib/Makefile @@ -18,10 +18,10 @@ SO_MAJOR_VERSION= 3 SO_MINOR_VERSION= 5 override CPPFLAGS := -I../include -I$(top_srcdir)/src/interfaces/ecpg/include \ - -I$(libpq_srcdir) -I$(top_srcdir)/src/include/utils $(CPPFLAGS) + -I$(top_srcdir)/src/include/utils $(CPPFLAGS) override CFLAGS += $(PTHREAD_CFLAGS) -SHLIB_LINK = -L../ecpglib -lecpg -L../pgtypeslib -lpgtypes $(libpq) \ +SHLIB_LINK = -L../ecpglib -lecpg -L../pgtypeslib -lpgtypes \ $(filter -lintl -lm, $(LIBS)) $(PTHREAD_LIBS) SHLIB_PREREQS = submake-ecpglib submake-pgtypeslib @@ -32,6 +32,8 @@ LIBS := $(filter-out -lpgport, $(LIBS)) OBJS= informix.o $(filter snprintf.o, $(LIBOBJS)) +PKG_CONFIG_REQUIRES_PRIVATE = libecpg libpgtypes + all: all-lib .PHONY:
Re: [HACKERS] pkg-config files for libpq and ecpg
Peter Eisentraut pete...@gmx.net writes: I'll take another stab at providing pkg-config files for the client-side libraries. This bit: + echo 'Libs.private: $(filter-out $(PKG_CONFIG_REQUIRES_PRIVATE:lib%=-l%),$(filter-out -L..%, $(SHLIB_LINK)))' $@ appears to assume that SHLIB_LINK contains nothing except -L and -l switches. I don't think I trust that a whole lot --- in fact, it looks guaranteed to fail on HPUX because of -print-libgcc-file-name. There might be other platform-specific bogosity on other platforms; PTHREAD_LIBS seems like a likely source for instance. Another point is that -L switches used at build time might not have much to do with the environment a .pc file would be used in later. I see that you're dropping relative -L paths, which is good as far as it goes, but I wonder whether it goes far enough. Perhaps the first step should be to filter in -l%, rather than filter out -L% ? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
