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?
Using Monodevelop to write Winelib apps
-
Charles Davis
Using Monodevelop to write Winelib apps
On 5/6/10 12:01 AM, Progman3K wrote:
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
Neither.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?
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.
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.
Thank you for your responses, they are most helpful.
I should clarify, I am already able to write Winelib apps fairly easily using imake.
I have been able to write some simple Imakefiles to build a project for Winelib or for MinGW.
It's just that to write everything, I am using separate tools like gedit, imake and the terminal.
Using Monodevelop is interesting because of it's integrated debugger and code-completion.
For example to write graphical Windows apps, I have had success with Imakefiles like these:
for Winelib
I should clarify, I am already able to write Winelib apps fairly easily using imake.
I have been able to write some simple Imakefiles to build a project for Winelib or for MinGW.
It's just that to write everything, I am using separate tools like gedit, imake and the terminal.
Using Monodevelop is interesting because of it's integrated debugger and code-completion.
For example to write graphical Windows apps, I have had success with Imakefiles like these:
for Winelib
And now the same thing for MinGW:INCROOT = /usr/include/wine/windows
SYSTEMUSRINCDIR = /usr/include/wine/windows
APPNAME = myapp
SRCS = src/main.cpp
OBJS = resource.res $(SRCS:.cpp=.o)
LOCAL_LIBRARIES =
INCLUDES = -I. -Iinc -I../include
DEFINES = -DWINELIB -D_REENTRANT
CC = wineg++
CXX = wineg++
CXXOPTIONS += -mwindows -std=c++0x -Wall
WRC = wrc
WINELIB_FLAGS = -I./inc -I/usr/include/wine/windows $(DEFINES)
WRCFLAGS = -r
ifndef NDEBUG
CXXDEBUGFLAGS += -g
CDEBUGFLAGS += -g
DEFINES += -DDEBUG
endif
/* Basic libraries */
USRLIBDIR = /usr/lib32/wine
SYSTEMUSRLIBDIR = /usr/lib32/wine
SHLIBDIR = /usr/lib32/wine
SYS_LIBRARIES += -lcomctl32
.SUFFIXES: .rc .res
resource.res:: res/dialogs.rc
clean::
$(RM) $(OBJS) $(APPNAME).exe $(APPNAME).exe.so
.rc.res:
$(WRC) $(WRCFLAGS) $(WINELIB_FLAGS) -o $@ $<
AllTarget($(APPNAME))
ComplexProgramTargetNoMan($(APPNAME))
DependTarget()
This approach works really well, I'm trying to do basically the same thing but using the project options in Monodevelop.INCROOT = /usr/i686-pc-mingw32/usr/include
SYSTEMUSRINCDIR = /usr/i686-pc-mingw32/usr/include
APPNAME = myapp.exe
SRCS = src/main.cpp
OBJS = resource.o $(SRCS:.cpp=.o)
LOCAL_LIBRARIES =
INCLUDES = -I. -Iinc -I../include
DEFINES = -D_M_IX86 -D_WIN32_IE=0x0400
CC = i686-pc-mingw32-g++
CXX = i686-pc-mingw32-g++
CXXOPTIONS += -mwindows -std=c++0x
WRC = i686-pc-mingw32-windres
WINELIB_FLAGS = -I. -Iinc -I/usr/i686-pc-mingw32/usr/include $(DEFINES)
WRCFLAGS = -r
ifndef NDEBUG
CXXDEBUGFLAGS += -g
CDEBUGFLAGS += -g
DEFINES += -DDEBUG
endif
/* Basic libraries */
USRLIBDIR = /usr/i686-pc-mingw32/usr/lib
SYSTEMUSRLIBDIR = /usr/i686-pc-mingw32/usr/lib
SHLIBDIR = /usr/i686-pc-mingw32/usr/lib
SYS_LIBRARIES += -lcomctl32
.SUFFIXES: .rc .res
resource.o:: res/dialogs.rc
clean::
$(RM) $(OBJS)
.rc.o:
$(WRC) $(WRCFLAGS) $(WINELIB_FLAGS) -o $@ $<
AllTarget($(APPNAME))
ComplexProgramTargetNoMan($(APPNAME))
DependTarget()
-
Charles Davis
Using Monodevelop to write Winelib apps
On 5/6/10 5:54 AM, Progman3K wrote:
You should be asking the Monodevelop folks anyway. They would know how
to help you.
Chip
Well then, we can't help you. I'm sorry.This approach works really well, I'm trying to do basically the same thing but using the project options in Monodevelop.
You should be asking the Monodevelop folks anyway. They would know how
to help you.
Chip
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.
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.
