Closed ldesousa closed 3 years ago
Hello Luis,
I suggest trying the following:
On the SASetupDefaultHooks multiple definition problem:
LDLIBS= $(DGLIBDIR)/lib/dglib.a \ $(SHPLIBDIR)/lib/shapelib.a \ $(PROJ4LIBDIR)/lib/proj4lib.a ${ADD_LD_LIBS}
Into:
LDLIBS= $(DGLIBDIR)/lib/dglib.a \ $(PROJ4LIBDIR)/lib/proj4lib.a ${ADD_LD_LIBS}
On the undefined json references:
Please let me know how it goes...
Kevin
On Feb 25, 2021, at 11:31 AM, Luís de Sousa notifications@github.com wrote:
Hi Kevin,
some months ago I tried to compile DGGRID on Linux (Ubuntu) coming to a dead end with the shapefile methods. The conclusion at the time http://osgeo-org.1560.x6.nabble.com/gdal-dev-undefined-reference-to-json-object-new-array-linking-with-libgdal-a-td5442523.html was this being caused by the way the GDAL versions available from the repositories are compiled.
Last weekend I compiled GDAL myself on my system and gave it a go with those binaries. Compilation still fails with similar error messages (the relevant segment is below). I only modified the GDAL_HDR_DIR and GDAL_LIB variables in the MakeIncludes file, pointing them to the locally built GDAL folders.
make --directory=lib/dglib/lib make[1]: Entering directory '/home/duque004/git/DGGRID/src/lib/dglib/lib' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/home/duque004/git/DGGRID/src/lib/dglib/lib' make --directory=lib/shapelib/lib make[1]: Entering directory '/home/duque004/git/DGGRID/src/lib/shapelib/lib' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/home/duque004/git/DGGRID/src/lib/shapelib/lib' make --directory=lib/proj4lib/lib make[1]: Entering directory '/home/duque004/git/DGGRID/src/lib/proj4lib/lib' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/home/duque004/git/DGGRID/src/lib/proj4lib/lib' make --directory=apps/dggrid make[1]: Entering directory '/home/duque004/git/DGGRID/src/apps/dggrid' g++ -I../../lib/dglib/include -I../../lib/shapelib/include -I../../lib/proj4lib/include -I/home/duque004/bin/gdal-3.2.1/include -O3 -std=c++11 -o dggrid binvals.o dggrid.o quadclip.o transform.o binpres.o gridgen.o DgHexSF.o param.o clipper.o table.o util.o ../../lib/dglib/lib/dglib.a ../../lib/shapelib/lib/shapelib.a ../../lib/proj4lib/lib/proj4lib.a /home/duque004/src/gdal-3.2.1/.libs/libgdal.a
/usr/bin/ld: /home/duque004/src/gdal-3.2.1/.libs/libgdal.a(shp_vsi.o): in functionSASetupDefaultHooks': /home/duque004/src/gdal-3.2.1/ogr/ogrsf_frmts/shape/shp_vsi.c:255: multiple definition of
SASetupDefaultHooks'; ../../lib/shapelib/lib/shapelib.a(safileio.o):safileio.c:(.text+0xc0): first defined here /usr/bin/ld: /home/duque004/src/gdal-3.2.1/.libs/libgdal.a(ogrfeature.o): in functionOGRFeature::GetFieldAsSerializedJSon(int) const': /home/duque004/src/gdal-3.2.1/ogr/ogrfeature.cpp:3292: undefined reference to
json_object_new_array' There are hundreds more of undefined reference errors with the GDAL methods, but I suspect those are just symptoms of the same problem.Any help appreciated.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sahrk/DGGRID/issues/25, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDRFIH7NJJOSJU6GQ3KB3DTA2QRZANCNFSM4YHDFVTA.
Thank you Kevin for the reply. Changing the LDLIBS
variable as you indicate indeed removed the "multiple definition" errors. I then removed the -ljson-c
flag and pointed GDAL_LIB
to libgdal.so
and finally the compilation succeeded.
I will still be trying to compile with the packaged version of GDAL. Will report back. Cheers.
Great! I need to fix these issues in the DGGRID distro. Could I ask you to test one thing, just in case? If you just use libgdal.so, and put LDLIBS back the way it is originally (including the local shapelib), by any chance does that also fix the multiple definition errors?
On Mar 1, 2021, at 11:35 AM, Luís de Sousa notifications@github.com wrote:
Thank you Kevin for the reply. Changing the LDLIBS variable as you indicate indeed removed the "multiple definition" errors. I then removed the -ljson-c flag and pointed GDAL_LIB to libgdal.so and finally the compilation succeeded.
I will still be trying to compile with the packaged version of GDAL. Will report back. Cheers.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/sahrk/DGGRID/issues/25#issuecomment-788213482, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDRFICY74EQIVG3X3JXKJDTBPT6LANCNFSM4YHDFVTA.
Hi again Kevin, indeed simply directing GDAL_LIB
to libgdal.so
is enough for the compiler to succeed. I also managed to compile with the packaged version of GDAL. Perhaps this needs to be updated in the README.
Let me know if there is something else I can try. Cheers.
Thanks Luis, I will put better comments in the MakeIncludes file.
On Mar 2, 2021, at 8:17 AM, Luís de Sousa notifications@github.com wrote:
Hi again Kevin, indeed simply directing GDAL_LIB to libgdal.so is enough for the compiler to succeed. I also managed to compile with the packaged version of GDAL. Perhaps this needs to be updated in the README.
Let me know if there is something else I can try. Cheers.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/sahrk/DGGRID/issues/25#issuecomment-789026360, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDRFIB3IPAWWTKKTB6Y7ITTBUFRLANCNFSM4YHDFVTA.
Great, and thank you for helping. Closing the ticket.
Hi Kevin,
some months ago I tried to compile DGGRID on Linux (Ubuntu) coming to a dead end with the shapefile methods. The conclusion at the time was this being caused by the way the GDAL versions available from the repositories are compiled.
Last weekend I compiled GDAL myself on my system and gave it a go with those binaries. Compilation still fails with similar error messages (the relevant segment is below). I only modified the
GDAL_HDR_DIR
andGDAL_LIB
variables in theMakeIncludes
file, pointing them to the locally built GDAL folders.There are hundreds more of undefined reference errors with the GDAL methods, but I suspect those are just symptoms of the same problem.
Any help appreciated.