I have been using the deploytool in Matlab for the past few months in my 2010b 64bit version of Matlab. I just recently found out that I need to create a 32 bit version of my c shared library.
To do this I follow the same methods I had been using previously (pretty much calling the command mcc -W lib:MYLIB -T link:lib -d 'MYOUTPUTFOLDER' -v 'MFILE1' 'MFILE2') in my 2009b 32 version of Matlab. I keep getting the error LNK1811: cannot open input file LIBRARY.obj. I have tried to find this LIBRARY object file but I cannot seem to find it anywhere.
So far I have checked to ensure all of the correct libraries are available (found at $MATLABROOT$\extern\include\win32), I have made sure all of my paths are correct in the compopts.bat file, and I have used the option -T compile:lib which works fine and creates a dll. This would be great but I need a lib file to use later in mbuild.
My current path forward is to take the compopts from my 64 bit version of Matlab (on a different machine) and compare it with my compopts for the 32 bit. I will post if it makes a difference.
To summarize our comments in the question and make it an answer. Here is how I manage to create both x32 and x64 libraries/standalones with mcc.
NB: Maybe there are more elegant solutions to configure deploytool, anyway with brute force I'm sure it works and I can automate global deployment process for my applications ...
Machine setup
Install Matlab x32 and x64 on your machine
Run Matlab x32 and setup compiler options typing msbuild -setup
This will generate a compopts.bat file in ~user\AppData\Roaming\MathWorks\MATLAB\R2013b (path may differ upon your version)
Rename this file to compopts.x32.bat (see later)
Run Matlab x64 and setup compiler options typing msbuild -setup
This will generate a compopts.bat file in ~user\AppData\Roaming\MathWorks\MATLAB\R2013b (!!Overwrites x32!!)
Rename this file to compopts.x64.bat (To workaround file overwrite)
EDIT Just tested ... In R2014b, Matlab does no longer overwrites same compots.bat file ... it now generates two separate MBUILD_C++_win64.xml and MBUILD_C++_win32.xml files (which is a good thing!).
Compilation in x32
Force your compilation script to point to ~matlabx32\bin\win32\mcc.exe and force mcc.exe to use previously saved compopts.x32.bat file using the -f option. Your command line should be something like:
~matlabx32\bin\win32\mcc.exe -f "compopts.x32.bat" ... other mcc options ...
Compilation in x64
Force your compilation script to point to ~matlabx64\bin\win64\mcc.exe and force mcc.exe to use previously saved compopts.x64.bat file using the -f option. Your command line should be something like:
~matlabx64\bin\win64\mcc.exe -f "compopts.x64.bat" ... other mcc options ...
Related
Having built my application, initially using debug, I now move to make it production ready. I have changed my compile options from
-c -W"c,debug,LP64,sscomm,dll"
to
-c -s -W"c,LP64,sscomm,dll"
which reduces the size of the resultant executable to 60% of the debug version.
I changed my link options from
-W"l,LP64,DYNAM=DLL"
to
-s -W"l,LP64,DYNAM=DLL"
which further reduces the size of the resultant executable to 20% of the original debug version.
So it certainly seems to be doing something. But when I view the executable, I can still see all the function name eye-catchers in the executable, and when I force an abend, the CEEDUMP generated still shows all the function names in that file. I expected -s to remove all symbolic information.
So my question is "how do I remove all symbolic information?"
In addition, once linked with -s I can no longer copy the module to an MVS dataset, from the USS file where it is generated. I use the following command:-
cp -X prog "//'ME.USER.LOAD(PROG)'"
which fails with:-
IEW2523E 3702 MEMBER *NULL* IDENTIFIED BY DDNAME /0000002 IS NOT AN EDITABLE
MODULE AND CANNOT BE INCLUDED.
IEW2510W 3704 ENTRY OFFSET 0 IN MODULE *NULL* IDENTIFIED BY DDNAME /0000002
DOES NOT EXIST IN A VALID SECTION.
cp: FSUMF140 IEWBIND function "INCLUDE" failed with return code 8 and reason code 83000505
This error message seems to say that I need the EDIT linkage option, but if I add that in, it appears to negate the step of using -s on the link, as the size goes back up to 60% of the debug version size.
So my second question is, "how do I copy the file to an MVS dataset and also remove symbolic information?"
Maybe there is a subsequent step that I can take to drive the binder again to remove symbolic information from the USS file and from the MVS dataset after the copy?
You can use COMPRESS compiler option and to some extent COMPACT. The COMPRESS option will suppress emitting function names in control blocks, while the COMPACT option will influence the compiler optimization choices to favor smaller object size.
Even though you are compiling and linking your executable in USS, you do not need to produce the executable in USS and then copy it to a data set. You can put your executable straight into the data set by using -o "//'ME.USER.LOAD(PROG)'" syntax. Just make sure your output data set is a PDSE.
Since you are compiling and linking in USS, you should use the xlc utility with -q syntax for compiler options as this syntax avoids the use of parenthesis which have special meaning in shell.
I want to run serial commands from a Bealgebone to a 4Dsystems display. Therefore I copied the c library found here into a directory and created a test program main.c:
#include "Picaso_const4D.h"
#include "Picaso_Serial_4DLibrary.h"
int main(int argc,char *argv[])
{
OpenComm("/dev/ttyUSB0", B115200); // Matches with the display "Comms" rate
gfx_BGcolour(0xFFFF);
gfx_Cls();
gfx_CircleFilled(120,160,80,BLUE);
while (1) {}
}
Now when I do gcc -o main main.c its says
main.c:2:37: fatal error: Picaso_Serial_4DLibrary.h: No such file or
directory
So I try linking it:
gcc main.c -L. -lPICASO_SERIAL_4DLIBRARY
which gives me the same error. Then I tried to create a static library:
gcc -Wall -g -c -o PICASO_SERIAL_4DLIBRARY PICASO_SERIAL_4DLIBRARY.C
which gives me this:
PICASO_SERIAL_4DLIBRARY.C:1:21: fatal error: windows.h: No such file
or directory compilation terminated.
What am I doing wrong? the git page clearly says this library is created for people who do not run windows.
Thanks in advance!
You're not getting a linker error; you're getting a preprocessor error. Specifically, your preprocessor can't find Picaso_Serial_4DLibrary.h. Make sure that it's in your include path; you can add directories to your include path using the -I argument to gcc.
You've had two problems. First was the picaso_whatever.h file that couldn't be found. You fixed that with the -I you added. But, now, the picaso.h wants windows.h
What are you building on? WinX or BSD/Linux?
If you're compiling on WinX, you need to install the "platform sdk" for visual studio.
If you're using mingw or cygwin, you need to do something else.
If on WinX, cd to the C: directory. Do find . -type f -name windows.h and add a -I for the containing directory.
If under Linux, repeat the find at the source tree top level. Otherwise, there is probably some compatibility cross-build library that you need to install.
Or, you'll have to find WinX that has it as Picaso clearly includes it. You could try commenting out one or more of the #include's for it and see if things are better or worse.
If you can't find a real one, create an empty windows.h and add -I to it and see how bad [or good] things are.
You may need the mingw cross-compiler. See https://forums.wxwidgets.org/viewtopic.php?t=7729
UPDATE:
Okay ... Wow ... You are on the right track and close, but this is, IMO, ugly WinX stuff.
The primary need of Picaso is getting a serial comm port connection, so the need from within windows.h is [thankfully] minimal. It needs basic boilerplate definitions for WORD, DWORD, etc.
mingw or cygwin will provide their own copies of windows.h. These are "clean room" reimplementations, so no copyright issues.
mingw is a collection of compile/build tools that let you use gcc/ld/make build utilities.
cygwin is more like: I'd like a complete shell-like environment similar to BSD/Linux. You get bash, ls, gcc, tar, and just about any GNU utility you want.
Caveat: I use cygwin, but have never used mingw. The mingw version of windows.h [and a suite of .h files that it includes underneath], being open source, can be reused by other projects (e.g. cygwin, wine).
Under Linux, wine (windows emulator) is a program/suite that attempts to allow you to run WinX binaries under Linux (e.g. wine mywinpgm).
I git cloned the Picaso library and after some fiddling, I was able to get it to compile after pointing it to wine's version of windows.h
Picaso's OpenComm is doing CreateFile [a win32 API call]. So, you'll probably need cygwin. You're opening /dev/ttyUSB0. /dev/* implies cygwin. But, /dev/ttyUSB0 is a Linux-like name. You may need some WinX-style name like "COM:" or whatever. Under the cygwin terminal [which gives you a bash prompt], do ls /dev and see what's available.
You can get cygwin from: http://cygwin.com/ If you have a 64 bit system, be sure to use the 64 bit version of the installer: setup-x86_64.exe It's semi-graphical and will want two directories, one for the "root" FS and one to store packages. On my system, I use C:\cygwin64 and C:\cygwin64_packages--YMMV.
Note that the installer won't install gcc by default. You can [graphically] select which packages to install. You may also need some "devel" packages. They have libraries and .h files that a non-developer wouldn't need. As, docs mention, you can rerun the installer as often as you need. You can add packages that you forgot to specify or even remove ones that you installed that you don't need anymore.
Remember that you'll need to adjust makefile -I and/or -L option appropriately. Also, when building the picaso library, gcc generated a ton of warnings about overflow of a "large integer". The code was doing:
#define control_code -279
unsigned char buf[2];
buf[0] = control_code >> 8;
buf[1] = control_code;
The code is okay, and the warning is correct [because the code is sloppy]. If the code had done:
#define control_code -279
unsigned char buf[2];
buf[0] = (unsigned) control_code >> 8;
buf[1] = (unsigned) control_code;
it probably would have been silent. Use -Wno-overflow in your Makefile to get rid of the warnings rather that edit 50 or so lines
I'm trying to find a way to convert simple C code to NASM assembly. I have tried using objconv and downloaded and unzipped and built it since I am using a MAC; however, it doesn't seem to be working. I keep getting "-bash: objconv: command not found". Does anyone know another way or can help me solve the -bash error.
Bash is the program that takes the words you type in a terminal and launches other programs. If it is reporting an error, it is because it cannot find the program you want to run (at least in this case).
You need to either find a pre-packaged installation of objconv, or you need to do the work to "integrate" your copy of objconv yourself.
If you can identify the executable you want to run (probably called objconv) you need to add that to your path. The easiest way (if it is just for you) is to verify that your ~/.bashrc or ~/.bashprofile has a line that looks something like
PATH=$PATH:${HOME}/bin
Don't worry if it doesn't look exactly the same. Just make sure there's a ${HOME}/bin or ~/bin (~ is the short version of ${HOME}).
If you have that then type the commands
cd ~/bin
ln -fs ../path/to/objconv
and you will create a soft link (a type of file) in your home binary directory, and the program should be available to the command line.
If you create the file, and nothing above has any errors, but it is not available to the command line, you might need to set the executable bit on your "real" (not link) copy of objconv.
If this doesn't work, by now you should be well primed for a better, more specific question.
If you have gcc installed, try gcc -masm=intel -S source.c to generate assembly files in a syntax very similar to that of MASM.
I am trying to test the VHDL AVR8 soft processor found on Gadget Factory on a Digilent Nexys II (Spartan 3E) Development board. The project includes a Makefile for compiling a C (or other) software program and merging it with the FPGA bitstream so there is no need to resynthesize the HDL with every iteration of the software.
When I execute 'make' I get the following error associated with data2mem:
Merging Verilog Mem file with Xilinx bitstream: main.bit
data2mem -bm bin/top_avr_core_v8_bd.bmm -bt bin/top_avr_core_v8.bit -bd main.mem -o b main.bit
process_begin: CreateProcess(NULL, data2mem -bm bin/top_avr_core_v8_bd.bmm -bt bin/top_avr_core_v8.bit -bd main.mem -o b main.bit, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [main.bit] Error 2
I am executing 'make' in the same directory containing the VHDL project files, and I even have a blank 'main.bit' file in the directory.
Does anyone have any ideas about what's going on here? Does my blank 'main.bit' file need to be formatted a certain way or placed in a different location?
The following is a link to my Makefile:
Makefile
Other information to note: I'm new to using Makefiles in general, let alone for the specific purpose of merging software with an FPGA bitstream file. Also, I am attempting this on a Windows 7 machine in command prompt.
Thanks in advance.
Edit: Here's a link to the AVR8 soft processor on Gadget Factory, and here's the AVR8 source.
Offhand I'd say make cannot invoke the data2mem program. Do you have such a program on your system? Is the directory containing it in your PATH variable? Does it run properly? For example, can you type in that command line yourself at the command prompt and have it work properly?
When you say a "blank" main.bit, I assume you mean a "fully populated except for the memory that I want to put the program into" main.bit... otherwise nothings going to work!
It sounds like you do not have data2mem on your path - are you sure you are running your makefile from a command window/shell which includes the xilinx paths?
On Windows, there is a specific icon for this. Alternatively you can open any old command prompt and run the settings32.bat (or settings64.bat) file from within the Xilinx install folder to get set up. Or on linux, you can source the appropriate .sh/.csh file in your shell.
I have a program which compiles and runs scripts.
To create a standalone version of the script, I reserve a large static buffer to hold the compiled script. The compiled script is copied into a copy of the program and it can then be run from that copy.
This works fine. It has some disadvantages however:
the buffer is static and takes up space if there's no compiled
program in it.
if the script to be included exceeds the buffer's size, I need to build a new version with a larger buffer.
I'd like to add the compiled script to the end of the program, but naively doing so doesn't work as the exe loader chokes on the new file size.
Is there a way to manipulate the exe so it would be acceptable for the loaders (mind this is a cross platform program)?
would be acceptable for the loaders (mind this is a cross platform program)?
I would think that this is unlikely to be possible without being platform specific. Time for a common interface with different implementations (so the code that saves/loads the script is common, but the executable manipulation is specific).
On Windows you'll hit the problem that a running executable file is locked against modification. By working on copies this can be worked around (but the only way to rename back in a completely deterministic way it is perform the move on boot, but scheduling a job might be acceptable).
On Windows the easiest way to add data to an image (executable or dll) is using resources. Define a custom resource type and add into the image (UpdateResource function) and later retrieve with LoadResource.
You said "script", so I suppose you have a separate file containing the script (a text file?). You could write a simple program that reads the script file and convert it in a compilable form (e.g. a C source containing the initialization of an array of byte). There are also tools you can use to convert an arbitrary file into a linkable object (.o or .obj). In the past I have used the command "objcopy" from GNU bimutils. In particular, on linux:
objcopy -I binary -O elf32-i386 mydata mydata.o
This command creates an object and three public symbols you can use to find the start, the end and the size of your data block:
_binary_mydata_start
_binary_mydata_end
_binary_mydata_size
Something similar may work also on Windows, provided that you install a Windows version of GNU binutils (e.g. cygwin).