Using winebuild explicitly

[Ralf Juengling]

On Mon, 2004-01-05 at 13:04, Dimitrie O. Paun wrote:
> > 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...
> 
> Alexandre is working on a patch to completely remove the
> need for such wrapper. Hopefully it will be committed soon
> enough so we will not have to create such an option.

Cool, that's good news.

 
> > Did so. wineg++ invokes winewrap (without passing on the
> > "-v" flag, though) which in turn generates same files 
> > and compiles them. 
> 
> Yes, it doesn't, but you can just copy the winewrap command, add the -v and invoke it manually.

That's how I found out which step actually failed...


> > 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?
> 
> Right, that's how I thought it's supposed to work.
> Did you rebuild the ld cache after updating /etc/ld.so.conf?

Yes, I did.

gcc -shared -Wl,-Bsymbolic,-z,defs -lwine -o phaeaco.exe.so
/tmp/wwrpwsPFIV.spec.o /tmp/wwrpwsPFIV.o
/usr/bin/ld: cannot find -lwine
collect2: ld returned 1 exit status
Error: gcc failed.
[juenglin at alpspitze bongard]$ gcc --version
gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
Copyright (C) 2002 Free Software Foundation, Inc.
 

Maybe, this assumption is simply wrong and gcc doesn't look up
dynamic libraries that way (at least its man page doesn't say so).
The reason that only I have this problem and noone else might be
due to my wine setup: I configured with "--prefix=/local" so the
libs cannot be found in any of the standard places (/usr/lib
or /usr/local/lib).

Ralf


> 
> --
> Dimi.