Donald Dong writes:
> I think #3 is a better choice since it's less invasive and would
> potentially avoid similar problems in the future. I think may worth
> the risks of breaking some extensions. I moved the rule to the
> Makefile.global and added $(X) in case it's set.
Yeah, I think #3 is the
> I observe that ecpg's Makefile.regress is already doing #3:
> %: %.o
> $(CC) $(CFLAGS) $< $(LDFLAGS) $(LDFLAGS_EX) $(LIBS) -o $@
> so what we'd be talking about is moving that to some more global spot,
> probably Makefile.global. (I wonder why the target is not specified
> as $@$(X) here
Donald Dong writes:
> Thank you for the explanation! That makes sense. It is strange that it does
> not work for me.
Yeah, I still can't account for the difference in behavior between your
platform and mine (I tried several different ones here, and they all
manage to build src/test/examples). Ho
Thank you for the explanation! That makes sense. It is strange that it does
not work for me.
> What platform are you on exactly, and what toolchain (gcc and ld
> versions) are you using?
I'm using Ubuntu 18.04.1 LTS.
gcc version:
gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
ld version:
GNU ld (GN
Donald Dong writes:
> In src/test/example, the implicit make rules produce errors:
Hm. "make" in src/test/examples works fine for me.
The only way I can account for the results you're showing is if your
linker is preferring libpq.a to libpq.so, so that reading the library
before the *.o files c
On Mon, Dec 31, 2018 at 11:24 PM Donald Dong wrote:
>
> Hi,
>
> In src/test/example, the implicit make rules produce errors:
>
> make -C ../../../src/backend generated-headers
> make[1]: Entering directory '/home/ddong/postgresql/bld/src/backend'
> make -C catalog distprep generated-header-symlink
