Makefile patch to make gcov work on Postgres contrib modules
I was trying to use gcov on Postgres and ran into a problem where some contrib
modules were missing the key libcov symbols and failed to load. Korry very
helpfully tracked down the missing bit: the broken modules were ones built
using "gcc -shared" according to the rule in Makefile.linux which doesn't have
-lcov.
Actually better than adding -lcov, I think this rule really ought to have
CFLAGS in it in case there are other CFLAGS that are necessary at link time.
Index: src/makefiles/Makefile.linux
===================================================================
RCS file: /home/stark/src/REPOSITORY/pgsql/src/makefiles/Makefile.linux,v
retrieving revision 1.22
diff -c -r1.22 Makefile.linux
*** src/makefiles/Makefile.linux 9 Dec 2005 21:19:36 -0000 1.22
--- src/makefiles/Makefile.linux 11 Apr 2007 00:34:43 -0000
***************
*** 11,16 ****
endif %.so: %.o
! $(CC) -shared -o $@ $<
sqlmansect = 7
--- 11,16 ----
endif %.so: %.o
! $(CC) $(CFLAGS) -shared -o $@ $<
sqlmansect = 7
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Gregory Stark wrote:
Actually better than adding -lcov, I think this rule really ought to
have CFLAGS in it in case there are other CFLAGS that are necessary
at link time.
But why would -lcov appear in CFLAGS? If it's a library it should be in
LIBS and perhaps in SHLIB_LINK.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Gregory Stark <stark@enterprisedb.com> writes:
%.so: %.o
! $(CC) -shared -o $@ $<
sqlmansect = 7 --- 11,16 ---- endif
%.so: %.o
! $(CC) $(CFLAGS) -shared -o $@ $<
Surely CFLAGS should be irrelevant at link time. Maybe LDFLAGS?
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes:
Gregory Stark <stark@enterprisedb.com> writes:
%.so: %.o
! $(CC) -shared -o $@ $<sqlmansect = 7 --- 11,16 ---- endif%.so: %.o
! $(CC) $(CFLAGS) -shared -o $@ $<Surely CFLAGS should be irrelevant at link time. Maybe LDFLAGS?
Does LDFLAGS contain flags that can be passed to $(CC) or are they expecting
to be passed to $(LD)?
It would be less convenient for the user who would have to do
CFLAGS='-fprofile-arcs -ftest-coverage' LDFLAGS='-fprofile-arcs -ftest-coverage' ./configure
Unless there's a makefile variable that is included in both CFLAGS and LDFLAGS
that the user could use instead? But then that wouldn't work on architectures
where ld is used instead of gcc for linking.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Am Donnerstag, 12. April 2007 17:08 schrieb Gregory Stark:
Unless there's a makefile variable that is included in both CFLAGS and
LDFLAGS that the user could use instead? But then that wouldn't work on
architectures where ld is used instead of gcc for linking.
Perhaps you should start by defining which situation you want to achieve.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Peter Eisentraut <peter_e@gmx.net> writes:
Am Donnerstag, 12. April 2007 17:08 schrieb Gregory Stark:
Unless there's a makefile variable that is included in both CFLAGS and
LDFLAGS that the user could use instead? But then that wouldn't work on
architectures where ld is used instead of gcc for linking.Perhaps you should start by defining which situation you want to achieve.
There are two ways to get gcov to work. Either you add -lcov to the end of the
linking step or you use the same -f flags that you use at the compile stage.
So what I would like to happen is something like:
CFLAGS='-fprofile-arcs -ftest-coverage -O0 -g' ./configure --enable-debug --enable-cassert --enable-depend
make
make check
gcov src/backend/access/common/heaptuple.c
Perhaps the flags need to be in a separate variable instead of CFLAGS
specifically advertised to ensure the flags will show up in both compile and
linking lines.
--
greg
Greg Stark wrote:
Perhaps the flags need to be in a separate variable instead of CFLAGS
specifically advertised to ensure the flags will show up in both
compile and linking lines.
CFLAGS ordinarily does show up in both of these places. Where it
doesn't, it should be added.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/