Hi Dimi,
On Wed, 2003-12-31 at 16:47, Dimitrie O. Paun wrote:
On December 31, 2003 07:42 pm, Ralf Juengling wrote:
okay, now it's as before:
As I said, I think there's something wrong with your ld setup. You need to have /usr/local/lib (where the libwine library is) in your /etc/ld.so.conf:
I tried this today, (adding /local/lib to /etc/ld.so.conf) but it didn't make a difference. I then looked into winegcc.c and winewrap.c to find out what winwgcc is actually doing. It is creating a shared library (dll) and a little wrapper executable to load the shared library.
This should not be necessary with the code in question and I would rather like to build just one executable. So I wrote a Makefile that does this (not using winegcc & co) by calling winebuild explicitly (see below).
It seems to work, but when I start the executable by
wine phaeaco.exe.so
I see the application's windows appearing and immediately disappearing and get the following error messages:
err:win:WIN_FindWndPtr window 0x20030 belongs to other process err:win:WIN_FindWndPtr window 0x20030 belongs to other process
I wonder whether this error has to do with the way I built the executable. The Makefile is as follows:
------ Makefile ------------------------------------------
INCLUDE_PATH = /local/include/wine LIBRARY_PATH = /local/lib
# This should be replaced by wildcard expression as soon as all # sources actually participate in the built. PHAEACO_CSRCS = ../gensrc/Statist.c
PHAEACO_CXXSRCS = Experim.cpp Login.cpp Phaeaco.cpp TextWnd.cpp \ Intrface.cpp Mentor.cpp Solver.cpp List.cpp ... (some more)
PHAEACO_RCSRCS = phaeaco.rc
PHAEACO_DLLS = advapi32 comdlg32 gdi32 kernel32 odbc32 ole32 \ oleaut32 shell32 user32 winspool winmm comctl32
DEFINES = -D__WINE__ INCLUDES = -I. -I../geninc -I../coginc -I$(INCLUDE_PATH) -I$(INCLUDE_PATH)/windows CC = gcc CFLAGS = -g -fpack-struct $(DEFINES) CXX = g++ CXXFLAGS = -g -fpack-struct $(DEFINES) CPPFLAGS = $(INCLUDES) OBJS = $(PHAEACO_CSRCS:.c=.o) $(PHAEACO_CXXSRCS:.cpp=.o) RESS = $(PHAEACO_RCSRCS:.rc=.res) LDFLAGS = -L$(LIBRARY_PATH) -L$(LIBRARY_PATH)/wine LIBS = -lwine -lm WBLIBS = $(patsubst %,-l%,$(PHAEACO_DLLS))
phaeaco.exe.so : $(OBJS) winebuild -o phaeaco.spec.c --exe $(@) -mgui $(OBJS) $(RES) $(LDFLAGS) $(WBLIBS) gcc -o phaeaco.spec.o -c phaeaco.spec.c $(CXX) -shared -Wl,-Bsymbolic,-z,defs -o $@ phaeaco.spec.o $(OBJS) $(LDFLAGS) $(LIBS) strip --strip-all $(@)
%.o : %.cpp $(CXX) -c $(CXXFLAGS) $(CPPFLAGS) -o $@ $<
%.res : %.rc wrc $(DEFINES) $(INCLUDES) -o $@ $<
clean: rm -f ./*.o ../gensrc/*.o ../cogsrc/*.o
On January 2, 2004 07:16 pm, Ralf Juengling wrote:
I tried this today, (adding /local/lib to /etc/ld.so.conf) but it didn't make a difference. I then looked into winegcc.c and winewrap.c to find out what winwgcc is actually doing. It is creating a shared library (dll) and a little wrapper executable to load the shared library.
Yes, and even if that's not necessary, it shouldn't break the build. If it does, and if there's a problem with it, I'd really like to fix it.
This should not be necessary with the code in question and I would rather like to build just one executable. So I wrote a Makefile that does this (not using winegcc & co) by calling winebuild explicitly (see below).
Unfortunately, by doing that we don't learn anything useful for Wine :) There is absolutely no reason why duplicating the steps that winegcc takes in your Makefile should make any difference.
Speaking of this wrapper script, we should have a flag in winegcc that disables it. But again, having it should make no difference whatsoever. Can you (pretty) please go back to the winegcc stuff, and run the linking step with the -v option, and send me the output?
It seems to work, but when I start the executable by
wine phaeaco.exe.so
I see the application's windows appearing and immediately disappearing and get the following error messages:
err:win:WIN_FindWndPtr window 0x20030 belongs to other process err:win:WIN_FindWndPtr window 0x20030 belongs to other process
I wonder whether this error has to do with the way I built the executable.
I doubt it, IIRC this is some unimplemented behaviour in Wine. What Wine are you using BTW? Is it the latest from CVS?
The Makefile is as follows: LIBS = -lwine -lm
You see, you link against -lwine as well, why would this fail through winegcc? I'm guessing there's something funny in your ld setup...
On Sat, 2004-01-03 at 01:03, Dimitrie O. Paun wrote:
This should not be necessary with the code in question and I would rather like to build just one executable. So I wrote a Makefile that does this (not using winegcc & co) by calling winebuild explicitly (see below).
Unfortunately, by doing that we don't learn anything useful for Wine :) There is absolutely no reason why duplicating the steps that winegcc takes in your Makefile should make any difference.
Speaking of this wrapper script, we should have a flag in winegcc that disables it. But again, having it should make no difference
There is at least one difference in using a wrapper & dll vs. using a single executable: The function GetModuleFileName doesn't yield the path to the program (the wrapper) with the wrapper-approach (there was some discussion on this in another recent thread). Thus, having such flag in winegcc would indeed be nice...
whatsoever. Can you (pretty) please go back to the winegcc stuff, and run the linking step with the -v option, and send me the output?
Did so. wineg++ invokes winewrap (without passing on the "-v" flag, though) which in turn generates same files and compiles them. The error eventually occurs in linking the wrapper executable:
gcc -shared -Wl,-Bsymbolic,-z,defs -lwine -o phaeaco.exe.so /tmp/wwrpLuPoqb.spec.o /tmp/wwrpLuPoqb.o /usr/bin/ld: cannot find -lwine collect2: ld returned 1 exit status Error: gcc failed.
The Makefile is as follows: LIBS = -lwine -lm
You see, you link against -lwine as well, why would this fail through winegcc? I'm guessing there's something funny in your ld setup...
The directory in which libwine.so.1 lives, is contained in my /etc/ld.so.conf. Are you saying this should be enough for gcc to find the library file? In the other Makefile (the one where I invoke winebuild explicitly), the path is passed (as an -L option) to winebuild and g++ (c.f. variable LDFLAGS).
Ralf
-
Dimitrie O. Paun -
Ralf Juengling