为SWIG指定Python头文件与库：多版本Python编译问询

Alright, let’s break down your current workflow to spot risks and actionable improvements:

1. Outdated SWIG Version is a Critical Red Flag #

SWIG 1.3.4 is ancient (released around 2009), while Python 3.3 launched in 2012. This version of SWIG has minimal, unpolished support for Python 3.x—you’ll almost certainly run into bugs like broken Unicode handling, incorrect Python 3 C API usage (e.g., relying on Python 2-style module initialization), or missing support for core Python 3 features. This is the biggest threat to your build working reliably.

2. Compilation Command Has Link Order Problems #

GCC’s linker is order-sensitive: libraries must come after the source files that depend on them. Your current command places -lpython3.3m and other libraries before mylib_wrap.cxx, which can trigger unresolved symbol errors. The linker processes libraries in the order given, so if a library is listed before the code that needs it, it might skip symbols it thinks are unnecessary.

3. Static Linking Carries Risks #

Statically linking libz and boost_date_time-mt with -Wl,-Bstatic works, but has downsides:

• It bloats the size of your final shared library.
• Boost libraries have strict ABI compatibility rules—if your static Boost build uses different compiler flags than your system’s dynamic libraries, you could hit runtime crashes.
• If boost_date_time-mt depends on other dynamic libraries (like pthread), static linking it might leave those dependencies unresolved unless you explicitly link them.

Optimizations & Fixes #

Upgrade SWIG Immediately #

Grab a SWIG version with proper Python 3.3 support. The minimum viable release is SWIG 2.0.10 (the first version with solid Python 3 compatibility), but I’d recommend a newer stable build like SWIG 3.0.12 or 4.x if possible. This will eliminate most Python 3 compatibility headaches out of the box.

Rewrite Your Compilation Command #

Fix the argument order to follow GCC’s standard convention: compiler flags → source files → include paths → library paths → libraries. Here’s the adjusted command:

g++ -O2 -fPIC -shared mylib_wrap.cxx \
  -I.. \
  -I/opt/rh/python33/root/usr/include/python3.3m \
  -I/server/zodiac/include \
  -L/opt/rh/python33/root/usr/lib64 \
  -Wl,-Bstatic -lz -lboost_date_time-mt -Wl,-Bdynamic \
  -lpython3.3m -lbz2 -lpthread -lrt -ldl \
  -s

• Moved mylib_wrap.cxx right after core compiler flags (-O2, -fPIC, -shared)
• Grouped include paths (-I) together before library paths (-L)
• Placed all dependent libraries after the source file to ensure proper symbol resolution
• Kept your static/dynamic linking split but positioned it logically

Reconsider Static Linking #

Unless you have a strict requirement to statically link zlib and Boost, switch to dynamic linking by removing the -Wl,-Bstatic and -Wl,-Bdynamic flags. This keeps your library smaller and avoids ABI compatibility issues. If static linking is mandatory, use ldd on the static Boost archive to verify it has no hidden dynamic dependencies.

Verify Python 3.3 Alignment #

• Ensure your shell environment points to Python 3.3 when running SWIG (set PYTHONHOME=/opt/rh/python33/root if needed)
• After generating the wrapper, skim mylib_wrap.cxx to confirm it uses Python 3-specific API calls like PyModule_Create instead of Python 2’s Py_InitModule

Test Thoroughly #

After compiling, launch your Python 3.3 interpreter and try importing the generated .so module. If you get errors:

• Use nm -D your_module.so to check for unresolved symbols
• Confirm all include paths point to Python 3.3 headers (not Python 2.7)
• Verify Boost libraries are compiled with the same compiler and flags as your wrapper

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