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.
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.
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?
-- Dimi.
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@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.
On January 5, 2004 05:40 pm, Ralf Juengling wrote:
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).
Yes, this is the problem! For some reason I've read /local as /usr/local/lib, and I was confused why it wasn't working :)
So, you have two options: 1. Specify -L/local/lib on the command line or 2. Just use std prefix (/usr/local/lib).
-
Dimitrie O. Paun -
Ralf Juengling