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 Eisen
Peter Eisentraut <[EMAIL PROTECTED]> 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 instea
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 def
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > %.so: %.o
> > ! $(CC) -shared -o $@ $<
>
> > sqlmansect = 7
> > --- 11,16
> > endif
>
> > %.so: %.o
> > ! $(CC) $(CFLAGS) -shared -o $@ $<
>
> Surely CFLAGS should be irrelevant at link t
Gregory Stark <[EMAIL PROTECTED]> 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
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 Eis
