Thread: msvc build broken for ecpg
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
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
Magnus Hagander wrote: >> 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 :-) > > > What I want to know is how resistant it is to breakage. Will it break if we add or remove a source file? A header? A directory? A library? cheers andrew
>> 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 :-) >> >> >> > > What I want to know is how resistant it is to breakage. Will it break if > we add or remove a source file? No. > A header? No, unless it requires changing the global include path. > A directory? As a part of the existing makefile structure? No. As a new makefile target (say a new directory in /bin for a new .exe)? Yes. > A library? If the library is required to build, yes, it will need to be added. If it's optional, it will still work but not use the library, until added. If you mean a library that we *build* (like libpq), yes (unless it's in contrib where it's picked up automatically). //Magnus