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
Mon, 18 Oct 2004 08:46:08 -0400
Andrew Dunstan <andrew@dunslane.net>
tsearch2 windows make failure
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

Mon, 18 Oct 2004 13:31:24 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: tsearch2 windows make failure 


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

Tue, 19 Oct 2004 18:35:16 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: tsearch2 windows make failure
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

Tue, 19 Oct 2004 18:43:39 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: tsearch2 windows make failure 


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



Wed, 20 Oct 2004 15:38:16 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: tsearch2 windows make failure