Back to the main page.
Bug 819 - ft_getopt.mexw64 depends on MSVC 2010 dll
| Status | CLOSED FIXED |
| Reported | 2011-07-15 08:53:00 +0200 |
| Modified | 2011-09-06 14:36:28 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P1 normal |
| Assigned to: | Jörn M. Horschig |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Robert Oostenveld - 2011-07-15 08:53:22 +0200
Created attachment 96 dll that needs to be redistributed with the mex file Hi Robert, it's in there, so we are allowed. Should I put it in the private-folder? Does it need to be autosynced? I attached the file just in case it is less work for you to do it than to explain it to me ;) Best, Jörn =========================================== On 7/14/2011 10:04 AM, Robert Oostenveld wrote: This pertains to http://msdn.microsoft.com/en-us/library/8kche8ah.aspx right? Can you check the Redist.txt file to see whether we are allowed to redistribute this with fieldtrip? Robert =========================================== On 14 Jul 2011, at 9:33, Jörn M. Horschig wrote: Hi Robert, I just ran the dependencywalker (which finds dlls needed for a specific mex-file), and I guess the problem might be the msvcr100.dll. My guess would be that we need to include this dll in FT. Since there is no compiler coming along with Win7, the users will have to either get the dll as a stand-alone version of by installing VS. Is there another possiblity? Best, Jörn =========================================== On 7/13/2011 4:33 PM, Robert Oostenveld wrote: Hi Jorn, But nevertheless it needs to be followed up ;-( At this moment the ft_getopt.mexw64 is not yet in utilities or the various private, but when it is all people will have the problem. Robert =========================================== On 13 Jul 2011, at 15:17, Marshall, T.R. (Tom) wrote: Hi Robert, Jorn, Thanks a lot for your help Robert. Following the best practices and running 'ft_defaults' rather than putting everything in the path seems to have fixed the problem. Therefore this is just a case of 'rtfm failure' :) Best, Tom ----- Original Message ----- From: "Robert Oostenveld"<r.oostenveld@example.com> To: "\"Jörn M. Horschig\""<jm.horschig@example.com>, "T.R. Marshall (Tom)"<t.marshall@fcexample.com> Sent: Wednesday, 13 July, 2011 2:51:04 PM Subject: Re: weird fieldtrip error Hi Tom I suspect it to be a problem with a *.dll that is missing (i.e. something from MSVC 2010 express). It might also be caused by a mismatch in the version that Jorn used to compile the mexw64 file (which he did yesterday) and the MATLAB version you are using. But first of all: you should not have added the src directory to your path. See http://fieldtrip.fcdonders.nl/faq/should_i_add_fieldtrip_with_all_subdirectories_to_my_matlab_path At this moment I don't have time to look into it further, but hopefully google can. Robert =========================================== On 13 Jul 2011, at 14:31, Jörn M. Horschig wrote: Hi Tom, I don't know what the error means. I hope Robert knows (I CCed him). To answer one of your question: a mex-file executes code from another programming language in Matlab, so e.g. a script written in C++ can be executed. This is way more efficient and thus faster than using a Matlab script (but requires programming experience in the programming language that you want to use). Best, Jörn =========================================== On 7/13/2011 2:27 PM, Marshall, T.R. (Tom) wrote: Hi Jorn, (disclaimer: I'm not sending this to the regular ft mailing list because I suspect it might concern the 'bleeding edge' version that we use at the DCCN specifically). I'm trying to do a simple tf analysis on my data and I get this error. *** ??? Invalid MEX-file 'H:\common\matlab\fieldtrip\src\ft_getopt.mexw64': The specified module could not be found. . Error in ==> ft_freqanalysis at 176 cfg.inputfile = ft_getopt(cfg, 'inputfile', []); *** I checked H:\common\matlab\fieldtrip\src\ and the file ft_getopt.mexw64 exists. I don't know what .mex files do, and have no idea how to interpret this error. I can't actually find that module referenced in either ft_freqnalaysis or ft_getopt (I searched both for 'w64' without success). So, what's going on here. Hope you can help me. Many thanks in advance! Tom
Robert Oostenveld - 2011-07-15 08:58:01 +0200
<<Hi Jorn, I decided to move the discussion over to bugzilla for easier tracking and future reference. Robert>> the dll would have to be in each directory where the mex file would be located, which means (almost) all private folders. I.e. the replication of the dll at multiple locations is the same as the replication of the mex file. what I wonder is why the other mexw64 files don't suffer from this. The content of the ft_getopt.c is very simple and based on that I would not expect any external dependencies. Might it be that those are compiled with another MSVC version (I know there is an express/free version from 2005 and 2008). You used 2010, right? Would it be possible to use another version of MSVC?
Jörn M. Horschig - 2011-07-15 10:30:40 +0200
hm, I am not sure if this is the root of the cause anymore, because I found that the msvcr100.dll is in my windows/system32 directory since March 18 2011, way before I installed VS... I will check at Tom's PC when he is in
Jörn M. Horschig - 2011-07-15 10:31:23 +0200
oh but btw, I tried installing VS 8 but it crashes at my pc :/
Jörn M. Horschig - 2011-07-18 10:52:27 +0200
I checked at Tom's and Ana's pc, they both only have msvcr80.dll
Jörn M. Horschig - 2011-07-29 10:58:37 +0200
okidoki, I managed to install MVSC 8 and compiled ft_getopt again. There seems to be no dependence to any special .dll anymore. I asked Tom to test it on his machine, as none else is currently my office and my machine seems to be not a neutral test machine. Update will follow shortly