Hi, I'm using Monodevelop to write Win32-API applications. I have no trouble getting the Monodevelop compiler (gcc/g++) to compile the code, but I am having problems getting the app to link: g++ -shared -o "dtrace/bin/Debug/libdtrace.so" "dtrace/bin/Debug/main.o" "/usr/lib64/libwine.so" dtrace/bin/Debug/main.o: In function `DllMain': dtrace/src/main.cpp:25: undefined reference to `InitializeCriticalSection' dtrace/src/main.cpp:41: undefined reference to `GlobalHandle' dtrace/src/main.cpp:41: undefined reference to `GlobalUnlock' dtrace/src/main.cpp:41: undefined reference to `GlobalHandle' dtrace/src/main.cpp:41: undefined reference to `GlobalFree' dtrace/src/main.cpp:48: undefined reference to `DeleteCriticalSection' /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: dtrace/bin/Debug/libdbgtrace.so: hidden symbol `LeaveCriticalSection' isn't defined /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status Build complete -- 40 errors, 13 warnings My question is, where are the Win32 API functions located for the linker? What are their names? .a files? .so files?
On 5/6/10 12:01 AM, Progman3K wrote:> Hi, > > I'm using Monodevelop to write Win32-API applications. > > I have no trouble getting the Monodevelop compiler (gcc/g++) to compile the code, but I am having problems getting the app to link: > > g++ -shared -o "dtrace/bin/Debug/libdtrace.so" "dtrace/bin/Debug/main.o" "/usr/lib64/libwine.so" > dtrace/bin/Debug/main.o: In function `DllMain': > dtrace/src/main.cpp:25: undefined reference to `InitializeCriticalSection' > dtrace/src/main.cpp:41: undefined reference to `GlobalHandle' > dtrace/src/main.cpp:41: undefined reference to `GlobalUnlock' > dtrace/src/main.cpp:41: undefined reference to `GlobalHandle' > dtrace/src/main.cpp:41: undefined reference to `GlobalFree' > dtrace/src/main.cpp:48: undefined reference to `DeleteCriticalSection' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: dtrace/bin/Debug/libdbgtrace.so: hidden symbol `LeaveCriticalSection' isn't defined > /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Nonrepresentable section on output > collect2: ld returned 1 exit status > Build complete -- 40 errors, 13 warnings > > My question is, where are the Win32 API functions located for the linker? What are their names? .a files? .so files?Neither. It's kinda weird actually. First you have to run winebuild on the object files, so it can generate import stubs. Then you have to assemble (yes, assemble) and link these stubs to your object files. This is because of the way importing functions from Wine DLLs works (it's designed to be compatible with Windows). Luckily, you don't have to do all this by hand. The winegcc tool does all this for you. So, you invoke wineg++ instead of plain g++. Also, you have to tell it you want to link to kernel32.dll by passing it -lkernel32. Hope that helps. Chip
Progman3k. You have a few more problems than you dream with this path. wine build tools are designed for porting applications to other platforms. There is a feature missing from wine. http://wiki.winehq.org/WinePluginApi . This feature would be required to allow native Linux programs to run segments in wine. Using Win32 API requires a very particular memory structs and services to work. Currently you are forced to do the following. Code application like windows application build a wine exe.so for program with calls out to Linux binaries. Unless of course you fell like bring WinePluginAPI into existence. If you are really aiming to make Win32-API applications you are looking for mingw version of gcc not wine build environment by the way. Also if not aware any binary built using wine own build environment is not windows compatible.
Program3k try kdevelop 4 some time. Yes I know its not for windows yet but it will come. Monodevelop is not what you call a fast program and its very feature light. Also if you are not aware if you are not using Linux parts there is no runtime speed advantage to build with wineg++ over using mingw g++. Same complier and .exe.so forces the same loader pattern as a PE. At most all it will make is minor loader delay in wine building with mingw nothing to write home about thinking most cases you are only loading a program once. The time wasted building twice is not worth it. Simply there is no point integrating wine into ide's in most cases. There is no performance to be gained. You are better off to build proper cross platform like QT.