Re: Broken build - was: removal of pgnuplot

[Bastian M. <bma...@we...>]

Am 24.06.2013 00:58, schrieb Hans-Bernhard Bröker:
> On 24.06.2013 00:25, Bastian Märkisch wrote:
>> Am 23.06.2013 23:37, schrieb Hans-Bernhard Bröker:
>>>
>>> Oh, but while on the topic of pgnuplot: some of your recent changes
>>> related to wredirect.c seem to have broken its build.  It now reports
>>> variations of
>>>
>>> Error! E2028: MyPrintF_ is an undefined reference
>>> Error! E2028: MyFPrintF_ is an undefined reference
>>> Error! E2028: MyFGetS_ is an undefined reference
>>> file pgnuplot.obj(c:\prg\gp\gnuplot\src\win\pgnuplot.c): undefined
>>> symbol MyPrintF_
>>> file pgnuplot.obj(c:\prg\gp\gnuplot\src\win\pgnuplot.c): undefined
>>> symbol MyFPrintF_
>>> file pgnuplot.obj(c:\prg\gp\gnuplot\src\win\pgnuplot.c): undefined
>>> symbol MyFGetS_
>>>
>>> on all Windows compilers I tried. Building bf_test.exe fails similarly.
>>>
>>
>> I cannot reproduce that problem here using MinGW or MSVC 2008.  The
>> intention was not to compile wredirect.cpp when using OpenWatcom, since
>> it is only helpful when using third party C++ libraries.
>
> Well, it breaks here on all three of those.  And it didn't until
> relatively recently.  Did you do a full rebuild (e.g. "wmake realclean
> all")?  Is there a possibility you have some local change to the
> Makefiles / Windows sources which would be needed?

Clean source and "(n)make veryclean && (n)make all", indeed. The only 
change to config/mingw/Makefile is that I enabled gd,wxt,cairo, and lua 
terminals. No changes at all to config/msvc/Makefile. Only building 
wgnuplot-ja.chm using the MingW makefile currently fails because the 
Japanese patches in CVS are outdated. Everything else works as it 
should. (Just double checked again.)

Are you sure that your source tree is a clean checkout?

Btw. I no longer have the possibility to check building with OpenWatcom 
or Cygwin.

>
> wredirect.cpp itself may be a red herring.  It could have been some of
> the other changes you did around that time.
>
>>> Oh, and OpenWatcom dislikes the redefinition of ETO_PDY in emf.trm. It's
>>> not used anywhere in gnuplot, and it conflicts with <wingdi.h>.
>>
>> Interesting.  That has been there since Ethan introduced enhanced text
>> support in 2008 (rev 1.55).
>
> The reason this never caused trouble before must be that we managed to
> keep the Windows headers invisible to the compilation of term.c before.

No it must be something else.  That "#include <windows.h>" line has been 
in win.trm since rev 1.1, ie. since before the beginning of the CVS 
repository, and win.trm is always included before emf.trm in src/term.h.
Anyway, that duplicate definition should be removed or protected by an 
#ifdef / #endif.