compile errors

[vindoctor]

when trying to compile against gdal with other SDK's I now get the following link errors. This happens in both vs2005 and vs2012

1>        C:\Program Files (x86)\Microsoft Visual Studio 8\VC\include\stdio.h(208) : see previous definition of 'feof'
1>f:\dev\sourcecode\trunk\3rd_party_opensrc\gdal_27261\port\cpl_vsi.h(181) : error C2733: second C linkage of overloaded function '_GTIFcalloc' not allowed
1>        f:\dev\sourcecode\trunk\3rd_party_opensrc\gdal_27261\port\cpl_vsi.h(181) : see declaration of '_GTIFcalloc'
1>f:\dev\sourcecode\trunk\3rd_party_opensrc\gdal_27261\port\cpl_vsi.h(182) : error C2733: second C linkage of overloaded function '_GTIFcalloc' not allowed
1>        f:\dev\sourcecode\trunk\3rd_party_opensrc\gdal_27261\port\cpl_vsi.h(182) : see declaration of '_GTIFcalloc'
1>f:\dev\sourcecode\trunk\3rd_party_opensrc\gdal_27261\port\cpl_vsi.h(184) : error C2733: second C linkage of overloaded function '_GTIFrealloc' not allowed
1>        f:\dev\sourcecode\trunk\3rd_party_opensrc\gdal_27261\port\cpl_vsi.h(184) : see declaration of '_GTIFrealloc'

[vindoctor]

I guess it should state, when I compile other sdk's against gdal. For example, liblas trying to link against gdal.

[Even Rouault]

Mateusz, Howard, perhaps you have an idea about that as it seems related to liblas... ? I suspect some odd stuff with libgeotiff.

[vindoctor]

I found an old ticket that relates. What I do not understand is nothing has changed in my build system other than gdal, so maybe the includes within gdal are exposing this issue somehow with liblas and liggeotiff?

the old ticket is: ​https://trac.osgeo.org/gdal/ticket/4374

[vindoctor]

BTW, I know its wrong, but just so I can keep moving fwd (as well as anyone else) until the proper way gets fixed in liblas or gdal... in cpl_vsi.h just comment out all but the VSIFree. I'm using the same compiler for all my 3rd party libs so I'm hoping this crutch works for the next week or so... Again, I know its not the right thing to do for production code.

void CPL_DLL *VSICalloc( size_t, size_t ) CPL_WARN_UNUSED_RESULT; void CPL_DLL *VSIMalloc( size_t ) CPL_WARN_UNUSED_RESULT; void CPL_DLL VSIFree( void * ); void CPL_DLL *VSIRealloc( void *, size_t ) CPL_WARN_UNUSED_RESULT; char CPL_DLL *VSIStrdup( const char * ) CPL_WARN_UNUSED_RESULT;

[Even Rouault]

Yes, this is not a proper solution since using the VSI* call might be valid for external code to GDAL. In ​https://trac.osgeo.org/gdal/ticket/4374 I think I identified the issue : for some reasons, an internal header of libgeotiff that does some nasty #define gets exposed to the outside world. So the issue is more in libgeotiff.

[Mateusz Łoskot]

Even,

I recall numerous issues while building libLAS or PDAL with libgeotiff (or GDAL with libgeotiff) support, but the error messages are slightly different. For example

• in libLAS: ​https://gist.github.com/hobu/8477865 (see also ​https://github.com/libLAS/libLAS/issues/33)

  port/cpl_vsi.h:180:17: error: conflicting types for '_GTIFcalloc'
  void CPL_DLL   *VSICalloc( size_t, size_t ) CPL_WARN_UNUSED_RESULT;
                  ^
  

• in PDAL: ​https://gist.github.com/chambbj/2229405

  /usr/local/include/cpl_conv.h:63: error: declaration of C function ‘void* gtCPLMalloc(size_t)’ conflicts with
  /usr/local/include/cpl_serv.h:147: error: previous declaration ‘void* gtCPLMalloc(int)’ here
  

But, we've discussed those already ​https://trac.osgeo.org/gdal/ticket/4374

[vindoctor]

Yeah, I just don't understand why everything was fine for the last couple years and now its showing up.

[Mateusz Łoskot]

If there is no obvious issue, sometimes problems appear after compilers update. New C/C++ compilers have become more standard compliant and strict, so the distinction between C and C++ languages and C vs C++ compilation mode has become more evident (at compile-time). Language constructions on the edge of conformity that would be swallowed by older compiler w/o problems, are now caught as an error.

Perhaps, this is explains the 'dynamic' nature of the libgeotiff vs other libraries issues.

[Even Rouault]

vindoctor,

It would be good if you could isolate on which liblas file the error occurs, and post the whole compilation line to see which include paths are used. Do you use external libgeotiff as well ? This issue is rather complex to analyze as it mixes different packages... And specify which versions of the different packages you use.

[cleo]

In LIBLAS, in the CMakeLists.txt file in the "if (WIN32)" section of the Platform specific settings sections, you can add:

add_definitions("-DCPL_DLL=declspec(dllimport)")

The formatting is messed up. Supposed two underscores before declspec.

This will remove the stdio warnings.

In LIBLAS gt_wkt_srs.cpp, I deleted #include "cpl_serv.h" and replaced it with this:

#define CPL_SERV_H_INCLUDED #include "cpl_error.h" #include "cpl_csv.h"

I'm using GDAL 1.11 and libgeotiff 1.4

This isn't a GDAL problem. LIBLAS is badly configured.

Posting the above in case others come across this ticket with the same issue.

[hobu]

This has been fixed in the latest libLAS master. I just built libLAS master against OSGeo4W64 GDAL 1.11 today using MSVC2013.

[Even Rouault]

From above comments, doesn't seem to be a GDAL bug. Closing. Reopen if needed