MATLAB - Error compiling jpeg_read.c to create mexmaci64 file [duplicate] - matlab

This question already has an answer here:
mex compilation error C2440: 'initializing': cannot convert from 'const mwSize *' to 'const int32_t *'
(1 answer)
Closed 6 months ago.
recently I moved my Matlab project from windows OS to Mac OS. so my jpeg_read.mexw64 file didn't work anymore and I needed to create a new mexmaci64 file that is compatible with Mac OS.
I Downloaded JpegToolbox from here and then installed Libjpeg using:
brew install libjpeg
in Matlab I tried to use mex:
>> mex -setup
MEX configured to use 'Xcode with Clang' for C language compilation.
To choose a different language, select one from the following:
mex -setup C++
mex -setup FORTRAN
MEX configured to use 'Xcode Clang++' for C++ language compilation.
>>
but when I try:
mex -I/usr/local/Cellar/jpeg/9d/include jpeg_read.c -L/usr/local/Cellar/jpeg/9d/lib
Matlab returns the following error:
Building with 'Xcode with Clang'.
/Users/folder/jpeg_toolbox/jpeg_read.c:294:39: warning: incompatible pointer types passing 'int [2]' to parameter of type 'const mwSize *' (aka 'const unsigned long *') [-Wincompatible-pointer-types]
mxtemp = mxCreateCharArray(2,dims);
^~~~
/Applications/Polyspace/R2020a/extern/include/matrix.h:958:91: note: passing argument to parameter 'dims' here
LIBMMWMATRIX_PUBLISHED_API_EXTERN_C mxArray *mxCreateCharArray(mwSize ndim, const mwSize *dims);
^
1 warning generated.
Error using mex
Undefined symbols for architecture x86_64:
"_jpeg_CreateDecompress", referenced from:
_mexFunction in jpeg_read.o
"_jpeg_destroy_decompress", referenced from:
_mexFunction in jpeg_read.o
"_jpeg_finish_decompress", referenced from:
_mexFunction in jpeg_read.o
"_jpeg_read_coefficients", referenced from:
_mexFunction in jpeg_read.o
"_jpeg_read_header", referenced from:
_mexFunction in jpeg_read.o
"_jpeg_save_markers", referenced from:
_mexFunction in jpeg_read.o
"_jpeg_std_error", referenced from:
_mexFunction in jpeg_read.o
"_jpeg_stdio_src", referenced from:
_mexFunction in jpeg_read.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
now how can I compile the program? Otherwise, does any of you have already got the mexmaci64 I would need?

This error typically happens when a MEX-file uses int instead of mwSize for the sizes of an array. Only very old MEX-file code still does this.
For these MEX-files, you need to add -compatibleArrayDims to the mex command when compiling. It causes the compiler to select the old 32-bit API instead of one of the newer 64-bit ones. This does limit the maximum size of arrays, but only in a way that is consistent with limits at the time the MEX-file was written.
The alternative solution is to rewrite the MEX-file to use a newer API.

Related

Using xerces in Eclipse cdt produces linking error

Building C++ app using xerces, here is where it worked, on the build part
g++ -I/usr/local/include/xercesc -O0 -g3 -Wall -c -fmessage-length=0 -v -MMD -MP -MF"mypoject/xercesserver.d" -MT"myproject/xercesserver.o" -o "myproject/xercesserver.o" "../myproject/xercesserver.c"
...etc,etc, blah, blah, blah
Here is where it failed, linking
gcc -L/usr/local/lib -lxerces-c -o "myprojectapp" ./myproject/textfileread.o ./myproject/xercesserver.o
Undefined symbols for architecture x86_64:
"vtable for __cxxabiv1::__class_type_info", referenced from:
typeinfo for xercesc_3_2::XMLDeleter in xercesserver.o
NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
"operator delete(void*)", referenced from:
xercesc_3_2::XMLDeleter::~XMLDeleter() in xercesserver.o
"___cxa_begin_catch", referenced from:
_main in xercesserver.o
"___cxa_end_catch", referenced from:
_main in xercesserver.o
"___gxx_personality_v0", referenced from:
xercesc_3_2::XMLDeleter::~XMLDeleter() in xercesserver.o
_main in xercesserver.o
Dwarf Exception Unwind Info (__eh_frame) in xercesserver.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Mac 10.13.1 High Sierra, Xerces 3.2, Eclipse Oxygen 3.a, CDT 9.4.3, gcc g++ both
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.0.0 (clang-900.0.39.2)
Target: x86_64-apple-darwin17.2.0
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
A symbolic link, g++ -> gcc , but binaries differ in /usr/bin though same size.
Problem originated by creating C++ Project, C Managed Build, instead of a C++ Project, C++ Managed Build, which then necessitated the corrective given below. I had begun working on a C code project and later realized I needed the xerces code, which of course is C++. Otherwise you would just need to add the library as in the following image.
Note that the actual file's name is libxerces-c.a in the directory /usr/local/lib but Eclipse wants you to just give the root name, meaning xerces-c.
Now for the error caused by creating a C Managed build, a good clue was found here: How can I fix g++ Undefined symbols for architecture x86_64 error?
Problem finding this was partly that Eclipse is using g++ for the compiling but then gcc by default for the linking. So the problem is really how to fix gcc, not g++, and then the solution is actually to switch to g++. Also xerces FAQs brings up similar issues with different solutions. Attached pix shows the place to fix in Eclipse.

Swift 2.2 undefined symbols preventing build

I'm trying to build a project with the new release of the open source Swift 2.2 compiler and am running into a few issues.
A minimal example like this:
.
├── Package.swift
└── Sources
└── main.swift
Package.swift
import PackageDescription
let package = Package(
name: "foo",
dependencies: []
)
main.swift
print("foo")
run via swift build throws the following:
Compiling Swift Module 'foo' (1 sources)
Linking Executable: .build/debug/foo
Undefined symbols for architecture x86_64:
"__TFSSCfT21_builtinStringLiteralBp8byteSizeBw7isASCIIBi1__SS", referenced from:
_main in main.swift.o
"__TFs5printFTGSaP__9separatorSS10terminatorSS_T_", referenced from:
_main in main.swift.o
"__TIFs5printFTGSaP__9separatorSS10terminatorSS_T_A0_", referenced from:
_main in main.swift.o
"__TIFs5printFTGSaP__9separatorSS10terminatorSS_T_A1_", referenced from:
_main in main.swift.o
"__TMSS", referenced from:
_main in main.swift.o
"__TTSg5P____TFs27_allocateUninitializedArrayurFBwTGSax_Bp_", referenced from:
_main in main.swift.o
"__TZvOs7Process11_unsafeArgvGSpGSpVs4Int8__", referenced from:
_main in main.swift.o
"__TZvOs7Process5_argcVs5Int32", referenced from:
_main in main.swift.o
"_globalinit_33_1BDF70FFC18749BAB495A73B459ED2F0_func5", referenced from:
_main in main.swift.o
"_globalinit_33_1BDF70FFC18749BAB495A73B459ED2F0_token5", referenced from:
_main in main.swift.o
ld: symbol(s) not found for architecture x86_64
<unknown>:0: error: build had 1 command failures
swift-build: exit(1): ["/Library/Developer/Toolchains/swift-2.2-SNAPSHOT-2015-12-01-a.xctoolchain/usr/bin/swift-build-tool", "-f", "/Users/kilian/Desktop/foo/.build/debug/foo.o/llbuild.yaml"]
Swift is Apple Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift 778f82939c) Target: x86_64-apple-macosx10.9 as provided on swift.org.
The only troubleshooting info regarding this I can find online corresponds to Xcode and linking other external libraries. Any help here would be much appreciated.
I haven't tried the new open source Swift on my Mac yet, focusing on playing with it on Linux instead. However, one way something like this could happen on Linux is when Clang is not available. In that case swift REPL and swift as an interpreter work fine, but swiftc and swift build fail. Just out of curiosity you may want to try
swiftc main.swift
in your Sources directory. Google for xcode command line tools mac os x or a combination of those search terms. The following, for example, might help:
https://developer.apple.com/library/ios/technotes/tn2339/_index.html
To see if your command tools are available, try clang or gcc from the command line. If you get a message that there are no input files, then the tools are installed (maybe incorrectly). If you get some other error, then the tools aren't there, and that's a very likely cause of your problem.
Hope this helps.

Using C++ library with Matlab

Hi I read one similar question- on using mex + nvcc linker problems with standard library. My problem is similar as I have code which compiles Ok with gcc on the Mac OS X. ( I am a beginner)
Code
gcc -lstdc++ trnr.c -o trnr works fine
Error
But I get these errors when I use mex
Building with 'Xcode with Clang'.
Error using mex
Undefined symbols for architecture x86_64:
"_mexFunction", referenced from:
-exported_symbol[s_list] command line option
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Not sure how to procede can anyone help

Liblinear on mac osx 10.9.3

Environment : Matlab R2014a (8.3), Macosx mavericks 10.9.3, Apple LLVM version 5.1 (clang-503.0.40)
I am compiling the liblinear package from http://www.csie.ntu.edu.tw/~cjlin/liblinear/. I fixed the mexopts.h in the matlab installation directory to point to right SDKROOT, C and CXX. When I run make from inside matlab under the director liblinear-1.94/matlab/, the libsvmread and libsvmwrite successfully generated the mexmaci64 library. However, it did not generate for train and predict. Hence I commented the try catch expection in the make, to understand the error. Now I getting the following error.
Error using mex
Undefined symbols for architecture x86_64:
"_daxpy_", referenced from:
TRON::tron(double*) in tron.o
TRON::trcg(double, double*, double*, double*) in tron.o
"_ddot_", referenced from:
TRON::tron(double*) in tron.o
TRON::trcg(double, double*, double*, double*) in tron.o
"_dnrm2_", referenced from:
TRON::tron(double*) in tron.o
TRON::trcg(double, double*, double*, double*) in tron.o
"_dscal_", referenced from:
TRON::trcg(double, double*, double*, double*) in tron.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
Error in make (line 16)
mex CFLAGS="\$CFLAGS -std=c99 -v" -largeArrayDims train.c
linear_model_matlab.c ../linear.cpp ../tron.cpp
"../blas/*.c"
Any idea why am I getting this error?
It looks like the program is looking for the files in the blas folder.
I got the exact same error when trying to add liblinear manually to my c++ using cmake (with the new ranksvm- so I couldn't brew) . I solved this by adding the .o AND the blas/.o files as sources to my project.
...using this as an analogy perhaps you only included the liblinear folder and not the folder and all its contents in your Matlab project?
Dylib in x86_64
First of all, let's make sure that the liblinear (or whichever library that you are linking to) dylib is in x86_64, or at least universal (i386 + x86_64) format.
$ file /usr/local/Cellar/liblinear/1.94/lib/liblinear.dylib
/usr/local/Cellar/liblinear/1.94/lib/liblinear.dylib: Mach-O 64-bit dynamically linked shared library x86_64
If you install your libraries via Homebrew, this should not be a problem.
GNU Libtool
Another instance where I frequently see the ld: symbol(s) not found for architecture x86_64 is when I compile node.js modules using GNU's libtool. If you install GNU Libtool, try uninstalling/unlinking it

compile error when using cv::minMaxLoc() on iOS

I am using OpenCV on iOS, the project works fine and can detect harris corners but when I try to use the following line I get a compile error:
cv::minMaxLoc(cornerStrength,&minStrength,&maxStrength);
The error from xcode is:
Undefined symbols for architecture armv7:
"___udivmodsi4", referenced from:
cv::minMaxIdx(cv::_InputArray const&, double*, double*, int*, int*, cv::_InputArray const&)in OpenCV(stat.o)
ld: symbol(s) not found for architecture armv7
collect2: ld returned 1 exit status
Any advice much appreciated as I cant find a way past this at the moment.
Cheers,
Fraser
If you are using LLVM GCC 4.x, try changing the compiler to Apple LLVM 3.x, that did the trick for me.