I can look into doing this, but is there a reason we can't use -gstabs+ for all compilers? Will some compilers barf with this flag?
I can see the benefits of doing it this way, but configure already takes ages :) On Wed, 2003-01-08 at 10:04, Eric POUECH wrote: > IMO the test should be: > - compile a little test program > - test if it contains stabs info (this adds a dependency on binutils, but since the >test is meant to compile wine it shouldn't be too much an issue) > - if it doesn't, and if compiler is gcc then rerun the test with the -gstabs+ flag > - it the test passes add the flag to CFLAG, otherwise warn the user (at the end of >configuration) as we do for opengl > however, this would be better in wine.ac (or equivalent) so that we can make use of >it for other winelib programs for instance > > A+ > >Messsage du 08/01/2003 08:59 > >De : Mike Hearn <[EMAIL PROTECTED]> > >A : Shachar Shemesh <[EMAIL PROTECTED]> > >Copie à : Eric Pouech <[EMAIL PROTECTED]>, Mike Hearn ><[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> > >Objet : Re: Symbol stripping? > > > > What does gcc prior to 3.1 do with the -gstabs+ flag? If it ignores it, > > or it's implied anyway, we could just have it always on. > > > > If not then I have some bash here that can parse the output of gcc -v > > and determine whether it's >= 3.1, would that be acceptable as a patch > > to configure.ac? > > > > The only other way would be to compile a little test app then run > > objdump on it to figure out if stabs data was included, but testing the > > GCC version would be faster. > > > > On Tue, 2003-01-07 at 09:19, Shachar Shemesh wrote: > > > Eric Pouech wrote: > > > > > > > aren't you, by any chance, compiling with gcc >= 3.1 ? > > > > if so, you need to force emission of stabs as a debugging format while > > > > running configure > > > > something like this should work > > > > CFLAGS=-gstabs+ ./configure > > > > > > Maybe we should patch configure.ac to detect this and add the apropriate > > > compile switch? > > > > > > > > > > > A+ > > > > > > > > -- > > Mike Hearn <[EMAIL PROTECTED]> > > QinetiQ - Malvern Technology Center > > > > > > > -- Mike Hearn <[EMAIL PROTECTED]> QinetiQ - Malvern Technology Center
