`ld x86_64 error` under mac os mojave (10.14+) with darwin kernel 18+

[FFengIll]

For macos mojave, compile failed for ld (x86_64) error. Under mac os mojave (10.14+) with darwin kernel 18+.

Undefined symbols for architecture x86_64:
  "_IRConst_U32", referenced from:
      _zero_division_side_exits in postprocess.o
  "_IRConst_U64", referenced from:
      _zero_division_side_exits in postprocess.o
  "_IRExpr_Binop", referenced from:
      _zero_division_side_exits in postprocess.o
  "_IRExpr_Const", referenced from:
      _mips32_post_processor_fix_unconditional_exit in postprocess.o
      _zero_division_side_exits in postprocess.o
  "_IRExpr_RdTmp", referenced from:
      _zero_division_side_exits in postprocess.o
  "_IRStmt_Exit", referenced from:
      _zero_division_side_exits in postprocess.o
  "_IRStmt_WrTmp", referenced from:
      _zero_division_side_exits in postprocess.o
  "_LibVEX_Init", referenced from:
      _vex_init in pyvex.o
  "_LibVEX_Lift", referenced from:
      _vex_lift in pyvex.o
  "_LibVEX_Update_Control", referenced from:
      _vex_lift in pyvex.o
  "_LibVEX_default_VexAbiInfo", referenced from:
      _vex_init in pyvex.o
  "_LibVEX_default_VexArchInfo", referenced from:
      _vex_init in pyvex.o
  "_LibVEX_default_VexControl", referenced from:
      _vex_init in pyvex.o
  "_addStmtToIRSB", referenced from:
      _irsb_insert in postprocess.o
      _zero_division_side_exits in postprocess.o
  "_newIRTemp", referenced from:
      _zero_division_side_exits in postprocess.o
  "_sizeofIRType", referenced from:
      _collect_data_references in analysis.o
  "_typeOfIRExpr", referenced from:
      _get_default_exit_target in analysis.o
      _collect_data_references in analysis.o
      _zero_division_side_exits in postprocess.o
  "_typeOfIRTemp", referenced from:
      _collect_data_references in analysis.o
ld: symbol(s) not found for architecture x86_64

[FFengIll]

A solution is (only for mine now): add -arch x86_64 into CFLAS in vex. but add -arch i386 into CFLAS in pyvex/pyvex_c. So the version can be link and built.

But some *.o lost (of course, the arch is not compatible).

[rhelmot]

None of us have a macOS install available, so we can't fix this or test any fix you give us. Submit a pull request once you have a solution and we'll try to get someone to test it?

[FFengIll]

It takes some time to confirm the question and solution.

The question comes from ar (for static lib) - mac xcode utils is different with gnu utils (or others) in this version, so different compile tool chain will report different error or generate different result (especially when the tools in PATH are incompatible - no right error report, no real error report). (for me, I have 2 chains)

mac xcode ar has different options with linux. some ld flags may need to change, too.

I am not sure the solution is safe enough to PR, I will take more chance to test more.

Furthermore, may keep this issue as tips.

some references here:

https://stackoverflow.com/questions/22107616/static-library-built-for-archive-which-is-not-the-architecture-being-linked-x86

[jace0x21]

I ran into this issue trying to build pyvex on MacOS 10.14.3. Switching to the ar that ships with xcode over the GNU ar fixed the linking issue. I think the recommended fix should just be to make sure the xcode ar is being used.