Windows: build with "build-gdal" about node-gdal HOT 10 CLOSED

@BergWerkGIS - thanks for posting the linking errors. I think you are very close to this working. My sense is that this is happening because the GDAL you have built has ODBC enabled and so it needs to be linked again when being linked by gdal.node. So does this fix it?

diff --git a/binding.gyp b/binding.gyp
index 8c58792..a89d4e5 100644
--- a/binding.gyp
+++ b/binding.gyp
@@ -64,6 +64,8 @@
                                                        "libraries": [
                                                                '<!@(find <(shar
                                                                "-lws2_32.lib"
+                                                               "-lodbccp32.lib"
+                                                               "-lodbc32.lib"
                                                        ],
                                                        "include_dirs": [
                                                                "deps/libgdal/ar

from node-gdal.

One step further, new error:

libpq.lib(fe-connect.obj) : error LNK2001: unresolved external symbol __imp__FreeCredentialsHandle@4 [C:\projects\node-gdal\build \gdal.vcxproj]
libpq.lib(fe-connect.obj) : error LNK2001: unresolved external symbol __imp__DeleteSecurityContext@4 [C:\projects\node-gdal\build \gdal.vcxproj]
libpq.lib(fe-auth.obj) : error LNK2001: unresolved external symbol _AcquireCredentialsHandleA@36 [C:\projects\node-gdal\build\gda l.vcxproj]
libpq.lib(fe-auth.obj) : error LNK2001: unresolved external symbol _InitializeSecurityContextA@48 [C:\projects\node-gdal\build\gd al.vcxproj]
libpq.lib(fe-auth.obj) : error LNK2001: unresolved external symbol _FreeContextBuffer@4 [C:\projects\node-gdal\build\gdal.vcxproj ]
C:\projects\node-gdal\build\Release\gdal.node : fatal error LNK1120: 5 unresolved externals [C:\projects\node-gdal\build\gdal.vcx proj]

from node-gdal.

Yeah!
node-gdal compiles with the output of build-gdal: 336 passing tests.
Had to add the odbcs libs mentioned above and "-lsecur32.lib" to binding.gyp and copy libexpat.dll to the binding dir.

@springmeyer
I don't know if this is desirable behavior.
When running npm test without libexpat.dll in the binding directory, the following happened, and all tests were successfull:

I think this is pretty easy to miss if you are just looking at the results of the tests and one might think the build was successful when in reality is wasn't.
Especially during automation.

Is there a switch to npm test to prevent this behaviour?

from node-gdal.

@BergWerkGIS - great work on getting this working!

Good catch on the npm test oddity. That is not good but understandable. It is happening because of this pretest line:

I think the simplest solution here is to remove that pretest line and just expect that developers will have those dependencies correctly installed after the first npm install.

from node-gdal.

pre-test fix at #55

@BergWerkGIS - can you queue up a new pull request with the library linking fixes?

from node-gdal.

Concerning changes to binding.gyp see 836c6e7

from node-gdal.

@BergWerkGIS - can you summarize big picture were we are at with using an external gdal for the build for windows? What are the next actions you see?

from node-gdal.

@springmeyer

It is possible to use an external gdal for the build, see:
appveyor.yml
binding.gyp

Although I was not able to get node-gdal compile with a version built by build-gdal or mapnik-dependencies.

I made it work like this:

• compiled node-gdal without external binaries
• packaged the resulting libs and uploaded them to S3
• referenced uploaded package for appveyor

Next actions as I see them:

• analyze why node-gdal doesn't work with the libs, that have been created via the scripts that come with gdal itself. I'm not sure if I'm the right person to do this, as I'm not familiar with the ins and outs of building gdal. Maybe I would need just a few hints on where to start.
• make node-gdal work with libs from other compiles
• dump build-gdal and building of gdal within node-gdal and only use gdal from mapnik-dependencies. So we have only one build script to maintain and not three

from node-gdal.

Awesome, thanks for the overview.

compiled node-gdal without external binaries

By this you mean that you grabbed the libgdal/etc that resulted from the npm install here and then repackaged it? Clever, I missed that previously :)

analyze why node-gdal doesn't work with the libs

Okay, I'm sure we can figure this out together - perhaps an iss of what GDAL drivers are built vs what GDAL drivers node-gdal expects are available.

dump build-gdal and building of gdal within node-gdal and only use gdal from mapnik-dependencies. So we have only one build script to maintain and not three

👍 And of course I need to follow through on my mason dreams/promises, but until then yes, sounds great to merge build-gdal -> mapnik-deps.

from node-gdal.

Closing, builds are fully done on AppVeyor now.

from node-gdal.