I just started to learn masm32 and am a bit confused about the .obj files, I used C# before, so the compiler linked for me, now I have qeditor but I cant find an option to assemble multiple .asm files. I have a very basic program built of:
Vector.asm (+ Vector.inc), ...is a vector
Matrix.asm (+ Matrix.inc), ...is a matrix
Main.asm ... is the main program where I do some Vector calculations
When I compile each one of them seperate, I get 3 .obj files, what are they? I looked into the makeit.bat at the line:
\masm32\bin\PoLink /SUBSYSTEM:CONSOLE "console.obj"
so I thought I could just change it to
\masm32\bin\PoLink /SUBSYSTEM:CONSOLE "console.obj" "vector.obj" "matrix.obj"
to compile my whole program, but I was wrong :(, can anyone help me to successfully create a .bat (because maybe I want to create a little ide later, for which I would need a .bat) which compiles the 3 .obj files into 1 .exe?
I'm not familiar with PoLink, but a standard linker requires more than just a list of .obj files. It will also need to know what you intend on calling the resulting .exe (it can assume if you only give it a single .obj file). May also require an entry point. May even require library definitions if you're doing multiple files. You really need to read the docs and see what it wants on the command line...
Related
I am creating a library, which require some assembly level code.
I am using using NASM to write and integrate my .asm file.
Now the problem is, I already have a project created in VS13. Now I want to add and integrate an assembly level code to my project.
I have already added a .asm file in my source directory, but when I am trying to run my test case, the compiler is unable to find my assembly code.
I want to know how can I link my .asm file with my .c file.
Structure of my project:
->Project1(Generates a Library)
--->Source
----->File1.c
----->File2.c
----->nasm.asm
->Project2 (Test case to use the library and generate .exe)
-->Source
---->main.c
Now, nasm.asm binaries should get attached with the .lib generated by project1
and Project2 should able to access project1.lib
Apologize if question is bit unclear, its a bit complex for me to make it clear in written. Please let me know if you want any clarification or extra information.
Thanks a lot
For each of you assembly files:
Right click it in the Solution Explorer and choose Properties
Make sure the selected Configuration is either All Configurations or the configuration you are using (this bites me every time!)
In the Configuration Properties>General change the Item type to Custom Build Tool
From the Configuration Properties>Custom Build Tool>General set the following items:
Command Line. Use this as an example: nasm -fwin32 "%(FullPath)" -o %(Filename).obj
Outputs. This is necessary, VS check for this files. I usually use %(Filename).obj.
Link Objects. Yes. If you name your output files with obj extension they are automatically included in the link phase.
To check that you set everything right, select your assembly file, right click and choose Compile.
This may be compiler specific, in which case I am using the IAR EWARM 5.50 compiler (firmware development for the STM32 chip).
Our project consists of a bunch of C-code libraries that we compile first, and then the main application which compiles its C-code and then links in those libraries (pretty standard stuff).
However, if I use a hex editor and open up any of the library object files produced or the final application binary, I find a whole bunch of plain text references inside the output binary to the file paths of the C files that were compiled. (eg. I see "C:\Development\trunk\Common\Encryption\SHA_1.c")
Two issues with this:
we don't really want the file paths being easily readable as that indicates our design some what
the size of the binary grows if you have your C-files located in a long subdirectory (the binary contains the full path, not just the name)...this is especially important when we're dealing with firmware that has a limited amount of code space (256KB).
Any thoughts on this? I've tried all the switches in the compiler I can think of to "remove debug information", etc., but those paths are still in there.
"The command-line option --no_path_in_file_macros has been added. It removes the path leaving only the filename for the symbols FILE and BASE_FILE."
It is defined in the release notes if IAR.
http://supp.iar.com/FilesPublic/UPDINFO/005832/arm/doc/infocenter/iccarm_history.ENU.html
Or you can look for FILE and BASE_FILE macros and remove it you do not want to use the flag.
I would like to compile the following C file on an embedded platform:
https://github.com/openwsn-berkeley/openwsn-fw/blob/develop/firmware/openos/bsp/chips/at86rf231/radio.c
However, as you can see, on lines 20-26 of radio.c it references "radiotimer_capture_cbt":
typedef struct {
radiotimer_capture_cbt startFrame_cb;
radiotimer_capture_cbt endFrame_cb;
radio_state_t state;
} radio_vars_t;
radio_vars_t radio_vars;
So now I need to hunt down where it is defined and make sure I include the right header.
I have cloned the entire GIT repository here: https://github.com/openwsn-berkeley/openwsn-fw, and I'm looking for a way to compile this easily.
Is there a better way to get this compiled other than going through the brutal dependency nightmare?
My ultimate goal is only to get radio.c compiled and anything it needs. I do not see any makefiles in this project so I'm expecting they want us to use an IDE.
The project seems to use scons as a build system. So the simplest way is to dive into the scons files.
There's a small scons file in the directory containing the linked file and two main script in the top directory.
But if you want to play, first remove headers include, try to compile (using -c) to know which one are really needed. Once you get an object file (.o) you can use nm to identify missing symbols (marked with U.) Good luck …
I am working with a different compiler CC. It doesn't work like GCC.
When I was using GCC, I can do "gcc -o exe_filename source_filename" and the output would be a exe file.
When I use CC, I need 2 steps. First I compile the source files (suppose it involve a .c and a .h file ) and it create a .lis file and a .obj file. Then I do a link command which created a .exe file.
What is the relationship between LIS, OBJ and EXE files? I ask this because I wonder which files do I need if I want to use the exe in another machine without including unnecessary files. If LIS and OBJ were only used for compilation, I don't need it in another machine.
The compiler takes C files (and includes H files as referenced) and produces object (OBJ) and listing (LIS) files. The object file contains the code and data, but has unresolved external references. The listing typically includes line numbers, error and warning messages, and optional sections such as a type and variable cross-reference.
The linker combines object files and resolves external references to libraries. The result is an executable (EXE) image. (Or shareable image when creating libraries.)
Only the executable file needs to be copied from one system to another to run the application. The listing may be useful for interpreting error messages as it provides the properly correlated line numbers. The object could be useful if the application needs to be relinked due to changes in libraries, particularly if the target system has older versions than the original system.
the OBJ files are the compiled C files in a format that they can be "Linked" together by a linker and turned into an EXE.
Compile -> OBJ -> Link -> EXE
the LIS file is just informational output of the C that the compiler ends up compiling.
All you need once compiled and linked is the EXE
You don't need the other files. The exe will work fine by itself.
I don't have much idea on LIS. But the difference between OBJ and EXE is OBJ file may contain unresolved symbols and in EXE file all symbols are linked and resolved.
If another machine also has same hardware then u can use direct exe to run else you have to cross compile
When I compile with Compaq Visual Fortran, I get these errors (when it starts the linker process) that should be located in a .lib file I thought I added to the workspace:
X30XFULL.OBJ : error LNK2001: unresolved external symbol _BCON#4
X30XFULL.OBJ : error LNK2001: unresolved external symbol _RCON#16
According to where I've googled about, it looks like Compaq Visual Fortran (Version 6, FYI) can't find the library files...
My main question is, how do I use them? Could there possibly be other missing files? Here is what I've tried:
Right Click->Adding the files in the FileView window
Going under Project->Settings, Clicking the Link tab, and under the input category, adding the library files under object/library modules (bprop.lib rprop.lib) and having the Additional Library Path point to where the files are. I also did this under the Resources tab and where it says "Additional Resource Include Directories," I put the directory of where these files were located.
To cover my bases, I also put these files in where the project workspace file, where the compiled executable file would be generated, and pretty much any place I could think of that CVF might possibly look to in order to find these files.
A little background:
I have this Fortran executable that was last compiled in the 90s. From my research, it's a 16-bit compiled one which won't work on a 64-bit machine.
The original code has, at least from what we can gather, 16 bit compiled libraries. Without the original compiler, we can't figure out how to look at or use them. We also have a (semi)equivalent library file that's actually a .FOR file. For all we know, the BPROP.FOR and BPROP.LIB could be the same file (they were found in the same source code area). If we use the BPROP.FOR file, the program can compile, but we are having issues with results that we've traced down to information that is used/gathered/processed in that file.
However, we do have 32-bit versions of (what we think) are the same .lib files. So, we're trying to use that, which is what is being used to compile the Fortran executable which results in the errors above.
Found the answer, at least for me. I don't know how easy it'll be to extrapolate if anyone else finds these answers, but this is how I solved it.
With the old Fortran libraries, all I had to do was add them to the FileList view that has all of the different fortran files (.FOR, etc). I did not have to add these libraries in the settings like I mentioned, but that will work as well. Other then that, I didn't need to add any extra declarations or anything similar.
What we did find out is that the function in question (BCON and RCON) that calls those .LIB files required an additional argument. The only way I found this out was examining other source code that used those libaries, so if anyone is stuck like I was, that would be a good place to start. Alternatively, if you can read the .lib file in a hex editor, you can kind of make out functions and their arguments.
Of course, if you have the original source code for said arguments, that's even better. :)