Using winebuild explicitly

Dimitrie O. Paun dpaun at
Sat Jan 3 03:03:59 CST 2004

On January 2, 2004 07:16 pm, Ralf Juengling wrote:
> I tried this today, (adding /local/lib to /etc/
> 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

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

> It seems to work, but when I start the executable by
> wine
> 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...


More information about the wine-devel mailing list