On Mon, May 20, 2002 at 09:43:40PM +1000, Robert Collins wrote: > > >> -----Original Message----- >> From: Charles Wilson [mailto:[EMAIL PROTECTED]] >> Sent: Monday, May 20, 2002 6:44 PM > >> Two ideas: >> 1) making auto-import the default >> 2) turning off the warnings >> >> You appear to not like either one. I don't really care about the >> warnings, but the auto-import thing should be default. However, I >> wonder how long these "warnings" are going to persist. Using >> auto-import is not a *bug* or *oops, I forgot to declspec() >> something* >> -- it's the way DLLs are done. > >But it's not complete. One cannot link against all .dll's with >auto-import, and no speed tests of normal vs auto-import have been >seriously conducted. I still maintain that a profile driven >recompile+link is the way to go, and that when that's done auto-import >can be tossed out. > >> I look at auto-import as "the new and better and more unixlike way of >> building shared libs". You seem to view them as "nice >> feature, but you >> really ought to do it the old-fashioned way". In my view, >> the warnings >> go away eventually -- they were just there during the "trial phase", >> which has now stretched to a REALLY long time. In your view, the >> warnings are TRUE warnings about BAD programming practice, >> and stay forever. > >The warnings should stay IMO. They aren't errors, but they are >important.
Since --auto-import has been the default for the last version of binutils, I think we should leave it that way. I think we should keep the warnings if --auto-import isn't specified on the command line but get rid of them if it is explictly specified. Including --auto-import on the command line would indicate that the user knows what they're doing, so they don't need to see warnings. Basically, I don't like being warned about something when there is no way to turn off the warning. cgf