Thread: 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/