I was assuming that it was a really simple task but I did not find anything relevant or my mistake.
So putting my problem here i.e. I have some project for MSP430 which is actually in code composer studio. I have to run this whole code into IAR embedded workbench now. There are some library files(*.lib) that are also provided with the project and that should have to be linked to build the project. After little modifications code is compiling fine but I am unable to link the libraries and getting linker errors. I worked on IAR with avr but very very little just to test some sample codes. I did not find the option where to mention these library names and their respective paths. I checked out the linker tab but I am not getting any clue to link these .lib files with project.
I believe that you are asking
How do I include a function that is in a binary library file supplied by one compiler vendor (Texas Instruments) into a project that is being compiled and built using a toolchain that is supplied by another vendor (IAR)
I would be very surprised if this is possible as the binary formats and calling conventions used by the two toolchains are probably different. The fact that you are getting an error message sayng that the library is not in UBROF format points to this fact. You need to do one of the following:
Compile the source for the old library module using the IAR toolchain (Even if you have the source for this file, it may well contravene the licence that allows you to use the function in your first toolchain)
You will have to find an equivalent function in the IAR toolchain libraries
Write your own clean function that performs the same purpose as the original library routine.
Related
Please don't answer this as a "How do I cross-compile on Linux for Windows" question, I solved that part. I need some specific instruction on configuring Netbeans. Thank you.
I'm developing a set of C functions that I want to distribute as a .dll on Windows, and a .so on Linux. (This is going to be used from java as a JNI library, but that's irrelevant to the question).
Development environment is Netbeans 8.2.
I have gcc and mingw installed, and compiling my source code for both targets works.
However, I want to create NetBeans configurations "Linux-Release" and "Windows-Release", with Linux-Release using gcc to create the .so file, and Windows-Release using x86_64-w64-mingw32-gcc. So I created a Mingw tools collection that refers to the mingw versions of the C compiler:
In my project properties, I created a Windows_Debug configuration, and told it to use the Mingw tool collection:
I can use this configuration to get a working Dll. However, the output file will be put into the dist/Windows_Debug/Mingw-Linux directory (not dist/Windows_Debug/Mingw-Windows as I'd like), and it's put there with a .so extension, not .dll. I can load this file on Windows when I rename it to .dll, but this will horribly confuse anyone I want to collaborate with.
Naively messing with the CND_DLIB_EXT macro in the generated Makefiles doesn't help at all, they just get overwritten.
I guess I have to either tell Netbeans that the Mingw Tool Collection compiles to Windows, or that the Windows_* configurations compile to Windows, so Netbeans sets the correct values for CND_* and the default output Macro
${CND_DISTDIR}/${CND_CONF}/${CND_PLATFORM}/libSMAQSJni.${CND_DLIB_EXT}
in the linker part of Project Properties works again. (Of course, as a workaround, I could just remove the variables from the macro, and replace them with appropriate constants, but I want to do this "right". I haven't found a way to tell Netbeans "this compiles to Windows" anywhere though, neither in the GUI nor in any of the config files. So, how do I do this?
I cross compile an application for target device using ARM arch using Green Hills toolchain (the device will run INTEGRITY OS) but it fail with some error like that
__vec_new from ...
__vec_delete from ...
I don't understand what it means and how to resolve it.
Anyone can help me ?
Unresolved symbols indicate failure to link the necessary object code or libraries defining said symbols. These particular symbols are most probably related to implementations of the new and delete C++ operators, and most likely indicate that you have not linked the C++ library. I am not very familiar with the Green Hills tool chain, but, in cases where you invoke the linker separately to the compiler, you may need to explicitly specify C++ linking.
If using an IDE it is possible that you have created a C project but added C++ code - this may result in linker options that do not link C++ support and libraries.
The Green Hill's compiler has a choice of C++ libraries selected by either language variant option, or linker override option. These options can be set in the MULTI IDE settings or on the command line depending on how you are managing your project. Consult the compiler/linker documentation - I have found the following:
You should have access to the full documentation, the pages following this describe how teh linker searches libraries and how to specify alternate libraries. If you have disabled the automatic library search by specifying -nostdlib, the automatic linking will not be performed and you will have to explicitly link the necessary libraries.
I have resolved the error
The cause is the project source contains a file *.c source it included and
I renamed it to *.cpp then the error disappeared
It seems I've got a real problem here due to my lack of any knowledge about Linux systems:
I have downloaded some open source code, which
is written in C
uses complex.h, so I assume it is ANSI C99
comes with makefiles designed for compilation under Linux systems
provides interfaces to IDL, MATLAB, Python etc.
I am indeed familiar about compiling C/MEX files under Windows-based MATLAB environments, but in this case I don't even know where to start. The project is distributed in several folders and consists of dozens of source and header files. And, to begin with, the Visual Studio 2010 compiler I've used to compile MEX files until now does not comply with the C99 standard, i.e. it does not recognize the complex.h header.
Any help towards getting this project compiled would be highly appreciated. In particular, I have the following questions:
1) Is there any possibility to automatically extract compilation information from the MEX files and transfer it to Windows reality?
2) Is there any free compiler being able to compile C99 stuff, which is also easy to embed in MATLAB?
I have done this (moved in-house legacy code inc. mex files to Win64). I can't recommend the experience.
You will have to recompile, no way around it.
Supported compilers for mex depend on your MATLAB version
This File Exchange entry for using Pelles C may be a starting point (if it works with your version of MATLAB).
I am guessing that there is a main makefile which then works through the makefiles in the subdirectories - have a read through the instructions for compiling under Linux, it will give you some idea of what's going on and may also discuss what to do if you want to change compiler. Once you've found a compatible compiler, the next stage is to understand what the makefiles are doing and edit them accordingly (change paths, compiler, compiler flags, etc.)
Then, from memory (it was a while ago), you get to enjoy a magical mystery tour through increasingly obscure compiler errors. Document everything because if you do get it working, you won't be in a mood to do this twice.
MATLAB R2016b on Windows now supports the MinGW compiler. I'm successfully using this to compile code written primarily for Linux/gcc. I installed this from the Add-On menu in MATLAB (search MinGW).
For my case, I'm building with the legacy code tool. The only thing I needed to do differently than normal was to tell the compiler to support c99 via a compiler flag. This does the trick:
legacy_code('compile', def, {'CFLAGS=-std=c99'})
I had trouble getting the flag command just right (I had some extra quotes that apparently broke things), and asked The MathWorks, so credit is due to their support team for this.
If you are using mex, I would expect to do something very similar.
I would guess that the makefiles are irrelevant for your application; you will need to tell the mex or legacy_code function about all of the files necessary to build the whole application or link against pre-built libraries (which it sounds like you don't have).
I hope this helps!
This is for my company, so I'm leery of being too specific, but I'll try.
I am attempting to add support for some existing ANSI C code to our platform. I am using GCC 4.7.2 as well as the GNU linker. We use part of newlib, but also some other C libraries, specifically libc.a. The end goal of this is to get an EXE or ELF image (this is for a PowerPC architecture micro) to put into the micro's RAM. This is being done on Windows XP. I am simply using a batch file, not a build environment or toolchain.
One of my build errors is a multiple definition problem of malloc/free functions. The cmd window spits out the error that there are definitions of these in both malloc.o and mallocr.o. Both of these are within libc.a. I've been told the "r" in mallocr.o is for reentrancy. I've also been told our platform does not support reentrancy.
I'm trying to resolve this error by preventing the linking of mallocr.o from within libc.a. This is the part where I am lost, I don't know how to do this. Google hasn't turned up anything helpful, and I haven't found a question on this site yet that answers my problem. I don't know if this is even possible.
There is really no specific code snippet to include in this question. Below is the error from the cmd window. I've *'d out company specific things I am not comfortable sharing.
c:\***\platform\2_2_0_r2013-2_x86-32\tools\gcc_4_7_2\ppc\bin\..\powerpc-eabi\lib\libc.a(mallocr.o): In function `free':
mallocr.c:(.text+0x19c): multiple definition of `free'
c:\***\platform\2_2_0_r2013-2_x86-32\tools\gcc_4_7_2\ppc\bin\..\powerpc-eabi\lib\libc.a(malloc.o):malloc.c:(.text+0x28): first defined here
c:\***\platform\2_2_0_r2013-2_x86-32\tools\gcc_4_7_2\ppc\bin\..\powerpc-eabi\lib\libc.a(mallocr.o): In function `malloc':
mallocr.c:(.text+0x468): multiple definition of `malloc'
c:\***\platform\2_2_0_r2013-2_x86-32\tools\gcc_4_7_2\ppc\bin\..\powerpc-eabi\lib\libc.a(malloc.o):malloc.c:(.text+0x0): first defined here
I'm trying to use an API for a proprietary interface device on an embedded system (Freescale HCS08), and the provided files include headers (.h) and libraries (.lib). The header compiles fine with the rest of my code (standard C), but when trying to link against the library I get memory errors saying the file might be corrupted.
My understanding of libraries in C is somewhat limited as I work almost exclusively on embedded systems where magic things like stdio, files, and dlls don't exist; but would the (or any) library be platform specific? Does it contain fully (if there is any sort of level there) compiled code? Some of the other files provided are VS project files, so if it is the case that the .lib is platform-specific, it wouldn't be unexpected that linking a file meant for x86-Windows to an 8-bit compiler would fail; it could be just me.
Not only is a .lib file CPU specific (there would be no way to link HCS08 code to x86 code), it is toolchain specific (CodeWarrior won't talk to SDCC, GCC/binutils won't talk to Visual Studio).
Yes the .lib contains compiled code so it is platform-specific. If you have the source you should be able to re-compile it to your platform.