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 <http://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 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?
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 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?Based on my experience with oracle_fdw, I would change the function declaration
in tds_fdw.h toextern 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
/messages/by-id/A737B7A37273E048B164557ADEF4A58B539300BD@ntex2010a.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:
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/messages/by-id/A737B7A37273E048B164557ADEF4A58B539300BD@ntex2010a.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 <http://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