Re: [winegcc01] Don't use BINDIR to spawn subprograms
Dimitrie O. Paun wrote: On August 13, 2003 09:49 pm, Richard Cohen wrote: Just using $PATH to find stuff makes it much easier to spawn off tools when running within the tree. Changelog: Remove hardcoded BINDIR paths Yes, this is a problem -- eventually we want to use these things from within the tree. I guess we can prepend $WINE_HOME/tools to the PATH within the Makefile. Another way do to it is to look at argv[0], and if we're running from within the tree, we automatically select the in-tree tools, rather than the ones from BINDIR. I agree with you that we should try to be as consistent with gcc as possible. Here gcc-winegcc and ld-winewrap. gcc just calls the ld in the PATH; I don't see any advantage in doing anything more complicated. Richard. PS. I read wine-devel so you don't have to send emails directly to me as well.
Re: [winegcc03] winewrap can handle the default output name
Dimitrie O. Paun wrote: The reason I've handled it in winegcc rather than winewrap is that this seems to be a (historical) feature that's specific to gcc, and there doesn't seem to be any reason to have such a feature perpetuated in winewrap. winegcc - gcc, winewrap-ld $ man ld ... -o output --output=output Use output as the name for the program produced by ld; if this option is not specified, the name a.out is used by default. The script command OUTPUT can also specify the output file name. Anyone up for renaming winewrap to wineld ? ;-} Richard.
Re: [winegcc06] Delayed import
Dimitrie O. Paun wrote: On August 13, 2003 10:08 pm, Richard Cohen wrote: This is not cool -- winegcc is supposed to be command line compatible with mingw-gcc, and -d conflicts with gcc's -d: Having the option in winewrap is OK, there we control the options. If this feature is useful in Windows, gcc must/will support it, right? If they don't already, we better get in touch with them so we end up with the same option name/syntax. I agree - I just chose -d to be the same as winebuild. How about an option --delay-lib... for winewrap, and to avoid polluting winegcc's namespace, pass it via -Wl eg something like... winegcc -mwindows grotto.c -Wl,--delay-lib,comdlg32 As an aside, delayed import libraries are used twice in programs/ (wineconsole winedbg), and apparently in comctl32, msvcrt, oleaut32. They are ineffective in wineconsole at the moment because (for some reason) ole32 is immediately pulled in, which pulls in shell32, which pulls in comdlg32 ... Richard.
Re: problem with apps in desktop mode
Dmitry Timoshkov wrote: Raphal Junqueira [EMAIL PROTECTED] wrote: When I try running InstallShield in windowed mode (Desktop = 640x480 as per default in config), window appears for a second and then dissapears printing this message: X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 12 (X_ConfigureWindow) Serial number of failed request: 93 Current serial number in output stream: 98 Did latest modifications of x11drv break anything? well i have the same message since 2 or 3 weeks now. ... That's because desktop window is not shared between processes. Fixing this is one of the aims of the scheduled window management rewrite. The patch that caused the regression is: http://cvs.winehq.com/patch.py?root=/home/winehq/opt/cvs-commitid=8265 Unless it is safe to let InstallShield apps out of their Desktop prison, this really needs fixing. Reversing the patch works for me, but I'm not absolutely clear what it was trying to solve, and there may be a less drastic solution. -- Richard.
Re: [winegcc06] Delayed import
Dimitrie O. Paun wrote: On August 14, 2003 05:30 am, Richard Cohen wrote: winegcc -mwindows grotto.c -Wl,--delay-lib,comdlg32 Yes, this works better, but I'm curious why the gcc people don't support it? Did you check the mingw docu for this feature? http://sourceforge.net/mailarchive/message.php?msg_id=5712741 is the only reference I could find on any the mingw mailing lists - a mingw-user saying he'd never heard of delay loading. The ld documentation certainly doesn't mention delay loading and I can't find a reference on the binutils mailing list. MS: /DELAYLOAD Borland: -d Irix: -delay_load winebuild: -d and --delay-lib so I would suggest either -delay_load or (my favourite) -delay-load. It doesn't really matter if we have it first - we can always change it later. In any case, we need to have our own extensions - eg to stop winewrap creating a wrapper script. PS. Alexandre, are my winegcc patches OK or should I rewrite them in Perl ? :-) -- Richard
Re: winegcc
[EMAIL PROTECTED] wrote: I've just updated via cvs, and I get this [EMAIL PROTECTED] Wine]$ winegcc -mwindows 01-biditest.c /tmp/wappZjLo5B.spec.o(.text+0x1010a): In function `__wine_exe_main': : undefined reference to `WinMain' collect2: ld returned 1 exit status Error: gcc failed. Error: winewrap failed. [EMAIL PROTECTED] Wine]$ winewrap returns a seg fault. You need to explicitly link with gdi (use -lgdi32) or change main() to WinMain() and use -mwindows -- Richard.
