On August 13, 2003 10:08 pm, Richard Cohen wrote:
--- tools.5/winegcc.c 2003-08-14 00:55:07.000000000 +0100 +++ tools/winegcc.c 2003-08-14 01:21:41.000000000 +0100 @@ -193,7 +193,8 @@ } argv[j] = 0; break;
case 'l':
case 'l': /* import/static library */case 'd': /* delayed import library */
This is not cool -- winegcc is supposed to be command line compatible with mingw-gcc, and -d conflicts with gcc's -d:
-dletters Says to make debugging dumps during compilation at times specified by letters. This is used for debugging the compiler. The file names for most of the dumps are made by appending a pass number and a word to the dumpname. dumpname is generated from the name of the output file, if explicitly specified and it is not an executable, otherwise it is the basename of the source file. In both cases any suffix is removed (e.g. foo.00.rtl or foo.01.sibling). Here are the possible letters for use in letters, and their meanings: .....
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.
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.
On August 14, 2003 05:30 am, Richard Cohen wrote:
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
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?
Dimitrie O. Paun wrote:
On August 14, 2003 05:30 am, Richard Cohen wrote:
winegcc -mwindows grotto.c -Wl,--delay-lib,comdlg32Yes, 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
On August 19, 2003 03:51 pm, Richard Cohen wrote:
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.
I'm not sure anything starting with -d is a good candidate due to the current use of -d in gcc.
It doesn't really matter if we have it first - we can always change it later.
That's not a good strategy, we'll have to be in line with the gcc people, and breaking compatibility like so is no good. Let's float the question on their mailing list before we settle on something.
In any case, we need to have our own extensions - eg to stop winewrap creating a wrapper script.
I don't think this is a good idea. This is an implementation detail that I'd rather not export -- we hope to get rid of this wrapper sooner or later. Why do you want to disable it?
Dimitrie O. Paun wrote:
... That's not a good strategy, we'll have to be in line with the gcc people, and breaking compatibility like so is no good. Let's float the question on their mailing list before we settle on something.
OK, do you want to do it or shall I?
In any case, we need to have our own extensions - eg to stop winewrap creating a wrapper script.
I don't think this is a good idea. This is an implementation detail that I'd rather not export -- we hope to get rid of this wrapper sooner or later. Why do you want to disable it?
Well, it's just the difference in the programs/ Makefile between
$(MODULE).so: $(ALL_OBJS) $(RC_SRCS:.rc=.res) Makefile.in $(WINEWRAPPER) $(RM) $(BASEMODULE) $(WINEGCC) -m$(APPTYPE) $(ALLCFLAGS) $(ALL_OBJS) \ $(RC_SRCS:.rc=.res) -o $(MODULE) -L$(DLLDIR) -L$(LIBDIR) $(EXTRALIBS) \ $(LIBPORT) -Wl $(LDFLAGS) \ $(DELAYIMPORTS:%=-Wl,-delay-load,%) $(IMPORTS:%=-l%) $(RM) $(BASEMODULE) && $(LN_S) $(WINEWRAPPER) $(BASEMODULE)
and
$(MODULE).so: $(ALL_OBJS) $(RC_SRCS:.rc=.res) Makefile.in $(WINEWRAPPER) $(WINEGCC) -m$(APPTYPE) $(ALLCFLAGS) $(ALL_OBJS) \ $(RC_SRCS:.rc=.res) -o $(MODULE) -L$(DLLDIR) -L$(LIBDIR) $(EXTRALIBS) \ $(LIBPORT) -Wl,-no-script $(LDFLAGS) \ $(DELAYIMPORTS:%=-Wl,-delay-load,%) $(IMPORTS:%=-l%) $(RM) $(BASEMODULE) && $(LN_S) $(WINEWRAPPER) $(BASEMODULE)
I think the second is cleaner - but it's not really a big deal, and as you say it will disappear, but probably not in time for 0.9
On September 9, 2003 02:32 pm, Richard Cohen wrote:
OK, do you want to do it or shall I?
I'd appreciate if you can do it, I'm close to my bandwidth :)
I think the second is cleaner - but it's not really a big deal, and as you say it will disappear, but probably not in time for 0.9
OK, no problem, we can worry about this a bit later I think...
-
Dimitrie O. Paun -
Richard Cohen