I am working on a MATLAB project which we want to export as .exe. The resulting file must then be able to run on both 32 and 64-bits Windows 7 PCs.
After a little research we realized this problem was easier to approach by developing on a 32-bit version of MATLAB building then a 32-bits .exe file.
Till this point, all our development was being carried in the 64-bits version of MATLAB. With it we had been able to successfully generate and run 64-bits .exe versions.
Now that we switched to MATLAB 32-bits, however, and we generate the .exe, something goes wrong and the following error is shown:
Undefined function ‘fmincon’ for input arguments of type ‘function handle’.
This is the line of code in which fmincon first appears:
Options = optimoptions('fmincon', 'DiffMinChange', 10);
A few remarks:
The same scripts which worked on MATLAB 64-bits also work on MATLAB
32-bits. Within the MATLAB environment, everything runs smoothly.
The scripts (with the same exact code) can still be made executable on MATLAB 64-bits without any problem.
In both cases, we properly installed the runtime required for the MATLAB executable to be run on the PC.
We have tried to run the 32-bits .exe in both 64-bits and 32-bits machines with the same result.
Is it possible that the 32-bits version of MATLAB's deployed executable has problems dealing with functions from the Optimization Toolbox (as fmincon is)?
What else could be the cause of this problem? Does anyone have an idea how to fix it?
The problem was only solved thanks to MATLAB's support. This is related to a bug in version R2014a, explained and patched in this Mathworks link.
Related
Version: Python 3.7 (Spyder) -- OS: Windows10 -- System: Core i5 (6th gen) + 16gb RAM
I wrote a program which handles a lot of data. The following structure is used to accomplish this:
Program Description
A GUI interface is used as a main function (class). In here an interface pops up, asks the user for input, uses this input the make all kinds of calculation, which are specified in different functions.
The first function is an import function, where in a specified (by user) folder is searched for all .wav files and where the data of these are imported. All imported items are appended (numpy.append) to one big array.
The big array (for 20 files about 2.000.000.000 datapoints) is used to calculated characteristics of the sound file. The reason it has so many datapoints is because the samplerate of the .wav file is set on 78125 samples/s, which I need for accurate calculations.
After the calculations, 2 plots are generated in a specified folder and 2 csv's are also stored in that folder with the requested data.
Problem Statement
Running the main function (program) in the spyder environment, works totally fine. It take about 10 minutes to go through all the data and generates the output.
Compiling the function to an .exe using PyInstaller, works fine, no errors, everything dependency imported. However when running the program a MemoryError pops up almost immediatly (see image below).
Image: error message from command line when executing the exe file
Tried solutions
Running the python script via CLI, gives the same error
Running the .exe program with only 2 files to import, works all file, but incredibly slow (much slower than executed via spyder)
Questions
Why has spyder enough memory to process all data with no problems, but when executing the .py via command line or when executing the .exe file, there is always a memory error?
Why does the .exe or the .py via CL run slower than in the spyder IDE?
Goal
This program should be able to process noise data on every laptop in the company (also 8gb ram sometimes). So I want to find a way to let the program allocate all available RAM on the used machine.
Thanks in advance, for any help!
Meanwhile I have found the answer to my question thanks to Axe319:
The Spyder IDE was running on a 64bit version of python, making the program run smoothly and without any issues. Nevertheless my python interpreter was still a 32bit version of python.
Steps taken to solve the problem:
uninstall python 32bit version
install python 64bit version
install all used packages again using pip install -packages-
install PyInstaller again using pip install pyinstaller
Compile the program to .exe using PyInstaller
After this all seems to be working!
This question already has answers here:
What is the bit size of long on 64-bit Windows?
(8 answers)
Determining 32 vs 64 bit in C++
(16 answers)
Closed 3 years ago.
I am using Debian 9 (stable) and I recently decided to install mingw-w64 so that I could do cross platform C/++ development since I don't have consistent access to a Windows machine. When I had first installed it a couple days ago to test out doing 32 and 64-bit builds, it seemed to work but now the 64-bit command (x86_64-w64-mingw32-gcc) seems to only put out 32-bit executables despite the fact that it should only put out 64-bit by default. I even explicitly declared the options -m64 and -march=x86_64 in an attempt to force it, but it seems like no matter what I try now it will only do a 32-bit build.
For reference, all the code consists of is three files: hello.c, hellofunc.c, and hellofunc.h. The file hello.c simply calls a function defined in hellofunc.c called printHelloWorld:
void printHelloWorld(void){
long z;
printf("Hello World!\n");
switch(sizeof(z)){
case 4:
printf("This program is 32-bit\n");
break;
case 8:
printf("This program is 64-bit\n");
break;
default:
printf("This program is of unknown bit size\n");
}
printf("Long int size is %i bytes long!\n", sizeof(z));
}
With the expected output being "This program is 32-bit" or 64-bit, with an explicit statement showing the byte length of a long variable. The problem I am having is that despite the fact that the 64-bit mingw-w64 gcc command is being used, when I do test it on Windows it will display the 32-bit message and a byte length of 4 instead of the expected 8.
Again, when I initially tested it right after download it worked as expected and I have no idea what could have changed the default functionality of it over the last couple of days- I didn't install anything new, and all I was doing was trying to work with makefiles (this directory does not contain one though). Also, for the record, the default gcc native to my Debian system works perfectly well with the -m32 and -m64 commands so it's not like my system isn't capable of it and... in fact, if anything, I would expect the behavior to be backwards as Linux seems to require special set-up to do 32-bit builds or run 32-bit programs on a 64-bit machine.
For the last attempt to understand the problem myself I ran the command x86_64-w64-mingw32-gcc -v -o hello.exe hello.c hellofunc.c -I . so that I could get the full command sequence of the compiler, and I also ran gcc on it as well. Here is the full output I put on pastebin just for reference. I don't 100% understand the output, but it seriously looks like all the configuration and options should be outputting 64-bit?? I don't know, I'm still pretty new to Linux and still don't entirely understand how to dissect when something goes wrong- especially when something runs counter to the explicitly defined functionality lol.
If somebody could recommend possible fixes for this or alternatives I probably didn't think of, I would really appreciate. I tried Googling for answers before hand, but x86_64-w64-ming32-gcc seems to only ever come up in conversation to tell newbies that it's the obvious default way to compile for 64-bit architecture.
Thanks for reading and any help you can give, cheers~
I'm midway through a VHDL class and have been able to play relatively nice with the ISE and Digilent toolchain in Linux... until trying to reflash a PicoBlaze program. For details, I am currently running and targeting,
Fedora 21 64-bit (3.19.3-200.fc21.x86_64)
Nexys2 development board from Digilent (with a Spartan3)
Xilinx ISE 14.7
Adept 2.16.1 Runtime
Adept 2.2.1 Utilities
I've been able to run ISE and program the Nexys2 bit files with iMPACT just fine so far in Linux, but this current project is to write an assembly program for the PicoBlaze soft core processor, compile and update the memory of the running vector without having to resynthesize any VHDL.
Using the steps from Kris Chaplin's post, I can compile a PSM to HEX and then convert that HEX file to an SVF in dosbox. From here I can use Digilent's Adept tool in Windows to program a top_level.bit file which has the PicoBlaze already synthesized, I could also do this in ISE's iMPACT in Linux. After the design is running, I can use Adept to program the SVF file into the running memory of the design and everything is peachy. However, trying to load the SVF into iMPACT in Linux throws an exception,
EXCEPTION:iMPACT:SVFYacc.c:208:1.10 - Data mismatch.
The only issue I've found online with that error shows that there should be an '#' symbol that needs to be removed, but I haven't seen any '#'s anywhere in the SVF.
I also tried to convert the SVF to XSVF. iMPACT doesn't throw an error loading the XSVF, but programming/executing the XSVF freezes the design instead of running the new program.
Adept doesn't have a comparable GUI in Linux that I've seen, just a cmd line tool 'djtgcfg'. Just like iMPACT, I've been able to program the toplevel.bit file fine with
$ djtgcfg prog -d Nexys2 -i 0 -f ../../toplevel.bit
but attempting to program the svf file with the same call doesn't seem to affect anything. It says it should take a few minutes and immediately reports "Programming succeeded" but I don't see any change on the device.
I'd really like to keep my environment all in Linux if I can, I don't have quite enough room on my laptop to juggle between two VMs.
Is it possible to use use iMPACT to write an SVF file to the Nexus2? Or can/should I be using the Adept utility differently?
Has anyone gotten this to work? Thanks a ton!
There are many better ways to reconfigure the PicoBlaze InstructionROM without resynthesizing:
use Xilinx's data2mem tool
This toll is shipped with ISE and can patch BlockRAM contents in bit-files
=> requires FPGA reprogramming
use PicoBlaze's embedded JTAGLoader6
Enable the embedded JTAGLoader6 design in the template file. Use JTAG_Loader_RH_64 binary or JTAG_Loader_Win7_64.exe to upload a hex-file via JTAG into the PicoBlaze ROM.
=> reconfigure ROM at runtime, no FPGA reprogramming needed
The manual from Ken Chapman offers several pages on how to use JTAG_Loader. Additionally, have a look into the PicoBlaze discussions at forums.xilinx.com. There are some discussions regarding bugs and issues around JTAG_Loader and how to solve them.
Also have a look into opbasm from Kevin Thibedeau as an alternative and improved PicoBlaze assembler. It is also shipped with an ROM patch tool.
I know it's a little bit late for the original poster, but I suspect I am taking the same class and I believe I have found a solution to upload picoblaze code on linux.
Download the KCPSM3 zip file from Xilinx IP Download, extract the contents and move the executables from the JTAG_loader folder to your working directory.
In dosbox run hex2svfsetup.exe for the nexys2 board select menu options 4 - 0 - 1 - 8
Use the assembler to create the .hex file
In dosbox run hex2svf.exe to create the svf file
Then run svf2xsvf.exe -d -i < input.svf > -o < output.xsvf >
The contrary to the JTAG_Loader_quick_guide.pdf in the initial zip file use impact and open the xsvf file and program using the xsvf file.
The title is pretty straightforward - I can't get anything at all to run when building in x64 and I get a message box with this error code. Do you know what may be the problem here?
This is STATUS_INVALID_IMAGE_FORMAT, you can find these error codes listed in the ntstatus.h SDK header file.
It is certainly strongly correlated with building x64 code. You'll get this status code whenever your program has a dependency on 32-bit code, particularly in a DLL. Your program will fail to start when it tries to load the DLL at startup, a 64-bit process cannot contain any 32-bit code. Or the other way around, a 32-bit process trying to load a 64-bit DLL.
Review all the dependencies for your program, particularly the import libraries you link. Everything must be built to target x64. You can use SysInternals' ProcMon utility to find the DLL that fails to load, useful in case this is a DLL Hell problem.
Just an addition to the correct answer above: also check you .manifest-files (resp. #pragma comment(linker,"/manifestdependency...) and make sure that you have processorArchitecture='x86' for 32-bit and processorArchitecture='amd64' for x64 code.
What are the guidelines for porting a 32-bit program to a 64-bit version?
Apart from the obvious issues with calling 32-bit libraries:
Don't assume a pointer is the same size as an integer.
Don't assume subtracting one pointer from another yields a value that fits in an integer.
See also http://msdn.microsoft.com/en-us/library/aa384190(VS.85).aspx
Don't use hard coded registry/file system paths as some are different on a 64-Bit machine. For example, 32 bit apps get installed in 'Program Files (x86)'.
If you are developing in Windows using .NET, make sure you are using the System or Microsoft.Win32 libraries to access resources.