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