Обсуждение: [GENERAL] Building tds_fdw Extension for Windows 64bit
Hello,
After reading Craig's excellent blog post at https://blog.2ndquadrant.com/compiling-postgresql-extensions-visual-studio-windows/ I decided to try and build a real extension - tds_fdw.
I've set it up in Visual Studio Community 2017, but am getting the following errors:
Error C2375 'tds_fdw_handler': redefinition; different linkage tds_fdw E:\Workspace\git\tds_fdw\src\tds_fdw.c 118
Error C2375 'tds_fdw_validator': redefinition; different linkage tds_fdw E:\Workspace\git\tds_fdw\src\tds_fdw.c 156
Full output:
1>------ Rebuild All started: Project: tds_fdw, Configuration: Release x64 ------
1>deparse.c
1>options.c
1>tds_fdw.c
1>src\tds_fdw.c(118): error C2375: 'tds_fdw_handler': redefinition; different linkage
1>E:\Workspace\git\tds_fdw\include\tds_fdw.h(130): note: see declaration of 'tds_fdw_handler'
1>src\tds_fdw.c(156): error C2375: 'tds_fdw_validator': redefinition; different linkage
1>E:\Workspace\git\tds_fdw\include\tds_fdw.h(131): note: see declaration of 'tds_fdw_validator'
1>Generating Code...
1>Done building project "tds_fdw.vcxproj" -- FAILED.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
I'm not sure if it's related, but the FreeTDS version that I found for Windows is marked as 32bit and I am trying to build for 64bit.
I believe that extensions like tds_fdw and pgloader will help users on TDS databases to migrate to Postgres and will improve adoption of the project. I will be more than happy to publish my binaries of the extension if I ever get that far.
Can anyone help?
Thanks,
Igal Sapir
Lucee Core Developer
Lucee.org
Igal @ Lucee.org wrote: > After reading Craig's excellent blog post at https://blog.2ndquadrant.com/compiling-postgresql-extensions-visual-studio-windows/I decided to try and build a real extension- tds_fdw. > I've set it up in Visual Studio Community 2017, but am getting the following errors: > Error C2375 'tds_fdw_handler': redefinition; different linkage tds_fdw E:\Workspace\git\tds_fdw\src\tds_fdw.c 118 > Error C2375 'tds_fdw_validator': redefinition; different linkage tds_fdw E:\Workspace\git\tds_fdw\src\tds_fdw.c 156 > Full output: > 1>------ Rebuild All started: Project: tds_fdw, Configuration: Release x64 ------ > 1>deparse.c > 1>options.c > 1>tds_fdw.c > 1>src\tds_fdw.c(118): error C2375: 'tds_fdw_handler': redefinition; different linkage > 1>E:\Workspace\git\tds_fdw\include\tds_fdw.h(130): note: see declaration of 'tds_fdw_handler' > 1>src\tds_fdw.c(156): error C2375: 'tds_fdw_validator': redefinition; different linkage > 1>E:\Workspace\git\tds_fdw\include\tds_fdw.h(131): note: see declaration of 'tds_fdw_validator' > 1>Generating Code... > 1>Done building project "tds_fdw.vcxproj" -- FAILED. > ========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ========== > I'm not sure if it's related, but the FreeTDS version that I found for Windows is marked as 32bit and I am trying to buildfor 64bit. > I believe that extensions like tds_fdw and pgloader will help users on TDS databases to migrate to Postgres and will improveadoption of the project. I will be more than happy to publish my binaries of the extension if I ever get that far. > Can anyone help? Based on my experience with oracle_fdw, I would change the function declaration in tds_fdw.h to extern PGDLLEXPORT Datum tds_fdw_handler(PG_FUNCTION_ARGS); Yours, Laurenz Albe -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
On 11/2/2017 1:05 AM, Laurenz Albe wrote: > Igal @ Lucee.org wrote: >> After reading Craig's excellent blog post at https://blog.2ndquadrant.com/compiling-postgresql-extensions-visual-studio-windows/I decided to try and build a real extension- tds_fdw. >> I've set it up in Visual Studio Community 2017, but am getting the following errors: >> Error C2375 'tds_fdw_handler': redefinition; different linkage tds_fdw E:\Workspace\git\tds_fdw\src\tds_fdw.c 118 >> Error C2375 'tds_fdw_validator': redefinition; different linkage tds_fdw E:\Workspace\git\tds_fdw\src\tds_fdw.c 156 >> Full output: >> 1>------ Rebuild All started: Project: tds_fdw, Configuration: Release x64 ------ >> 1>deparse.c >> 1>options.c >> 1>tds_fdw.c >> 1>src\tds_fdw.c(118): error C2375: 'tds_fdw_handler': redefinition; different linkage >> 1>E:\Workspace\git\tds_fdw\include\tds_fdw.h(130): note: see declaration of 'tds_fdw_handler' >> 1>src\tds_fdw.c(156): error C2375: 'tds_fdw_validator': redefinition; different linkage >> 1>E:\Workspace\git\tds_fdw\include\tds_fdw.h(131): note: see declaration of 'tds_fdw_validator' >> 1>Generating Code... >> 1>Done building project "tds_fdw.vcxproj" -- FAILED. >> ========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ========== >> I'm not sure if it's related, but the FreeTDS version that I found for Windows is marked as 32bit and I am trying to buildfor 64bit. >> I believe that extensions like tds_fdw and pgloader will help users on TDS databases to migrate to Postgres and will improveadoption of the project. I will be more than happy to publish my binaries of the extension if I ever get that far. >> Can anyone help? > Based on my experience with oracle_fdw, I would change the function declaration > in tds_fdw.h to > > extern PGDLLEXPORT Datum tds_fdw_handler(PG_FUNCTION_ARGS); Thanks, Laurenz, but I am still getting the same error after prefixing the PGDLLEXPORT statements with `extern` in the `.c` files. The `.h` files already had `extern` for those declarations. Any other ideas? Thank you, Igal -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
"Igal @ Lucee.org" <igal@lucee.org> writes: > Any other ideas? It looks to me like MSVC is complaining about the PGDLLEXPORT markings that tds_fdw.c has on the function definitions (not the extern declarations). In the core code we only put PGDLLEXPORT in extern declarations ... so try keeping it in the externs and removing it from the .c file. You may still get warnings that way, which I think you probably have to live with, unless you want to make a .DEF file or use --export-all-symbols as a substitute for PGDLLEXPORT'ing specific functions. For some sorry history around this see https://www.postgresql.org/message-id/flat/A737B7A37273E048B164557ADEF4A58B539300BD%40ntex2010a.host.magwien.gv.at regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
On 11/2/2017 8:40 AM, Tom Lane wrote:
Tom, thank you for chiming in on this. I usually write Java code so am not very familiar with C/C++ or the inner workings of DLLs. I would love to be able to compile this extension though, as it will help me and others migrate databases from MS SQL to Postgres.
I removed the PGDLLEXPORT declarations from _tds_fdw.c_ and added a _deffile_ (tried to rename it to _tds_fdw.def_ but VS2017 complained that it can't find _deffile_ so I renamed it back). It looks like a similar concept as a MANIFEST.MF file in OSGi in Java where the manifest declares which packages are exported and which are imported.
So now I am getting the errors below. Do I need to add an entry in _deffile_ for each error message? What does the entry look like?
1>------ Rebuild All started: Project: tds_fdw, Configuration: Release x64 ------
1>deparse.c
1>options.c
1>tds_fdw.c
1>Generating Code...
1> Creating library E:\Workspace\git\tds_fdw\x64\Release\tds_fdw.lib and object E:\Workspace\git\tds_fdw\x64\Release\tds_fdw.exp
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbbind referenced in function tdsGetRowCountShowPlanAll
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbclose referenced in function estimate_path_cost_size
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbcmd referenced in function tdsExecuteQuery
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbcolname referenced in function tdsGetColumnMetadata
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbcoltype referenced in function tdsGetColumnMetadata
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbconvert referenced in function tdsConvertToCString
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbiscount referenced in function tdsGetRowCountExecute
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbcount referenced in function tdsGetRowCountExecute
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbdata referenced in function tdsIterateForeignScan
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbdatecrack referenced in function tdsDatetimeToDatum
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbdatlen referenced in function tdsIterateForeignScan
1>tds_fdw.obj : error LNK2019: unresolved external symbol dberrhandle referenced in function estimate_path_cost_size
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbexit referenced in function estimate_path_cost_size
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbinit referenced in function estimate_path_cost_size
1>tds_fdw.obj : error LNK2019: unresolved external symbol dblogin referenced in function estimate_path_cost_size
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbloginfree referenced in function estimate_path_cost_size
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbmsghandle referenced in function estimate_path_cost_size
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbnextrow referenced in function tdsGetRowCountExecute
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbnumcols referenced in function tdsGetRowCountShowPlanAll
1>tds_fdw.obj : error LNK2019: unresolved external symbol tdsdbopen referenced in function tdsSetupConnection
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbresults referenced in function tdsExecuteQuery
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbsqlexec referenced in function tdsExecuteQuery
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbuse referenced in function tdsSetupConnection
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbwillconvert referenced in function tdsConvertToCString
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbsetlname referenced in function tdsSetupConnection
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbsetlversion referenced in function tdsSetupConnection
1>E:\Workspace\git\tds_fdw\x64\Release\tds_fdw.dll : fatal error LNK1120: 26 unresolved externals
1>Done building project "tds_fdw.vcxproj" -- FAILED.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
Thanks again,
It looks to me like MSVC is complaining about the PGDLLEXPORT markings that tds_fdw.c has on the function definitions (not the extern declarations). In the core code we only put PGDLLEXPORT in extern declarations ... so try keeping it in the externs and removing it from the .c file. You may still get warnings that way, which I think you probably have to live with, unless you want to make a .DEF file or use --export-all-symbols as a substitute for PGDLLEXPORT'ing specific functions. For some sorry history around this see https://www.postgresql.org/message-id/flat/A737B7A37273E048B164557ADEF4A58B539300BD%40ntex2010a.host.magwien.gv.at regards, tom lane
Tom, thank you for chiming in on this. I usually write Java code so am not very familiar with C/C++ or the inner workings of DLLs. I would love to be able to compile this extension though, as it will help me and others migrate databases from MS SQL to Postgres.
I removed the PGDLLEXPORT declarations from _tds_fdw.c_ and added a _deffile_ (tried to rename it to _tds_fdw.def_ but VS2017 complained that it can't find _deffile_ so I renamed it back). It looks like a similar concept as a MANIFEST.MF file in OSGi in Java where the manifest declares which packages are exported and which are imported.
So now I am getting the errors below. Do I need to add an entry in _deffile_ for each error message? What does the entry look like?
1>------ Rebuild All started: Project: tds_fdw, Configuration: Release x64 ------
1>deparse.c
1>options.c
1>tds_fdw.c
1>Generating Code...
1> Creating library E:\Workspace\git\tds_fdw\x64\Release\tds_fdw.lib and object E:\Workspace\git\tds_fdw\x64\Release\tds_fdw.exp
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbbind referenced in function tdsGetRowCountShowPlanAll
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbclose referenced in function estimate_path_cost_size
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbcmd referenced in function tdsExecuteQuery
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbcolname referenced in function tdsGetColumnMetadata
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbcoltype referenced in function tdsGetColumnMetadata
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbconvert referenced in function tdsConvertToCString
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbiscount referenced in function tdsGetRowCountExecute
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbcount referenced in function tdsGetRowCountExecute
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbdata referenced in function tdsIterateForeignScan
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbdatecrack referenced in function tdsDatetimeToDatum
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbdatlen referenced in function tdsIterateForeignScan
1>tds_fdw.obj : error LNK2019: unresolved external symbol dberrhandle referenced in function estimate_path_cost_size
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbexit referenced in function estimate_path_cost_size
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbinit referenced in function estimate_path_cost_size
1>tds_fdw.obj : error LNK2019: unresolved external symbol dblogin referenced in function estimate_path_cost_size
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbloginfree referenced in function estimate_path_cost_size
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbmsghandle referenced in function estimate_path_cost_size
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbnextrow referenced in function tdsGetRowCountExecute
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbnumcols referenced in function tdsGetRowCountShowPlanAll
1>tds_fdw.obj : error LNK2019: unresolved external symbol tdsdbopen referenced in function tdsSetupConnection
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbresults referenced in function tdsExecuteQuery
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbsqlexec referenced in function tdsExecuteQuery
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbuse referenced in function tdsSetupConnection
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbwillconvert referenced in function tdsConvertToCString
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbsetlname referenced in function tdsSetupConnection
1>tds_fdw.obj : error LNK2019: unresolved external symbol dbsetlversion referenced in function tdsSetupConnection
1>E:\Workspace\git\tds_fdw\x64\Release\tds_fdw.dll : fatal error LNK1120: 26 unresolved externals
1>Done building project "tds_fdw.vcxproj" -- FAILED.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
Thanks again,
Igal Sapir
Lucee Core Developer
Lucee.org
"Igal @ Lucee.org" <igal@lucee.org> writes:
> So now I am getting the errors below. Do I need to add an entry in
> _deffile_ for each error message? What does the entry look like?
These look like you're failing to link to whatever library supplies
dbbind() etc. Can't help you more than that.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general