conflicting typedef for int64

[sasavilic]

System information (version)

• OpenCV => 2.4.9 (2.4.9.1+dfsg-1.5ubuntu1)
• Operating System / Platform => Ubuntu 16.04, 64 bit
• Compiler => GNU GCC 5.2

Detailed description

OpenCV has typedef in global namespace that will prevent compilation if other library has conflicting typedef. Currently, we are aware of one library (libgeos) that has conflicting typedef. We are going to submit similar bug report to libgeos.

// libgeos
typedef long long int int64;
// opencv
typedef int64_t int64;

I am aware that this problem could be solved by compiling code in different compilation unit, but currently we have shared code that can't be separated (or at least not easily) in different compilation units. The only option in that case is to either mess with typedef, i.e.:

#define int64 opencv_broken_int
#include <opencv2/imgproc/imgproc.hpp>
#undef int64
#include <geos/geom/Coordinate.h>

int main(int, argc**)
{
    return 0;
}

or make wrapper interface and compile it different compilation units. Nevertheless, the nicest solution would be if opencv could stop using common typename like int64 in global namespace.

I am aware that using C++ namespace might not be option due to C interface, but at least prefixed typedef could be used, i.e. opencv_int64 / cv_int64 or similar. Such typedef would not break ABI, although it would change API.

We are ready to commit resources to this issue and provide a patch once we agree that this should be fixed and agree what is best approach to this issue.

Steps to reproduce

// sample.cpp
#include <geos/geom/Coordinate.h>
#include <opencv2/imgproc/imgproc.hpp>

int main(int, argc**)
{
    return 0;
}

$ g++ -c sample.cpp 
In file included from /usr/include/opencv2/core/core.hpp:49:0,
                 from /usr/include/opencv2/imgproc/imgproc.hpp:50,
                 from sample.cpp:2:
/usr/include/opencv2/core/types_c.h:163:20: error: conflicting declaration ‘typedef int64_t int64’
    typedef int64_t int64;
                    ^
In file included from /usr/include/geos/geom/Coordinate.h:19:0,
                 from sample.cpp:1:
/usr/include/geos/platform.h:66:26: note: previous declaration as ‘typedef long long int int64’
    typedef long long int int64;
                          ^
sample.cpp:4:15: error: ‘argc’ has not been declared
 int main(int, argc**)
               ^
sample.cpp:4:5: warning: second argument of ‘int main(int, int**)’ should be ‘char **’ [-Wmain]
 int main(int, argc**)

[alalek]

I observed some tricks for similar problems in pure C:

• special macro (but it should be used in all places/libraries in the same way):

// stdio.h sys/stat.h sys/types.h have this:
# ifndef __ssize_t_defined
typedef __ssize_t ssize_t;
# define __ssize_t_defined
# endif

• prefixes (conflicts are still possible because prefix length is about ~1-3 symbols and adding prefix will break source compatibility):

// Qt/qglobal.h
typedef __int64 qint64;

[kinchungwong]

Does OpenCV have a roadmap to eventually migrate to <cstdint> types?

http://en.cppreference.com/w/cpp/header/cstdint

[nightsparc]

Same problem here.
The define/undef-hack is really ugly.

Would be really nice if OpenCV could stop bloating global namespace - at least in OpenCV3 where the C-API is considered deprecated (as as far as I know), it should be possible to move the the tdefs into the cv:: namespace.

Or give it some prefix, I mean - come on, it's just a simple refactoring.

[ronaldoesa]

i also encounter the same problem when using Dlib 19.17 with OpenCV 4.1.1
on OpenCV 4.1.1 (core_c.h & interface.h) on GetTickCount()
typedef int64_t int64
on Dlib 19.17 (when compiling with CUDA support)
typedef long long int dlib:: int64

[Dinesh13197]

i also encounter the same problem when using SystemC 2.3.1-Accellera with OpenCV 4.1.1
on OpenCV 4.1.1
opencv/core/types_c.h:164:21: error: redeclaration of ‘typedef uint64_t uint64’
typedef uint64_t uint64;

systemc/include/sysc/datatypes/int/sc_nbdefs.h:182:36: note: previous declaration ‘typedef long long unsigned int sc_dt::uint64’
typedef unsigned long long uint64;

[agarwal-ayushi]

@Dinesh13197 : Did you find a solution to this problem? I am integrating OpenCV with SystemC and I am facing the same issue. The def/undef solution is really ugly .

[vrabaud]

This int64 is used for two things in the code:

• as int64_t (in that case, it is just a matter of doing a int64->int64_t replacement)
• to name variables when using macros (especially for intrinsics)

The following modifies my local sources so that it can compile with other libraries that define int64 (like SWIG). Not elegant ...

sed -i 's:\(#define OPENCV_CORE_TYPES_H\):\1\n#include <cstdint>:g' modules/core/include/opencv2/core/types_c.h
sed -i 's:\(#define OPENCV_CORE_HAL_INTERFACE_H\):\1\n#include <cstdint>:g' modules/core/include/opencv2/core/hal/interface.h
sed -i 's:\(typedef [u]*int64\):// \1:g' modules/core/include/opencv2/core/hal/interface.h

for i in int64 uint64; do
  find modules -regextype sed -regex ".*\.\(h\|cpp\|hpp\|cu\|cc\)" -type f -print0 | xargs -0 sed -i 's:v_'$i':v_'$i'_t:g'
done
for i in int64 uint64; do
  find modules -regextype sed -regex ".*\.\(h\|cpp\|hpp\|cu\|cc\)" -type f -print0 | xargs -0 sed -i 's/\([^a-z]\)'$i'\([^_a-zA-Z09]\)/\1'$i'_t\2/g'
  find modules -regextype sed -regex ".*\.\(h\|cpp\|hpp\|cu\|cc\)" -type f -print0 | xargs -0 sed -i 's/^'$i'\([^_a-zA-Z09]\)/'$i'_t\1/g'
done
sed -i 's:v_int64x:v_int64_tx:g' modules/core/include/opencv2/core/hal/intrin_neon.hpp
sed -i '299itypedef v_uint64_tx2 v_uint64x2;' modules/core/include/opencv2/core/hal/intrin_neon.hpp
sed -i '299itypedef v_int64_tx2 v_int64x2;' modules/core/include/opencv2/core/hal/intrin_neon.hpp
sed -i '299itypedef uint64x1_t uint64_tx1_t;' modules/core/include/opencv2/core/hal/intrin_neon.hpp
sed -i '299itypedef int64x1_t int64_tx1_t;' modules/core/include/opencv2/core/hal/intrin_neon.hpp

[pulkit15158]

@Dinesh13197 : Did you find a solution to this problem? I am integrating OpenCV with SystemC and I am facing the same issue. The def/undef solution is really ugly .

Hi did you find the solution for this?

[iegorval]

Almost 8 years later, and there is still no plan to do something about this issue?

[asmorkalov]

@mshabunin Could you take a look?

[mshabunin]

I think we need to:

• switch to C/C++ fixed-width types in our public interface
• make compatibility header for our internal usage and for people using our types in their code
• introduce policy requiring all new code to use standard types
• gradually replace internal usage

One thing which confuses me is that "(optional)" marker, it means that compiler/library may not define these types but I'm not aware of such cases.

Links:

• https://en.cppreference.com/w/cpp/types/integer
• https://en.cppreference.com/w/c/types/integer

[vrabaud]

@mshabunin , you can find an answer here https://stackoverflow.com/questions/32155759/state-of-support-for-the-optional-fixed-width-integer-types-introduced-in-c11 and especially here: https://cplusplus.github.io/LWG/issue2820 The types basically exist if the implementation guarantees they exist, which is what we want.