tsearch2 windows make failure
The attached log from make on tsearch2 for windows demonstrates a
failure at the dllwrap stage, presumably as a result of changes just
made to handle the relative path thing discussed yesterday. It also
illustrates some other make and compile warnings I am seeing quite
frequently, and to which I was about to turn my attention.
cheers
andrew
Attachments:
Andrew Dunstan <andrew@dunslane.net> writes:
../../src/Makefile.shlib:327: warning: overriding commands for target `libtsearch2.a'
../../src/Makefile.shlib:262: warning: ignoring old commands for target `libtsearch2.a'
Broken coding in the WIN32 parts of Makefile.shlib? I don't see this
here.
wparser_def.c:79:1: warning: "IDIGNORE" redefined
rewrite.c:177:1: warning: "V_UNKNOWN" redefined
Thanks Microsoft :-( ... guess we'll have to rename those macros.
Info: resolving _my_exec_path by linking to __imp__my_exec_path (auto-import)
fu000001.o(.idata$3+0xc): undefined reference to `libpostgres_a_iname'
nmth000000.o(.idata$4+0x0): undefined reference to `_nm__my_exec_path'
I was wondering whether my_exec_path might need to be marked DLLIMPORT.
Not sure about the other symbol though.
regards, tom lane
Tom Lane wrote:
Info: resolving _my_exec_path by linking to __imp__my_exec_path (auto-import)
fu000001.o(.idata$3+0xc): undefined reference to `libpostgres_a_iname'
nmth000000.o(.idata$4+0x0): undefined reference to `_nm__my_exec_path'I was wondering whether my_exec_path might need to be marked DLLIMPORT.
Not sure about the other symbol though.
Is this going to be fixed? Right now tsearch2 is totally busted for
Windows. I would fix it but my attempt (marking my_exec_path with
DLLIMPORT) just seemed to make things worse (pgtz.c blew up).
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
Tom Lane wrote:
I was wondering whether my_exec_path might need to be marked DLLIMPORT.
Not sure about the other symbol though.
Is this going to be fixed? Right now tsearch2 is totally busted for
Windows. I would fix it but my attempt (marking my_exec_path with
DLLIMPORT) just seemed to make things worse (pgtz.c blew up).
[ shrug ... ] *I'm* not going to fix it; I don't have a Windows setup
I could test a proposed fix on. And evidently it does need testing.
regards, tom lane
Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
../../src/Makefile.shlib:327: warning: overriding commands for target `libtsearch2.a'
../../src/Makefile.shlib:262: warning: ignoring old commands for target `libtsearch2.a'Broken coding in the WIN32 parts of Makefile.shlib? I don't see this
here.
Yes, I see that for win32 and cygwin a different ruleset is defined for
lib$(NAME).a if enable_shared is true. On most platforms those rules
only cover $(shlib) but for win32 and cygwin the enable_shared rules
cover both.
Is the right fix to surround the earlier rule with conditionals so there
isn't a rule conflict?
cheers
andrew