Re: msvc build broken for ecpg - Mailing list pgsql-hackers

Andrew Dunstan wrote:
> 
> 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)
> 

ecpg needs to link with libpgport. Instead of always linking with it, I
went with adding it only to those projects that actually need it. Seems
I missed ecpg on that - probably because one of my dev boxes builds
without ecpg since I don't have the pthreads lib on it.

So it's not actually ecpgs fault...


> 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.

It's intended to parse as much as possible out of the existing files.
Unfortunately, the makefiles aren't consistent enough to make this
always work, which is why each project in /bin/ for example is added
manually. In /contrib/ they're a lot more consistent, so they're
auto-parsed.

But - what specifically do you want to know? I'll be happy to give the
details if I know what you're after :-)

//Magnus