OpenCV3与OpenCV2冲突原因咨询：ROS+ORB-SLAM2环境问题

Great question—let’s break down exactly what’s happening here, beyond just "it’s a conflict" and why this isn’t a simple multiple-definition error.

1. The Link-Time Warning: What It’s Telling You #

That linker warning /usr/bin/ld: warning: libopencv_imgproc.so.3.2, needed by ../../../../lib/libORB_SLAM2.so, may conflict with libopencv_imgproc.so.2.4 is a red flag for mixed library dependencies:

• Your ORB-SLAM2 library was compiled against OpenCV 3.2, so it explicitly links against OpenCV 3’s shared libraries.
• Your ROS nodes are built against OpenCV 2.4.8, so they link against OpenCV 2’s libraries.
• The linker detects that your final executable will depend on both versions of the same library (same name, different version numbers). It doesn’t throw an error here because the libraries are in separate files, but it’s warning you that this will almost certainly cause runtime issues.

2. The Runtime Error: Why It’s Not a Multiple-Definition Issue #

The cvGetFileNodeByName invalid pointer error is a classic case of ABI (Application Binary Interface) incompatibility, not a compile-time multiple-definition problem:

• Multiple-definition errors happen at link time when two different implementations of the same symbol (function/variable) are found in the same scope, and the linker can’t choose which one to use. That’s not what’s happening here.
• Instead, here’s the sequence of events:
  1. Your ROS code uses OpenCV 2 to create a CvFileStorage object (a C API structure).
  2. ORB-SLAM2 code (compiled against OpenCV 3) tries to call cvGetFileNodeByName on that same CvFileStorage pointer.
  3. OpenCV 3 modified the internal memory layout of CvFileStorage compared to OpenCV 2—even though the function name is the same, the expected structure size and fields are different.
  4. When the OpenCV 3 version of cvGetFileNodeByName tries to access the OpenCV 2 CvFileStorage, it reads invalid memory, triggering the "invalid file storage pointer" error.

This happens because dynamic linkers resolve symbols by name at runtime. If both OpenCV 2 and 3 libraries are loaded, the linker will pick whichever version was loaded first for any shared symbol names—meaning your code ends up mixing function implementations from two incompatible library versions, operating on mismatched data structures.

3. Why Your Fix Worked #

By uninstalling OpenCV 3 and standardizing on OpenCV 2.4.8, you ensured:

• All parts of your project (ROS nodes + ORB-SLAM2) are compiled against and linked to the same library version.
• There’s no ambiguity in symbol resolution at runtime—every call to an OpenCV function uses the implementation that matches the data structures your code creates.

Bonus: Alternative Fixes (If You Needed to Keep OpenCV 3) #

If you ever need to use both versions, you could:

• Build ORB-SLAM2 in an isolated workspace with its own environment variables pointing to OpenCV 3, so it doesn’t pollute the ROS environment’s OpenCV 2 dependencies.
• Use static linking for ORB-SLAM2 (link against static OpenCV 3 libraries), embedding its required OpenCV code directly into libORB_SLAM2.so instead of relying on dynamic shared libraries.

内容的提问来源于stack exchange，提问作者Lee Eugene