make « Alec's Web Log

Posts Tagged ‘make’

Correct sse flags for compiling against embree with gcc

Tuesday, May 14th, 2013

I had trouble compiling against the embree raytracing library. I first tried compiling a small test problem with gcc (g++-mp-4.7) and immediately got errors:


error: '_mm_abs_epi32' was not declared in this scope
error: '_mm_shuffle_epi8' was not declared in this scope
error: '_mm_abs_epi32' was not declared in this scope

I tried adding the gcc flag -msse to no avail. I tried -mavx I got tons of errors like:


/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:20:no such instruction: `vxorps %xmm0, %xmm0,%xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:21:no such instruction: `vmovaps %xmm0, __ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:22:no such instruction: `vmovss LC0(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:23:no such instruction: `vmovaps %xmm0, 16+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:24:no such instruction: `vmovaps LC1(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:25:no such instruction: `vmovaps %xmm0, 32+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:26:no such instruction: `vmovaps LC2(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:27:no such instruction: `vmovaps %xmm0, 48+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:28:no such instruction: `vmovaps LC3(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:29:no such instruction: `vmovaps %xmm0, 64+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:30:no such instruction: `vmovaps LC4(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:31:no such instruction: `vmovaps %xmm0, 80+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:32:no such instruction: `vmovaps LC5(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:33:no such instruction: `vmovaps %xmm0, 96+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:34:no such instruction: `vmovaps LC6(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:35:no such instruction: `vmovaps %xmm0, 112+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:36:no such instruction: `vmovaps LC7(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:37:no such instruction: `vmovaps %xmm0, 128+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:38:no such instruction: `vmovaps LC8(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:39:no such instruction: `vmovaps %xmm0, 144+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:40:no such instruction: `vmovaps LC9(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:41:no such instruction: `vmovaps %xmm0, 160+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:42:no such instruction: `vmovaps LC10(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:43:no such instruction: `vmovaps %xmm0, 176+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:44:no such instruction: `vmovaps LC11(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:45:no such instruction: `vmovaps %xmm0, 192+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:46:no such instruction: `vmovaps LC12(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:47:no such instruction: `vmovaps %xmm0, 208+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:48:no such instruction: `vmovaps LC13(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:49:no such instruction: `vmovaps %xmm0, 224+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:50:no such instruction: `vmovaps LC14(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:51:no such instruction: `vmovaps %xmm0, 240+__ZL17_mm_lookupmask_ps(%rip)'

Finally I looked into the commands embree’s makefile was issuing to compile it in the first place and found the correct flag: -msse4.2.

Tags: avx, embree, g++, gcc, intel, intrinsics, make, sse, sse3, sse4, sse4.2
Posted in code | No Comments »

MATLAB mex file with boost (e.g. when using CGAL)

Friday, December 7th, 2012

On my laptop I have MATLAB2011b and I was able to compile a mex function using CGAL (and by dependency boost), just fine. When I tried this code on my iMac at work, the code compiled fine, but at runtime matlab crashed somewhere deep inside Cgal and boost:


[  0] 0x00000001000e4e46 /Applications/MATLAB_R2012b.app/bin/maci64/libmwfl.dylib+00036422 _ZN2fl4diag15stacktrace_base7captureERKNS0_14thread_contextEm+000150
[  1] 0x00000001000e5af1 /Applications/MATLAB_R2012b.app/bin/maci64/libmwfl.dylib+00039665 fl_diag_terminate+000321
[  2] 0x00000001000e7c34 /Applications/MATLAB_R2012b.app/bin/maci64/libmwfl.dylib+00048180 _ZN2fl4diag13terminate_logEPKcRKNS0_14thread_contextE+000100
[  3] 0x00000001008e125e /Applications/MATLAB_R2012b.app/bin/maci64/libmwmcr.dylib+00315998 mnTrapCtrlc+000254
[  4] 0x00000001008e2d24 /Applications/MATLAB_R2012b.app/bin/maci64/libmwmcr.dylib+00322852 _Z32mnRunPathDependentInitializationv+003492
[  5] 0x00000001008e313d /Applications/MATLAB_R2012b.app/bin/maci64/libmwmcr.dylib+00323901 _Z32mnRunPathDependentInitializationv+004541
[  6] 0x00000001008e37f5 /Applications/MATLAB_R2012b.app/bin/maci64/libmwmcr.dylib+00325621 _Z32mnRunPathDependentInitializationv+006261
[  7] 0x00000001008e3aa1 /Applications/MATLAB_R2012b.app/bin/maci64/libmwmcr.dylib+00326305 mnSIGABRTHandler+000129
[  8] 0x00007fff90d64cfa                  /usr/lib/system/libsystem_c.dylib+00666874 _sigtramp+000026
[  9] 0x00007fff6332b6f8                  /usr/lib/system/libsystem_c.dylib+18446744072944523000
[ 10] 0x00007fff90d03a7a                  /usr/lib/system/libsystem_c.dylib+00268922 abort+000143
[ 11] 0x0000000121634c3e              /opt/local/lib/gcc43/libgcc_s.1.dylib+00060478 uw_init_context_1+000142
[ 12] 0x0000000121635058              /opt/local/lib/gcc43/libgcc_s.1.dylib+00061528 _Unwind_Resume+000072
[ 13] 0x000000012106e2da /Users/ajx/Documents/volume/matlab/peeling/peeling.mexmaci64+00045786 mexFunction+001450
[ 14] 0x000000010550deca /Applications/MATLAB_R2012b.app/bin/maci64/libmex.dylib+00065226 mexRunMexFile+000090
[ 15] 0x0000000105509a29 /Applications/MATLAB_R2012b.app/bin/maci64/libmex.dylib+00047657 _ZN7Mfh_mex30runMexFileWithSignalProtectionEiPP11mxArray_tagiS2_+000137
[ 16] 0x000000010550b038 /Applications/MATLAB_R2012b.app/bin/maci64/libmex.dylib+00053304 _ZN7Mfh_mex13dispatch_fileEiPP11mxArray_tagiS2_+000232
[ 17] 0x00000001009dab43 /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_dispatcher.dylib+00314179 _ZN8Mfh_file11dispatch_fhEiPP11mxArray_tagiS2_+000499
[ 18] 0x0000000100d8b5b2 /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_interpreter.dylib+03278258 _ZN20ResolverFunctionDesc12CallFunctionEiPP11mxArray_tagiS2_+000914
[ 19] 0x0000000100d9287f /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_interpreter.dylib+03307647 _ZN8Resolver13CallMFunctionEiiP10_m_operandP17m_operand_storageiS1_S3_Pi+001679
[ 20] 0x0000000100d934e6 /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_interpreter.dylib+03310822 _Z22inResolveMFunctionCallP16_m_function_desciiP10_m_operandP17m_operand_storageiS2_S4_PiP13inMarshalTypeiPK19mpsTypeSequenceNlhsPFP11mxArray_tagiE+000598
[ 21] 0x0000000100bc9b4f /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_interpreter.dylib+01436495 _ZN9accelImpl13MFunctionCallEPP8_accelOp+000527
[ 22] 0x0000000100bf4b7e /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_interpreter.dylib+01612670 _ZN9accelImpl4ExecEv+000286
[ 23] 0x0000000100bf4c3b /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_interpreter.dylib+01612859 _ZNK9accelCode4CallEP13inMarshalTypePi+000091
[ 24] 0x0000000100d39f16 /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_interpreter.dylib+02944790 _ZN5inJit17ExecuteHotSegmentEP15_inJitAccelInfoP7opcodesPiPl+001654
[ 25] 0x0000000100b24361 /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_interpreter.dylib+00758625 _Z16inEnterDebugModeN5boost8functionIFvvEEEb+012273
[ 26] 0x0000000100b29c1c /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_interpreter.dylib+00781340 _Z18protected_inInterp12inDebugCheckii7opcodesPV15inPcodeNest_tagPl+000140
[ 27] 0x0000000100b2614e /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_interpreter.dylib+00766286 _Z16inEnterDebugModeN5boost8functionIFvvEEEb+019934
[ 28] 0x0000000100b27630 /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_interpreter.dylib+00771632 _Z26inExecuteMFunctionOrScriptP6Mfh_mpb+000688
[ 29] 0x0000000100b9482a /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_interpreter.dylib+01218602 _Z10inRunMfileiPP11mxArray_tagiS1_P6Mfh_mpP15inWorkSpace_tag+001530
[ 30] 0x00000001009dab43 /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_dispatcher.dylib+00314179 _ZN8Mfh_file11dispatch_fhEiPP11mxArray_tagiS2_+000499
[ 31] 0x0000000100b76a5a /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_interpreter.dylib+01096282 _Z19inDispatchFromStackiPKcii+001034
[ 32] 0x0000000100b02979 /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_interpreter.dylib+00620921 inCallFcnFromReference+000265
[ 33] 0x0000000100b23125 /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_interpreter.dylib+00753957 _Z16inEnterDebugModeN5boost8functionIFvvEEEb+007605
[ 34] 0x0000000100b29c1c /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_interpreter.dylib+00781340 _Z18protected_inInterp12inDebugCheckii7opcodesPV15inPcodeNest_tagPl+000140
[ 35] 0x0000000100b2614e /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_interpreter.dylib+00766286 _Z16inEnterDebugModeN5boost8functionIFvvEEEb+019934
[ 36] 0x0000000100b27630 /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_interpreter.dylib+00771632 _Z26inExecuteMFunctionOrScriptP6Mfh_mpb+000688
[ 37] 0x0000000100b9482a /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_interpreter.dylib+01218602 _Z10inRunMfileiPP11mxArray_tagiS1_P6Mfh_mpP15inWorkSpace_tag+001530
[ 38] 0x00000001009dab43 /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_dispatcher.dylib+00314179 _ZN8Mfh_file11dispatch_fhEiPP11mxArray_tagiS2_+000499
[ 39] 0x0000000100b62904 /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_interpreter.dylib+01014020 _Z23inEvalPcodeHeaderToWordP15_memory_contextiPP11mxArray_tagP12_pcodeheaderP6Mfh_mpj+000260
[ 40] 0x0000000100b1c162 /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_interpreter.dylib+00725346 _Z25in_local_call_with_setjmpIN5boost3_bi6bind_tIvPFvP15_memory_contextPiPP11mxArray_tagP12_pcodeheaderjENS1_5list5INS1_5valueIS4_EENS0_3argILi1EEENSG_ILi2EEENSE_ISA_EENSE_IiEEEEEEE17inExecutionStatusT_S5_S8_b+000082
[ 41] 0x0000000100b187f5 /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_interpreter.dylib+00710645 _ZN7EvalLog6setLogEiPP11mxArray_tagiS2_+003381
[ 42] 0x0000000100b18b75 /Applications/MATLAB_R2012b.app/bin/maci64/libmwm_interpreter.dylib+00711541 _ZN7EvalLog6setLogEiPP11mxArray_tagiS2_+004277
[ 43] 0x000000010640058e /Applications/MATLAB_R2012b.app/bin/maci64/libmwbridge.dylib+00058766 _Z28evalCommandWithLongjmpSafetyPKc+000094
[ 44] 0x0000000106400d8b /Applications/MATLAB_R2012b.app/bin/maci64/libmwbridge.dylib+00060811 _Z28evalCommandWithLongjmpSafetyRKSbItSt11char_traitsItESaItEE+000043
[ 45] 0x000000010640181d /Applications/MATLAB_R2012b.app/bin/maci64/libmwbridge.dylib+00063517 _Z8mnParserv+001021
[ 46] 0x00000001008c4139 /Applications/MATLAB_R2012b.app/bin/maci64/libmwmcr.dylib+00196921 _ZN11mcrInstance30mnParser_on_interpreter_threadEv+000041
[ 47] 0x000000010089e76b /Applications/MATLAB_R2012b.app/bin/maci64/libmwmcr.dylib+00042859 _ZN3mcr7runtime17InterpreterThread4Impl17InvocationRequest3runEv+000523
[ 48] 0x000000010089e925 /Applications/MATLAB_R2012b.app/bin/maci64/libmwmcr.dylib+00043301 _ZN3mcr7runtime17InterpreterThread4Impl26invocation_request_handlerEl+000053
[ 49] 0x000000010042f574 /Applications/MATLAB_R2012b.app/bin/maci64/libmwservices.dylib+00107892 _ZN10eventqueue18UserEventQueueImpl5flushEv+000756
[ 50] 0x000000010042f79a /Applications/MATLAB_R2012b.app/bin/maci64/libmwservices.dylib+00108442 _ZN10eventqueue8ReadPipeEib+000026
[ 51] 0x000000010042df26 /Applications/MATLAB_R2012b.app/bin/maci64/libmwservices.dylib+00102182 _ZN10eventqueue18UserEventQueueImpl9selectFcnEb+000326
[ 52] 0x0000000107d26a9d /Applications/MATLAB_R2012b.app/bin/maci64/libmwuix.dylib+00170653 _ZN21uix_nodisplay_ppeHook16pollingDuringFcnEb+000045
[ 53] 0x00000001004d71b2 /Applications/MATLAB_R2012b.app/bin/maci64/libmwservices.dylib+00795058 _ZSt8for_eachIN9__gnu_cxx17__normal_iteratorIPN5boost8weak_ptrIN4sysq10ws_ppeHookEEESt6vectorIS6_SaIS6_EEEENS4_8during_FIS6_NS2_10shared_ptrIS5_EEEEET0_T_SH_SG_+000162
[ 54] 0x00000001004d8dab /Applications/MATLAB_R2012b.app/bin/maci64/libmwservices.dylib+00802219 _ZN4sysq12ppe_for_eachINS_8during_FIN5boost8weak_ptrINS_10ws_ppeHookEEENS2_10shared_ptrIS4_EEEEEET_RKS9_+000203
[ 55] 0x00000001004d592c /Applications/MATLAB_R2012b.app/bin/maci64/libmwservices.dylib+00788780 _ZN4sysq19ppePollingDuringFcnEb+000092
[ 56] 0x00000001004d5ac7 /Applications/MATLAB_R2012b.app/bin/maci64/libmwservices.dylib+00789191 _ZN4sysq11ppeMainLoopEiib+000119
[ 57] 0x00000001004d5c94 /Applications/MATLAB_R2012b.app/bin/maci64/libmwservices.dylib+00789652 _ZN4sysq11ppeLoopIfOKEiib+000132
[ 58] 0x00000001004d5e34 /Applications/MATLAB_R2012b.app/bin/maci64/libmwservices.dylib+00790068 _ZN4sysq20processPendingEventsEiib+000132
[ 59] 0x000000010089ea9f /Applications/MATLAB_R2012b.app/bin/maci64/libmwmcr.dylib+00043679 _ZN3mcr7runtime17InterpreterThread4Impl14process_eventsERKN5boost10shared_ptrIS2_EE+000223
[ 60] 0x000000010089f2ca /Applications/MATLAB_R2012b.app/bin/maci64/libmwmcr.dylib+00045770 _ZN3mcr7runtime17InterpreterThread4Impl3runERKN5boost10shared_ptrIS2_EEPNS2_12init_contextE+000282
[ 61] 0x0000000100897176 /Applications/MATLAB_R2012b.app/bin/maci64/libmwmcr.dylib+00012662 _Z26run_init_and_handle_eventsPv+000054
[ 62] 0x00007fff90d108bf                  /usr/lib/system/libsystem_c.dylib+00321727 _pthread_start+000335
[ 63] 0x00007fff90d13b75                  /usr/lib/system/libsystem_c.dylib+00334709 thread_start+000013

At first I thought it was a problem of compiling against the CGAL that came with macports rather than a version inside on matlab. But actually it seems matlab no longer contains the libCGAL libraries. I did however see the boost libraries there. When I checked the libraries of my mex file using:


otool -L myfunction.mexmaci64

I saw:


myfunction.mexmaci64:
	/opt/local/lib/libCGAL.10.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/local/lib/libCGAL_Core.10.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/local/lib/libgmp.10.dylib (compatibility version 11.0.0, current version 11.5.0)
	/opt/local/lib/libmpfr.4.dylib (compatibility version 6.0.0, current version 6.1.0)
	/opt/local/lib/libboost_thread-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
	/opt/local/lib/libboost_system-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libmx.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libmat.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libmex.dylib (compatibility version 0.0.0, current version 0.0.0)
	/opt/local/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.17.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
	/opt/local/lib/gcc47/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

libboost_*-mt are the boost libraries that come from macports. Inside of matlab these are just libboost_* (without the -mt). After switching my make file to link against these:


-L$MATLAB/bin/maci64/ -lboost_thread -lboost_system

I used otool again and confirmed that I linked against matlab’s boost:


myfunction.mexmaci64:
	/opt/local/lib/libCGAL.10.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/local/lib/libCGAL_Core.10.dylib (compatibility version 10.0.0, current version 10.0.0)
	@rpath/libgmp.3.dylib (compatibility version 8.0.0, current version 8.1.0)
	@rpath/libmpfr.1.dylib (compatibility version 3.0.0, current version 3.2.0)
	@rpath/libboost_thread.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libmx.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libmat.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libmex.dylib (compatibility version 0.0.0, current version 0.0.0)
	/opt/local/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.17.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
	/opt/local/lib/gcc47/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

I tried running my mex file and indeed this worked.

Update: This also happens when calling mex directly. Somehow matlab still finds the wrong boost libs.

Tags: boost, CGAL, gcc, mac os x, make, matlab, mex
Posted in code | No Comments »

Bash script to find best number of threads for make’s -j option

Friday, November 16th, 2012

The make command lets you specify a number of processes to run commands on using the -j option. I’ve read of a heuristic to use 1.5 times the number of cores on your machine. To find out if this is true I wrote a short script:


#!/bin/bash

for i in {1..20}
do
  make clean &>/dev/null
  printf "$i  "
  t=`(time make -j$i &>/dev/null) 2>&1 | grep real | sed -e "s/real[^0-9]*//g"`
  echo "$t"
done

For my project on my iMac with an intel i7 this prints:

1  1m1.235s
2  0m32.128s
3  0m23.353s
4  0m19.989s
5  0m18.007s
6  0m16.613s
7  0m15.490s
8  0m15.644s
9  0m16.307s
10  0m16.415s
11  0m16.861s
12  0m17.535s
13  0m17.053s
14  0m17.112s
15  0m17.550s
16  0m17.267s
17  0m17.274s
18  0m17.618s
19  0m17.540s
20  0m17.653s

Obviously you could improve the accuracy of these timing by running multiple times and averaging.

Tags: make, multicore, parallel, process, thread
Posted in code | No Comments »

Porting Marco Attene’s meshfix to mac os x

Wednesday, November 14th, 2012

Short notes on porting meshfix to mac.

Follow readme.txt placing downloaded OpenNL and JMeshLib directories in the mesh fix directory [same as meshfix.cpp]

When compiling JMeshLib be sure in makeconf file to change the lines:


# On 64-bit machines you need to uncomment the following line
# -DIS64BITPLATFORM

MOREFLAGS = $(OPTM) $(STRICTALIAS)

to:


MOREFLAGS = $(OPTM) $(STRICTALIAS) -DIS64BITPLATFORM

When compiling JMeshExt I separated the predicates.cxx file from tetgen’s source to make jrs_predicates.h and jrs_predicates.c. Placing them according to readme.txt. One note is that if jrs_predicates.c is to be a .c file rather than a .cpp file then you need to extern "C"{...} encapsulate the jrs_predicates.h header file or you will get Undefined symbol linker errors.

Finally in JMeshExt and meshfix.cpp there are several casts of pointers to ints. This won’t compile on 64-bit machines. This similar operation was fixed in JMeshLib by the -DIS64BITPLATFORM. Thus, I’ve fixed the following files to use the j_voidint typedef defined by IS64BITPLATFORM in j_mesh.h:


JMeshExt-1.0alpha_src/src/holeFilling.cpp
meshfix.cpp

I’ve zipped up my changes and organization: download package. Then you can just issue:


cd OpenNL3.2.1/
./configure.sh 
cd build/Darwin-Release/
make
cd ../../../JMeshLib-1.2/
make
cd ../JMeshExt-1.0alpha_src/
make
cd ..
make

I imagine a very similar port could be used for Linux.

Update: I started occasionally getting runtime errors:


OpenNL should not have reached this point: file:/Users/ajx/Downloads/MeshFix/OpenNL3.2.1/src/NL/nl_superlu.c, line:223
Abort trap: 6

Seems this comes from compiling OpenNL without SuperLU support. SuperLU is fairly straightforward to install and so is following the OpenNL instructions for compiling with OpenNL support.

Tags: jmesh, jmeshlib, make, marco attene, mesh, mesh repair, meshfix, opennl, predicates
Posted in code | No Comments »

Linking against static library using Eigen produces many `direct access ... to global weak symbol` warnings

Friday, April 13th, 2012

Our group builds a static library of useful functions implemented using the Eigen matrix library in C++. We build the library with a standard Makefile and gcc. But when I try to link against this library in an Xcode project (which also used Eigen) I got many warnings from the linker of the form:


ld: warning: direct access in void Eigen::internal::computeProductBlockingSizes<float, float, 4>(long&, long&, long&)to global weak symbol Eigen::internal::manage_caching_sizes(Eigen::Action, long*, long*)::m_l2CacheSizemeans the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.

There seem to be no problems at runtime, but nonetheless it’s annoying to have so many warnings.

To make the warnings go away, I went to my project settings in Xcode and made sure that Symbols Hidden by Default was set to No.

Tags: eigen, gcc, ld, llvm, make, warning, xcode
Posted in code | No Comments »

Patch for colormake to properly handle redirecting std err

Friday, February 10th, 2012

I started using colormake which is a great little perl script that wraps the make command, colorizing its output. I liked it so much that I quickly decided to make an alias in my bash .profile so that whenever I called make I would actually run colormake:


alias make=colormake

Note: The original colormake script is called cmake, but I renamed it to colormake to avoid conflict with the cmake.

This was going fine until I want to actually play with my typical make output. One thing I like to be able to do is redirect all of my errors to a file:


make 2>make.err

My alias to colormake broke this because the first thing the colormake wrapper does is redirect all of make’s std err output to std out.

Here’s my patch to the colormake (cmake) script that more properly deals with stderr. I also provide a fix to the errors from using stty incorrectly (though I actually don’t like the extra feature of colormake which trims commands to fit the window):


#!/bin/bash
#
# Wrapper around make to colorize its output.
#
# This patch fixes problems with calling stty in a script and redirecting std
# err
#

## use terminal size but avoid "stty: stdin isn't a terminal" warning from stty 
#STTY_SIZE=`stty size 2>/dev/null`
# Don't pass a terminal size (soft wrap entire commands)
STTY_SIZE=""

if [ -t 1 ];
then
  # Std out is tty
  if [ -t 2 ];
  then
    # Std err is tty
    make $* 2>&1 | colormake.pl $STTY_SIZE                                                              
    ret_val=${PIPESTATUS[0]}
  else
    # Std err is not tty
    # only pipe std out to colormake
    make $* | colormake.pl $STTY_SIZE                                                              
    ret_val=${PIPESTATUS[0]}
  fi
else
  # Std out is not tty
  make $*
  ret_val=$? 
fi                                                                                        
exit $ret_val

Update: Using PIPESTATUS I made sure that this script returns the return code of the make call.

Tags: bash, cmake, colormake, make, perl, std err, std out, stty
Posted in code | No Comments »

Compiling, installing and using AntTweakBar on Mac OS X, as a static library

Monday, October 4th, 2010

I recently posted about compiling and installing the very cool prototyping UI library, AntTweakBar, on Mac OS X.

That post describes how to compile as a dynamic library, which is great for development of many different projects on the same machine. But when I want to show my app to others the last thing I want is for them to have to compile all of the dependencies as global dynamic libraries. Instead I’d rather package up my binary with statically linked dependency libraries.

So after a bit of a struggle over my lack of experience with gcc and even contacting AntTweakBar’s developer, I’ve found at least one way to compile AntTweakBar as a static library on Mac OS X, universal for 32-bit or 64-bit apps.

Dowload the source from the AntTweakBar site.

Go to the source directory:


cd AntTweakBar/src

Make some changes to the Makefile.osx. Edit the lines to look like this


SO_EXT          = .a

#---- Release
CXXCFG          = -O3 -arch i386 -arch x86_64

and


$(TARGET): $(OBJS)
        #@echo "===== Link $@ ====="
        #$(LINK) $(LFLAGS) -dynamiclib -Wl,-undefined -Wl,dynamic_lookup  -o $(OUT_DIR)/lib$(TARGET)$(SO_EXT) $(OBJS) $(LIBS)
        @echo "===== Archive $@ ====="
        $(AR) $(OUT_DIR)/lib$(TARGET)$(SO_EXT) $(OBJS)

Depending on your OS version you may have to adjust this line, too:


BASE            = /Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks

Copy Makefile.osx over the exisiting Makefile:


cp Makefile.osx Makefile

Then build with


make

You may see some suspicious looking output like:


ranlib: archive library: ../lib/libAntTweakBar.a will be fat and ar(1) will not be able to operate on it
ranlib: for architecture: i386 file: ../lib/libAntTweakBar.a(TwPrecomp.o) has no symbols
ranlib: for architecture: x86_64 file: ../lib/libAntTweakBar.a(TwPrecomp.o) has no symbols

But I haven't run into any problems with this yet...

Now go over to the examples:


cd ../examples

You can compile the GLUT example with:


gcc -O3 -arch i386 -arch x86_64 -Wall -fno-strict-aliasing -D_MACOSX TwSimpleGLUT.c -framework OpenGL -framework GLUT -framework AppKit -L../lib -lAntTweakBar -lstdc++ -o TwSimpleGLUT -I ../include

You'll notice a couple more links in this compile command than when using the dynamic library. The most important to notice is the -lstdc++ which is a little weird but definitely needed (you could switch gcc to g++, instead, too). There were other link options in the original Makefile.osx that don't seem necessary for this example, but maybe for others... I'm not sure.

Update: A couple people have been getting the following error on the final ar line of the makefile:


===== Archive AntTweakBar =====
ar cqs ../lib/libAntTweakBar.a TwColors.o TwFonts.o TwOpenGL.o TwBar.o TwMgr.o TwPrecomp.o LoadOGL.o TwEventGLFW.o TwEventGLUT.o TwEventSDL.o
ar: ../lib/libAntTweakBar.a: Inappropriate file type or format
make: *** [AntTweakBar] Error 1

Here's how I fixed this with in at least one case. Delete the incomplete libAntTweakBar.a file:


rm ../lib/libAntTweakBar.a

Then issue:


ar r ../lib/libAntTweakBar.a TwColors.o TwFonts.o TwOpenGL.o TwBar.o TwMgr.o TwPrecomp.o LoadOGL.o TwEventGLFW.o TwEventGLUT.o TwEventSDL.o

You may see a warning like:


ar r ../lib/libAntTweakBar.a TwColors.o TwFonts.o TwOpenGL.o TwBar.o TwMgr.o TwPrecomp.o LoadOGL.o TwEventGLFW.o TwEventGLUT.o TwEventSDL.o
ar: creating archive ../lib/libAntTweakBar.a
/usr/bin/ranlib: file: ../lib/libAntTweakBar.a(TwPrecomp.o) has no symbols

This is OK, I've been told by the AntTweakBar developer that this file is ignored anyway if you're not on windows.

Then you should be able to compile and run the example above.

Tags: anttweakbar, ar, c#, compile, g++, gcc, glut, ld, make, opengl, ranlib
Posted in code | 4 Comments »

Compiling, installing and using AntTweakBar on Mac OS X

Monday, August 30th, 2010

Seeing Bruno Levy‘s demos at SIGGRAPH 2010 convinced me that I want to start using the painlessly easy prototyping GUI library, AntTweakBar. The premise of AntTweakBar is great. Prototyping should be easy and a researcher shouldn’t spend any time on UI that just flips flags and changes input parameter values. With AntTweakBar UI is added with a single line of code for any variable you want to expose. Moreover AntTweakBar figures out which type of UI element should show up: switches for bools, RGB/HSV value manipulators for colors, spinners for numbers. And it’s all Glut and OpenGL (and DirectX I guess), which for most is exactly what they’re already using.

Compiling and installing AntTweakBar as a dynamically linked library on a mac is a bit tricky though. Here’s what I did:

Dowload the source from the AntTweakBar site.

Go to the source directory:


cd AntTweakBar/src

I had to make some changes to the Makefile.osx. Edit the lines to look like this


CXXCFG          = -O3 -arch i386 -arch x86_64
LFLAGS          = -arch i386 -arch x86_64
OUT_DIR         = /usr/local/lib

BASE            = /Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks

I want to compile AntTweakBar universally (32-bit and 64-bit) for a 10.6 machine so I need those -arch options. You can leave those out if you just want the default setting.

Copy Makefile.osx over the exisiting Makefile:


cp Makefile.osx Makefile

Then build with


sudo make

This will put the dylib in the right place so you don't have to mess with DYLD_LIBRARY_PATH each time you link to AntTweakBar

Since I've installed libAntTweakBar.dylib all the way at the /usr/local/ level, I'll also put the header file there:


sudo cp ../include/AntTweakBar.h /usr/local/include

Now, hop over to the examples directory:


cd ../examples

Now you should be able to universally compile a simple example with the following:


gcc -O3 -arch i386 -arch x86_64 -Wall -fno-strict-aliasing -D_MACOSX TwSimpleGLUT.c -lAntTweakBar -lpthread -lm -framework OpenGL -framework GLUT -o TwSimpleGLUT

And run it with:


./TwSimpleGLUT

And you should get something like this:

Update:
Mac ports does have a port for AntTweakBar, but it's always such a nightmare dealing with the 32-bit/64-bit problem with mac ports so I have done the above. With macports you can just issue:


sudo port install anttweakbar

And you should be able to compile and run the example in the same manner.

Tags: 10.6, anttweakbar, dylib, gcc, glut, i386, mac os x, macports, make, opengl, x86_64
Posted in code | 3 Comments »

taucs on Mac OS X

Tuesday, July 13th, 2010

Yesterday I spent way too long trying to get taucs compiled and linking on a Mac machine running OS X 10.6.

Because my Qt is compiling for 32 bits I needed a 32-bit/i386 libtaucs.a, this was not so easy. I began hoping to compile a universal library, but couldn’t manage to do it. I’ve previously posted about how to compile a 64-bit version of taucs on a mac 10.6 machine (this was not so bad).

Update: Thanks to the useful comment below, I’ve modify these steps so that the result is a unviersal (32-bit and 64-bit) libtaucs.a

Part one: Compiling libtaucs.a (universal)

In the taucs directory (here on out [taucs] issue the following:


cp config/darwin.mk config/darwin10.0.mk

Then open up config/darwin10.0.mk and edit the following lines to look like this:


CFLAGS    = -arch i386 -arch x86_64 -O3 -faltivec


LIBBLAS   = -framework Accelerate
LIBLAPACK = -framework Accelerate
LIBMETIS  = -lmetis


LIBF77 = -lf2c

Now, this part is really messy but hopefully I’ll remember everything I did. Before compiling libtaucs.a we need to compile libf2c.a and libmetis.a, and we need to do it so that both are at least i386. I think I managed to get mine to both be universal (i386 and x86_64).

So, I’ve stripped these commands out of the buildf2c.sh script. Issue them in a terminal:


curl http://netlib.sandia.gov/cgi-bin/netlib/netlibfiles.tar?filename=netlib/f2c -o "f2c.tar"
tar -xvf f2c.tar
gunzip -rf f2c/*
cd f2c
unzip libf2c.zip -d libf2c
cd ..
sed 's/CC = cc/CC = \/usr\/bin\/cc/' f2c/libf2c/makefile.u > f2c/libf2c/makefile
sed 's/CC = cc/CC = \/usr\/bin\/cc/' f2c/src/makefile.u > f2c/src/makefile

At this point we need to edit the makefiles to make sure that they build universal libraries:

In libf2c/makefile edit the following lines to look like this:


CFLAGS = -arch x86_64 -arch i386 -O
LDFLAGS += -arch x86_64 -arch i386

# compile, then strip unnecessary symbols
.c.o:
        $(CC) -c -DSkip_f2c_Undefs $(CFLAGS) $*.c
#        ld $(LDFLAGS) -r -x -o $*.xxx $*.o
#        mv $*.xxx $*.o

AND AGAIN in src/makefile edit the following lines to look like this:


CFLAGS = -arch x86_64 -arch i386 -O
LDFLAGS += -arch x86_64 -arch i386

# compile, then strip unnecessary symbols
.c.o:
        $(CC) -c -DSkip_f2c_Undefs $(CFLAGS) $*.c
#        ld $(LDFLAGS) -r -x -o $*.xxx $*.o
#        mv $*.xxx $*.o

Note: Be sure to comment out the ld ... and mv ... lines above.

Now back to compiling:


cd f2c/libf2c
make f2c.h
if test ! -d /usr/local/include; then
    sudo mkdir -p /usr/local/include
fi
sudo cp f2c.h /usr/local/include/
make
if test ! -d /usr/local/lib; then
    sudo mkdir -p /usr/local/lib
fi
sudo cp libf2c.a /usr/local/lib/
sudo ranlib /usr/local/lib/libf2c.a
cd ../src
make
if test ! -d /usr/local/bin; then
    sudo mkdir -p /usr/local/bin
fi
sudo cp f2c /usr/local/bin/
cd ..
chmod +x fc
sudo cp fc /usr/local/bin
sudo ln  -s /usr/local/bin/fc /usr/local/bin/f77
sudo chmod +x /usr/local/bin/f77

~~Following the rest of the buildf2c.sh on your own to build the executables.~~

Next, we need to compile libmetis.a.

Download and unzip the source then in the metis folder edit Makefile.in:


# What options to be used by the compiler
COPTIONS = -arch i386 -arch x86_64

# What options to be used by the loader
LDOPTIONS = -arch i386 -arch x86_64

Then issue:


make

and then


sudo cp libmetis.a /usr/local/lib/

Now, finally, go back to [taucs]. Here you can issue:


./configure
make

This should produce a universal libtaucs.a library.

Part two: Using libtaucs.a

You should have no problem compiling any of the examples, like those in [taucs]/progs, as long as you include the right headers and the library. For example I can issue the following (be sure to replace the [taucs]s):


cc -arch i386 -o direct [taucs]/progs/direct.c \
-I[taucs]/src/ -I[taucs]/build/darwin10.0/ \
-L[taucs]/lib/darwin10.0/ -ltaucs -framework \
Accelerate -lmetis -lf2c


cc -arch x86_64 -o direct [taucs]/progs/direct.c \
-I[taucs]/src/ -I[taucs]/build/darwin10.0/ \
-L[taucs]/lib/darwin10.0/ -ltaucs -framework \
Accelerate -lmetis -lf2c

Though I do get the warning:


In file included from taucs_with_LU/src/taucs.h:7,
                 from taucs_with_LU/progs/direct.c:17:
taucs_with_LU/build/darwin10.0/taucs_config_build.h:5:24: warning: missing whitespace after the macro name

This is because of a #define that uses darwin10.0 and periods are not allowed.

Update:

If you are using a mac then taucs will try to define a macro called OSTYPE and set it to an invalid c value: darwin10.0 (invalid because of the period). As a result whenever you include taucs.h you’ll get hundreds of warnings. I fix this by opening [taucs]/build/taucs_config_build.h and commenting out the following lines before I make:


/* This is an automatically generated file */
/* Configuration name: anonymous */
//#define TAUCS_OSTYPE darwin10.0
...
//#define OSTYPE_darwin10.0
...

You should also be able to compile this simple c program, saved in taucs_super_simple.c:


#include <taucs.h>
int main(int argc, char* argv[])
{
  double x = taucs_get_nan();
  return 1;
}

I can compile and run this with:


cc -arch i386 -o taucs_super_simple taucs_super_simple.c \
-I[taucs]/src/ -I[taucs]/build/darwin10.0/ \
-L[taucs]/lib/darwin10.0/ -ltaucs -framework Accelerate
./taucs_super_simple

Now if you try the same simple program, naively translated to cpp like this, saved in taucs_super_simple.cpp:


extern "C"{
#include <taucs.h>
}
int main(int argc, char* argv[])
{
  double x = taucs_get_nan();
  return 1;
}

and you try to compile with something like this:


c++ -arch i386 -o taucs_super_simple taucs_super_simple.cpp \
-I[taucs]/src/ -I[taucs]/build/darwin10.0/ \
-L[taucs]/lib/darwin10.0/ -ltaucs -framework Accelerate

You’ll get a bagillion of these errors:


/usr/include/c++/4.2.1/complex:1104: error: template with C linkage

That’s because taucs.h uses some complex library that is weird. Not sure why exactly you have to do this, but just add:


#include <complex>

above

extern "C"{
#include <taucs.h>
}

Do this anytime you include taucs. This should now compile with the above command.

Tags: 10.6, 32, c#, compile, f2c, i386, mac os x, make, metis, snow leopard, taucs, x86_64
Posted in code | 13 Comments »

Vim syntax highlighting for Qt’s .pro files

Tuesday, July 13th, 2010

I use the following at the end of my .vimrc file to force vim to highlight Qt’s .pro project files like a make file:


au BufNewFile,BufRead *.pro set filetype=make

Looks much better than whatever it was trying to do before.

Tags: highlighting, make, qt, syntax, vi, vim, vimrc
Posted in code | 1 Comment »

Alec's Web Log

Posts Tagged ‘make’

Correct sse flags for compiling against embree with gcc

MATLAB mex file with boost (e.g. when using CGAL)

Bash script to find best number of threads for make’s -j option

Porting Marco Attene’s meshfix to mac os x

Linking against static library using Eigen produces many `direct access ... to global weak symbol` warnings

Patch for colormake to properly handle redirecting std err

Compiling, installing and using AntTweakBar on Mac OS X, as a static library

Compiling, installing and using AntTweakBar on Mac OS X

taucs on Mac OS X

Part one: Compiling libtaucs.a (universal)

Part two: Using libtaucs.a

Vim syntax highlighting for Qt’s .pro files

Categories

Links

Archives

Posts Tagged ‘make’

Part one: Compiling libtaucs.a (universal)

Part two: Using libtaucs.a

Categories

Links

Archives

Tag Cloud