The recent ecpg commit seems to have broken MSVC builds:


descriptor.obj : error LNK2019: unresolved external symbol _pg_snprintf referenced in function _ECPGget_desc
error.obj : error LNK2001: unresolved external symbol _pg_snprintf
misc.obj : error LNK2001: unresolved external symbol _pg_snprintf
path.obj : error LNK2001: unresolved external symbol _pg_snprintf
error.obj : error LNK2019: unresolved external symbol _pg_fprintf referenced in function _sqlprint
misc.obj : error LNK2001: unresolved external symbol _pg_fprintf
path.obj : error LNK2001: unresolved external symbol _pg_fprintf
execute.obj : error LNK2019: unresolved external symbol _pg_sprintf referenced in function _ECPGis_type_an_array execute.obj : error LNK2019: unresolved external symbol _pg_printf referenced in function _ECPGexecute misc.obj : error LNK2019: unresolved external symbol _pg_vfprintf referenced in function _ECPGlog path.obj : error LNK2019: unresolved external symbol _strlcpy referenced in function _join_path_components
thread.obj : error LNK2001: unresolved external symbol _strlcpy
.\Debug\libecpg\libecpg.dll : fatal error LNK1120: 6 unresolved externals
   10 Warning(s)
   13 Error(s)


This makes me worry about how fragile the support for MSVC is. If it can't handle changes like this then we'll forever be breaking things. That was one of the main reasons we went with MinGW/Msys in the first place - namely that we'd be using a single build system across all platforms.

This is not to say that the current build infrastructure is ideal - in fact I think it's pretty creaky. But I don't think we can accept an additional system which is always in danger of being out of sync.

Perhaps Magnus could give some precise details about the requirements of the buildsystem he's constructed.


cheers

andrew


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to