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
Related
I want to use the AMD HIP framework for my self-written GPU kernels. I do that by using a third-party library, which takes responsibility of taking the code and compiling it with HIP (and additional backends if desired). The technical setup looks as follows:
The kernel code is compiled into a static helper library with AMD HIP linking and toolchain enabled (CMake: set_target_properties(${target_name} PROPERTIES LINKER_LANGUAGE HIP))
This helper library is then linked into the core part of our own library, which is a shared library
This core part is then linked into the final shared library which is shipped at the end
Therefore, we have 3 different libraries in the build process that are linked together.
The build process exits without any errors s.t. that during compile- and link-time there are no errors. However, when I now want to use this library, I get the following error during runtime: undefined symbol: __hip_fatbin.
Because the code used to not even link correctly, I added these two flags to CMake which made it build successfully (as suggested by others on GitHub): -fgpu-rdc --hip-link. However, the library still does not run because of this undefined symbol error during execution. Inspecting the created libraries with nm -gD shows U in front of __hip_fatbin which makes me wonder why it is like that. Shouldn't that be somehow defined when linking with the HIP toolchain?
So my question is if anybody experienced the same issue yet when trying to use AMD HIP across multiple libraries that are linked against each other. Might this be an issue with gcc and HIP's clang? Or is there any chance for me to get further details which makes me understand what to do now. Thank you!
I have an application, which has been compiled several libraries into it through static link.
And this application will load a plugin through dlopen when it runs.
But it seems that the plugin can't resolve the symbol in the application, which I can find them through "nm".
So what can I do? Recompile the libraries into shared mode, and link them to the plugin?
You have to use the gcc flag -rdynamic when linking your application, which exports the symbols of the application for dynamic linkage with shared libraries.
From the gcc documentation:
Pass the flag -export-dynamic to the ELF linker, on targets that support it. This instructs the linker to add all symbols, not only used ones, to the dynamic symbol table. This option is needed for some uses of dlopen or to allow obtaining backtraces from within a program.
This should eliminate your problem.
The usual suggestion to add -rdynamic is too heavyweight in practice as it causes linker to export all functions in executable. This will slow down program startup (due to increased time for relocation processing) and, more importantly, will eventually make the interface between your application and plugins too wide so it would be hard to maintain in future (e.g. you won't be able to remove any function from your application in fear that it may be used by some unknown external plugin). Normally you should strive to expose a minimal and well-defined API for plugin authors.
I thus recommend to provide explicit exports file via -Wl,--dynamic-list when linking (see example usage in Clang sources).
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 am developing a bare metal C applications on an ST ARM-Cortex-M3. I have also developed libraries that are usable across all these applications.
I used to use Keil ARM-MDK, but want to move over to GNU-GCC. I thus downloaded the latest version of GCC and started recompiling the code.
Although similar questions to this one have been answered, it does not solve my problem ans therefore I am posting my question.
I have a problem with the following:
Lib_Flash has a function Read_Flash(). Lib_AppCfg links in Lib_Flash as it uses Read_Flash().
My application (App) links in both Lib_Flash and Lib_AppCfg. App also uses Read_Flash() for some specific FLASH checks.
In Keil MDK-ARM it worked fine.
With GCC, when functions using Lib_AppCfg are built, I get errors stating that Read_Flash() is an "undefined reference".
I am not sure where the problem lies. Is it in the linking of the Lib_Appcfg is built or is the problem when I link App?
Please advise. If you need additional information, please let me know.
The GNU linker by default searches the libraries once in the order listed on the command line. So if a library later in the list has a reference to symbol defined in an earlier library or object file, then it cannot be resolved.
The simple solution is to use library grouping; this causes the linker to repeatedly search a list of libraries until no further synbols can be resolved. If you are invoking the linker (ld) separately, then the linker options are:
--start-group _Flash _AppCfg --end-group
or the alternative form
-( _Flash _AppCfg -)
See the GNU linker manual for details. If driving the linker indirectly through gcc you pass linker options via the -Wl option, something like:
-Wl,-(,_Flash,_AppCfg,-)
I think.
It sounds to me like you have got an ordering problem in your libraries. Some linkers will rescan all the libraries on the command line till all references are resolved (or can't be resolved). Other linkers work sequentially along the link line.
In particular, this means that if library A defines a symbol SYM_A and library B which comes after library A references this symbol, it won't be resolved on the 2nd type of linker, and your link will fail.
To get round this, you can do one or more of the following
Reorder the libraries
Replicate libraries on the link line where
necessary
Refactor your libraries so there aren't mutual
dependencies between them (that is A references symbol SYMB, which
is defined in B, but B references SYMA)
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.