I am trying to compile a C program using CeGCC, the program is written in C using Win32 API, and it's being compiled with MingW like this:
gcc -o "Win32App.exe" obj/winmain.o obj/callbacks.o obj/resource.o -s -lcomctl32 -Wl,--subsystem,windows
As a result the program is successfully compiled and then tested afterwards. The problem occurs when i try to compile it for ARM (Windows-CE) rather than x86-based architecture:
obj/winmain.o:winmain.c:(.text+0x24): undefined reference to InitCommonControlsEx
obj/winmain.o:winmain.c:(.text+0xe0): undefined reference to RegisterClassExW
As you can see the problem is that the two functions called InitCommonControlsEx and RegisterClassExW are not defined in Windows-CE.
My Question is how can i find an equivalent function to use in my code so that i can successfully compile and run my program in Windows-CE. I need help in replacing those two functions with compatible ones which are recognized in CeGCC.
Related
**Edit: Found my problem. As explained by the following answer, I was not actually doing any linking when making the static library. Instead, I made a shared library and linked libstdc++ statically.
Compile a static library link with standard library (static)**
I am trying to create a method to use c++11 on an ancient arm platform running kernel (2.6.37). Unfortunately the latest cross compile our BSP contains is GCC 4.5.3, which does not support all the c++11 utilites we need.
Initially I tried to use old versions of crosstool-ng to build a cross compiler, but the older versions were too broken. The newer versions did not support the 2.6.37 kernel. I was able to complete one build, however the g++ binary was not built, making the whole endeavor useless (I did check that c++ was enabled in the menuconfig).
Thus my last option was to build gcc natively at version 4.9.4 and create a statically linked library to have my gcc 4.5.3 cross compiler link against. This seems to work for the most part. I create my library on the target with the following:
g++ -std=c++11 --static -c main2.cpp
ar -cvq libmain2.a main2.o
I then copy over the files and try build on the host machine with gcc 4.5.3 and get the following:
arm-angstrom-linux-gnueabi-g++ simple.cpp -lmain2 -L.
(I cleaned up some of the output)
undefined reference to `std::_Hash_bytes(void const*, unsigned int, unsigned int)'
undefined reference to
std::__throw_regex_error(std::regex_constants::error_type)'
However, when I use nm, I get the following:
$ arm-angstrom-linux-gnueabi-nm libmain2.a | grep Hash_bytes
U _ZSt11_Hash_bytesPKvjj
U _ZSt11_Hash_bytesPKvjj
$ arm-angstrom-linux-gnueabi-nm libmain2.a | grep throw_regex
U _ZSt19__throw_regex_errorNSt15regex_constants10error_typeE
U _ZSt19__throw_regex_errorNSt15regex_constants10error_typeE
Does anyone know what the heck is going on? Unfortunately we need to be able to use our cross compiler on the host system for most work, but we are also needing to integrate this specific library which uses c++11.
Also note that if I take out the regex and hash functionality from my code but leave other c++11 concepts like nullptr, type inference, delegation etc, the code compiles and runs on the target fine.
Edit: Okay, so after a little more investigation, it looks like the functions _Hash_bytes and __throw_regex_error are not being statically linked into the static library. I guess I need to know why this is the case in order to fix the issue.
I have a third party C library, both in static format (.lib) and in dynamic format (.dll) with its own import library (.lib). It is MKL (Intel Math Kernel Library). I am working with cygiwn 64 on Windows 7.
In brief, I am trying to get a compiler born to work in POSIX world to talk to a lib compiled in Windows world, assuming that is vene possible.
I want to link that library as part of a C++ executable I am compiling with g++ in cygwin and I am trying to link with the DLL using the import library.
My command line, where I omit the file paths for simplicity, results in a undefined reference error.
$ g++ main.obj mkl_intel_lp64_dll.lib mkl_sequential_dll.lib mkl_core_dll.lib -o paper.exe
mkl_intel_lp64_dll.lib: blah, blah, blah: undefined reference to `__GSHandlerCheck'
... and many other similar errors
Anybody knows if it is possible, and, if yes, how to do it?
Thanks
Try rearranging the arguments to g++ so that main.obj precedes the libraries it references.
So after searching the web for a while, Ive decided to try here as it seems to be a good forum for discussion. Im trying to create a simple gcc plugin. The program code is attached in the end of this mail, but in plain english it registers the plugin and makes sure that the pragma_init function is called when pragmas are registered. It is here that I use c_register_pragma to intercept some of the pragmas.
I compile it using the example in http://gcc.gnu.org/onlinedocs/gccint/Plugins-building.html#Plugins-building. The compilation and linking works fine. However, when I load the plug-in I get:
gcc -c -fplugin=plugin.so test.c -o test.o
cc1: error: cannot load plugin plugin.so
plugin.so: undefined symbol: warning
What am I doing wrong? In addition, when including some header files (that will be required later), I get a lot of errors. For example, including "tree.h" yields (amongst 50 other errors):
/machmode.h:262:1: error: unknown type name 'class'
class bit_field_mode_iterator
^
/machmode.h:263:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
{
^
/plugin/include/tree.h:27:0,
from conftest.c:63:
/vec.h:220:8: error: field 'register_overhead' declared as a function
Anyone have a clue on what I am doing wrong?
Thank you
There are two problems here :
The error : "cannot load plugin plugin.so" means that you should add to your LD_LIBRARY_PATH the directory where you store your new shared library plugin.
The hundreds of errors you got with all the files in the include are resolved in my computer if you compile with g++ instead of gcc (not sure to understand why thought)
Which version of GCC are you using, both to compile your plugin, and to use the plugin? Run simply
gcc -v
without any other program argument to find out!
Did you install the appropriate package for GCC plugin development (on Debian or Ubuntu, it might be gcc-4.7-plugin-dev, but adapt the 4.7 version to your particular version of GCC)?
Did you install all the dependencies needed to build your GCC (on Debian or Ubuntu, apt-get build-dep gcc-4.7 gcc-4.7-plugin-dev)?
Recent versions of GCC (notably many GCC 4.7 shipped by distributions, and all GCC 4.8) are compiled by a C++ compiler, not a C compiler.
You may check how was your GCC built (in C or in C++) by running
nm -D -C $(gcc -print-file-name=cc1)
If that command shows typed C++ manged names, e.g. execute_ipa_pass_list(opt_pass*) instead of just execute_ipa_pass_list your GCC has been compiled with a C++ compiler (probably g++)
So you may need to use g++ (not gcc) to compile your GCC plugin.
As I commented, did you consider using MELT (a domain specific language to extend GCC) to extend or customize your gcc compiler?
I suggest downloading the very latest http://gcc-melt.org/melt-plugin-snapshot.tar.bz2 since I will release the next MELT in a few weeks for GCC 4.7 and 4.8
And don't expect to change the parsing behavior of your GCC with a plugin. That is not really possible (GCC provides only plugin hooks to add your builtins and pragmas, not to extend the parsed syntax).
I have obtained and installed a Cygwin-to-Linux cross-compiler from the Cygwin Ports Project and am trying to use it to compile a simple "Hello world"-program. Then this happens:
$i686-pc-linux-gnu-gcc main.c
/usr/bin/i686-pc-linux-gnu-g++.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory
Obviously, GCC can't find some DLL. Unforntunately, it does not print which and I do not know how I can find out.
This even happens when I try something as simple as running the preprocessor (through i686-pc-linux-gnu-gcc -E) over a C file that does nothing but return 0.
This GCC is version 4.7.2.
Does someone know how I can fix this? Or at least how I could find out the name of the library which can not be found?
I have 2 shared object libs and one executable.
1 of the libs that I compile has linkage error: Undefined _cxa_pure_virtual.
Why?
Usually we do not need to implement it. Any Ideas?
If I implement it both the libs compile and link OK, but the application that links to both has same linkage issue?
The lib in question is a C++ library and the __cxa_pure_virtual is needed by the C++ runtime. Suggest that you try first linking with g++ command instead of gcc.
Read more under this question: What is the purpose of cxa pure virtual