Troubleshooting and FAQ

1. Read Me First
2. What does "failed to map segment from shared object: operation not permitted" mean?
3. Ok, I followed your instructions for win32, so why do I get "access denied" with respect to the mex-file?
4. It still doesn't work!!! Now I get "the specified module could not be found"
5. I don't see netcdf.dll in the windows distribution. Where is it?
6. I just downloaded the Windows R2006a version. So where's mexnc.dll?
7. Where's the 64-bit mex-file for Windows
8. How can I test mexnc?
9. MATLAB complains about GLIBC_2.3 on R14 Linux x86
10. Why does the test suite fail on me?
11. Why do I get the following message everytime I use SNCTOOLS with java?

     ??? Error using ==> snctools\private\nc_info_java
    Could not open netCDF URL.
    

12. What about the netcdf-4 beta?
13. What about the NetCDF Toolbox?
14. I get "??? Invalid MEX-file" when trying to compile with linux. What's up with that?

1. Read Me First: Before doing anything else, you should check to see that your versions of the software are current. The ChangeLog file in each of the mexnc, snctools, and netcdf_toolbox directories should tell you the version release numbers. It may be that the mex-file most appropriate for your architecture is a bit behind the current release. That's all the more reason for you to compile your own version.

   Also, you should see what the following commands tell you before contacting me (because this will most likely be the first bit of information I ask of you). The paths may be slightly different on your system...

   • >> which( 'mexnc', '-all' )
     C:\path\to\mexnc\mexnc.dll            % on windows, will be mexnc.w32 on R2006a and higher
     

     Other platforms should see their appropriate mex-file extensions.

   • >> which( 'mexcdf53', '-all' )
     C:\path\to\mexnc\mexcdf53.m         
     

     Mexcdf53 used to be the mex-file itself, but no longer. Now it is only an m-file that funnels its arguments into the real mex-file, mexnc. If your matlab path reflects a mex-file, then you should remove it from the matlab path.
2. Q: What does "failed to map segment from shared object: operation not permitted" mean?

   A: This might show up on linux if the partion under which you installed mexnc is mounted with the noexec option. Check your /etc/fstab file to see if this is the case. If it is, you need to either remove the noexec option and remount the partition, or just move mexnc to another partition.

3. Q: Ok, I followed your instructions for win32, so why do I get "access denied" with respect to the mex-file?

   A: Check that the folder containing "mexnc.mexw32" has appropriate permissions. Specifically,

   1. Right click on the folder containing the mex-file
   2. Click on the "Security" tab.
   3. Do you have "Full control"?
   You also may want to check with your IT staff as to whether or not any security policies are in place that prevent third party applications from functioning.
4. Q: It still doesn't work!!! Now I get the specified module could not be found

   A: Check the location where you actually placed the netcdf.dll. It must lie somewhere on your system path. Not your matlab path, but your system path. Something like either C:\path\to\matlab\bin or C:\path\to\matlab\bin\win32

5. Q: I don't see the file "netcdf.dll" file. Where is it?

   A: It's there. Check the win32 directory. DO NOT, I repeat, DO NOT use a DLL from a prior installation, and do not download the DLL from Unidata.

6. Q: I just downloaded the R2006a version for Windows. So where is mexnc.dll?

   A: It ain't there. As of R2006a, the new mex-file is called "mexnc.mexw32".

7. Q: Where's the 64-bit mex-file for Windows?

   A: It ain't there either, because no one has built it and contributed it back. If you had any guts, you'd do it for me.

8. Q: How can I test mexnc?

   A: There is a test suite contained in the "test" subdirectory underneath mexnc. But don't bother with this unless you are either source-compiling your own mex-file or are convinced that something is horribly wrong with your installation!

   Now, go back and read that last sentence one more time.

   If you absolutely must run the tests, make sure you follow the directions in the README in that subdirectory.

   The following command, though, is a real simple way of testing if the mex-file is completely wrong for you.

   >> mexnc ( 'STRERROR', 0 )
   

   If the result is not

   ans =
   
   No error
   
   

   then yes, you are right, something is horribly, horribly wrong.

9. Q: I have a real ancient version of glibc, 2.2 or less. When I try to use mexnc on R14 linux x86, the first thing it says is something to the effect of

   ??? Invalid MEX-file '/path/to/mexnc/mexnc.mexglx': /lib/i686/libc.so.6: version `GLIBC_2.3' not found 
   (required by /path/to/mexnc/mexnc.mexglx).
   

   A: Check your version of glibc (especially if you are using a debian system). It would seem that mex-files compiled on versions of glibc greater than 2.3 won't work with systems with glibc 2.2 or less. This is a case where you end up having to compile your own mex-file. You should search out the section of the mexopts.sh file for CFLAGS that reads

   CFLAGS='-fPIC -ansi -D_GNU_SOURCE -pthread -fexceptions -m32'
   

   and get rid of the -m32 flag, which changes it to

   CFLAGS='-fPIC -ansi -D_GNU_SOURCE -pthread -fexceptions'
   

   MEXNC should now compile cleanly and run.

10. Q: Why does the test suite fail on me?

    A: About the only good reason to run the test suite is if you are compiling your own version and want to contribute it back to me so I can post it for the benefit of others (in which case, thank you). Otherwise you really don't need to do that unless you suspect that there's a problem with your installation. Really.

    Ok, fine, don't listen to me. If you must plow foreward with this, make sure you read the instructions carefully and agree with the questions that the test suite asks you. And then, if it still doesn't work, email me.

11. Q: Why do I get the following message everytime I use SNCTOOLS with java?

     ??? Error using ==> snctools\private\nc_info_java
    Could not open netCDF URL.
    

    A: Did you add the toolsUI jar file to your path using javaaddpath? Check the README.

12. Q: Can mexnc work with the netcdf-4 beta?

    A: Yes, it will work just fine, but the normal build process will not work. Because HDF5 1.6.5 is a required component of MATLAB, and because netCDF-4 requires HDF5-1.8.0, one cannot get away with shared libraries. Everything has to be statically compiled, which results in a pretty big makefile (and a pretty big mex-file, the x86_64 version currently weighs in at 9.7 MB). Here's a makefile which will work on x86_64

    HDF=/path/to/hdf5
    NETCDF=/path/to/netcdf4
    MATLAB=/path/to/your/matlab
    CC=gcc
    
    INCLUDES=-I${MATLAB}/extern/include 
    INCLUDES+=-I${HDF}/include 
    INCLUDES+=-I${NETCDF}/include 
    INCLUDES+=-I${HDF}/include
    
    CFLAGS=-c -DMATLAB_MEX_FILE -g -fPIC -fno-omit-frame-pointer -ansi 
    CFLAGS+= -D_GNU_SOURCE -pthread -fexceptions -DMX_COMPAT_32
    
    LDFLAGS=-g -pthread -shared 
    LDFLAGS+= -Wl,--version-script,${MATLAB}/extern/lib/glnxa64/mexFunction.map 
    LDFLAGS+= -Wl,--no-undefined 
    
    LPATH= -L${NETCDF}/lib -L${HDF}/lib -L${MATLAB}/bin/glnxa64 
    LIBS=-lmx -lmex -lmat -lm -lstdc++ -lnetcdf -lhdf5 -lhdf5_hl -lhdf5  -lz
    
    
    OBJECTS=mexgateway.o netcdf2.o netcdf3.o common.o mexversion.o
    
    mexversion.o:  ${MATLAB}/extern/src/mexversion.c
    	${CC} ${CFLAGS} ${INCLUDES} $<
    
    %.o: %.c
    	${CC} ${CFLAGS} ${INCLUDES} $<
    
    mexnc: ${OBJECTS}
    	${CC} ${LDFLAGS} ${OBJECTS} -o mexnc.mexa64 ${LPATH} ${LIBS}
    	
    clean:
    	rm -f *.o
    
    

14. What about the NetCDF Toolbox?

    So what about it? It's completely unsupported. Use it at your own risk.

15. Q: The following was seen on a Fedora Core 5 machine with R14 SP2 where mexnc was compiled with gcc 4.1. I'm using Matlab R14 SP2.

    ??? Invalid MEX-file '/home/jevans/matlab/mexcdf/mexnc/mexnc.mexglx': 
    /opt/matlabR14sp2/bin/glnx86/../../sys/os/glnx86/libgcc_s.so.1: 
    version `GCC_4.2.0' not found (required by /usr/lib/libstdc++.so.6).
    

    A: You really shouldn't be seeing this anymore... but ...

    The problem is basically a mismatch between the version of gcc und the C++ libraries used to compile matlab, and the versions found the current system. According to Mathworks, we have

    • R13 compiled with gcc-2.95.3, libstdc++ 2.9 or below
    • R14 compiled with gcc-3.2.3, libstdc++.so.5
    • R2006a compiled with gcc-3.4.5, libstdc++.so.6
    So, you really should try to get yourself versions of gcc and libstdc++ that are as close as possible to these. Check with your friendly neighborhood sysadmin for details.

    Now suppose you have Mandriva 2007. Here are your options.

    • gcc-4.1.1 and libstdc++6-4.1.1-3mdk are installed by default. Therefore this is well-suited for R2006a. Mexnc should compile with no problems.
    • gcc-3.3.6 and libstdc++5 can be expected to work with R14. In this case, just add a line down at the bottom of the mexopts.sh file that reads

      #############################################################################
      #
      # Architecture independent lines:
      #
      #     Set and uncomment any lines which will apply to all architectures.
      #
      #----------------------------------------------------------------------------
                 CC="gcc-3.3.6"
      

    • gcc2.96 and libstdc++2.10 can be expected to work with R13. The mexopts.sh fragment in this case is

      #############################################################################
      #
      # Architecture independent lines:
      #
      #     Set and uncomment any lines which will apply to all architectures.
      #
      #----------------------------------------------------------------------------
                 CC="gcc2.96"
      

    Actually, I've never witnessed a problem with Mandriva and compiling mexnc, it's usually been Fedora Core or RedHat...

    The other trick to try is alluded to in the file ${MATLAB}/sys/os/glnx86/README.libstdc++, but you need to be the root user. Type these commands ...

    # cd $MATLAB
    # cd sys/os/glnx86
    # mkdir old
    # mv libstdc++.* libg2c.* libgcc_s* old
    

When matlab is restarted, it will then use the system libraries instead of those supplied by Mathworks. And then all is fine and well with the world. Note that if this sort of thing happens with an x86-64 machine, then the directory in question would be ${MATLAB}/sys/os/glnxa64 instead of ${MATLAB}/sys/os/glnx86.