problem with rfsub.f

[GoogleCodeExporter]

What steps will reproduce the problem?

When I'm trying to compile the code I get the following error:

Compiling rfsub.f (fortran subroutines)
gfortran   -O2 -fpic -march=native -c src/rfsub.f -o rfsub.o
src/rfsub.f:0: error: bad value (native) for -march= switch
src/rfsub.f:0: error: bad value (native) for -mtune= switch


Have you ever crossed with the same issue?
Any help is appreciated.

MJ

Original issue reported on code.google.com by m.se...@gmail.com on 5 Jun 2012 at 11:07

[GoogleCodeExporter]

in the Makefile 
http://code.google.com/p/randomforest-matlab/source/browse/trunk/RF_Class_C/Make
file#25

remove -mtune=native and that should fix the problem

regards

Original comment by abhirana on 5 Jun 2012 at 11:40

[GoogleCodeExporter]

Thanks!
The thing is I'm running the code on CentOs linux and I see a weird behavior:
After I run the "model = classRF_train( a,b );" command it goes to the prompt 
line, i.e. I see ">>", but matlab is freezed and I can't do anything. When I 
check the cpu usage I see that matlab is still working.
I thought recompiling the whole thing might help but it didn't.

Well... I guess it is not easy for you to address this one but I write this 
comment just in case that someone knows the solution.

Best,
MJ

Original comment by m.se...@gmail.com on 6 Jun 2012 at 4:58

[GoogleCodeExporter]

I found out that the problem is that Matlab doesn't return from the 
"classRF_train.m" and "classRF_predict.m" files. So if I save the outputs at 
the very end of these matlab scripts and also add a "quit" command at the end 
of these files everything works fine. In other words the problem is not in the 
mex files.

This is a hack and I'm still working to see how I can fix this minor issue.

Best,
MJ

Original comment by m.se...@gmail.com on 6 Jun 2012 at 8:19

[GoogleCodeExporter]

actually there may a couple of reasons for this happening.

usually march and mtune flags should work for gfortran if its a new version 
do a gfortran -v and a g++ -v the version number should be nearby and if not it 
may create issues when linking. anything about 4.1.x should be ok

the other possible issue might be that particular version of gfortran and g++ 
don't work well in conjunction with malloc and matlab. try to sync with the svn 
source which replaces mallocs by matlab based malloc mxMalloc 
http://code.google.com/p/randomforest-matlab/source/checkout

actually issues do happen even when matlab has returned from mex (but it still 
is a mex issue)

Original comment by abhirana on 6 Jun 2012 at 10:36