I wanted to know if anybody has successfully compiled a data structure containing EXTERNAL type with asn1c compiler (http://lionet.info/asn1c/blog/) ? I have successfully compiled the presentation layer using asn1c and used to decode packets in my code but I am unable to compile ACSE layer because the compiler whines for EXTERNAL.h file, which doesn't get generated in the compilation process and thus I am unable to use the compiled files.
Thanks.
I have not tried EXTERNAL in the lionet.info asn1 compiler, but the OSS Nokalva asn1 compiler supports the ASN.1 EXTERNAL type without any difficulty. You can download a free trial of the OSS ASN.1 compiler from http://www.oss.com/asn1/products/asn1-download.html.
Paul
Related
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
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.
I recently received a closed-source SDK consisting of a C header file (.h), a library file (.lib), and a dynamic library (.dll). They were compiled using Microsoft's Visual C++. However, I am attempting to write my code using MinGW (GCC ported to Windows, for anyone unfamiliar with the project). It appears that ld is unable to link to the .lib file. I was wondering if it was possible to write a compatibility wrapper between the VS-compiled code and the GCC code I'm writing.
Is there an ABI mismatch or does it just not want to to link against the object format? If it's just a linking problem, you can extract the functions you care about, disassemble them, and then reassemble them into an object your linker can handle. Even easier, maybe objcopy(1) can speak both formats and can help you out?
If you do have an ABI problem to deal with, you can do the same but also add a shim layer to thunk the ABI so that the function calls will work. How complicated that layer is and how difficult it will be to write will depend on the interfaces of the functions you're trying to use.
Don't get too discouraged by the comments - it's software, so pretty much anything is possible.
By using the -fdump-tree-* flag , one can dump some intermediate format file during compilation of a source code file. My question is if one can use that intermediate file as an input to gcc to get the final object file.
I'm asking this because I want to add some code to the intermediate file of the gimple (obtained by using the flag -fdump-tree-gimple) format. Sure I can use hooks and add my own pass, but I don't want to get to that level of complexity yet. I just want to give gcc my modified intermediate file, so it can start its compilation from there and give me the final object file. Any ideas how to achieve this?
GIMPLE was a binary internal format which is hard to dump fully and reload back correctly. Comparing with LLVM, LLVM IR was designed to be dumpable and reloadable into usual file (text and binary format of such files are fully-convertible from each to other). You can run Clang fronted to emit LLVMIR, then start opt program with some optimizations, then with other, and there will be LLVM IR bitcode files between phases. And then you can start codegeneration from IR bitcode into native code (even, in theory, into not the same platform, see PNaCl project).
There are some projects of dumping/reloading internal representation of GCC. I know such project was created to integrate gcc with commercial compiler tool. The author can't just link commercial code with gcc, because gcc is VIRAL (it will infect any linked code with anti-commercial GPL). So, author wrote a GPL dumper/loader of GIMPLE to some external (xml) format; the proprietary tool was able to read and translate this XML into other XML of the same format and then it was reloaded back with GPL tool.
In newer gcc you have an option of writing a plugin, which is VIRAL (23.2.1) in terms of GPL. Plugin will operate on in-memory representation of program and there will be no problem of dumping/reloading GIMPLE via external file.
There are some plugins which may be configured/may use user-supplied program, e.g MELT (Lisp) and GCC Python (Python). Some list of gcc plugins is there
There's no built-in facility to translate the text GIMPLE representation back to original GIMPLE internal representation.
You'll need to use custom front-end (such as suggested GIMPLE FE) to make sense of dumped GIMPLE.
I compiled libxml2 with BCC 5.5 command line compiler, now I have lots of .obj files which I'd like to link into my Delphi application. Unfortunately, I get lots of "Unsatisfied forward or external declaration" errors, pointing to standard C library functions like memcpy, open, recv etc ...
What should I do to compile it correctly? I'd like to avoid depending on msvcrt.dll or any other external libraries.
Thanks in advance!
Depending on the version of Delphi you have, there should be a unit called crtl.dcu with which you can link. Just use the $L directive for each .obj file in a unit that also uses crtl. You may also need to "use" other various units like Windows, WinSock, etc... The point is to provide the symbols and functions to resolve during the link phase.
This is the same technique used to statically link in the DataSnap TClientDataSet code used to also build midas.dll.
you should read article of Rudy here "Using C object files in Delphi"
Don't use those functions, but rewrite them to call operating system functions (kernel32/system32) directly.