Actually, it occurs to me that my commit doesn't even fix the case that it was intended to fix -- @#$%@#$%%@#$ !!!
The main point of the patch was to fix totalview support. I did this by examining CFLAGS. But because CFLAGS doesn't always contain -g, we use $DEBUGGER_CFLAGS (setup in orte/config/orte_setup_debugger_flags.m4) to always compile the "special" .c files in libompi that *must* be compiled with -g (and friends) for totalview/ddt to work. My patch didn't address DEBUGGER_CFLAGS at all -- it only addressed CFLAGS, so it doesn't guarantee that the ompi/debugger/*.c files are compiled with -gstabs+. Sigh. So regardless, my first commit is busted. Here's a summary of random points: - Per above, we clearly need to add -gstabs+ for the DEBUGGER_CFLAGS -- not CFLAGS. But it *needs* to be added -- even if it's just for those ompi/debugger/*.c files. ===> This is the most important point, I think. ===> Is there a way to test to see if -gstabs+ is broken? - I agree that configure should always "just work" out of the box. We shouldn't add something that may be broken in some environment. - I didn't think we cared about OS X 10.3 anymore (OMPI's readme says that the earliest OS X we have tested is 10.4). Brian -- are you saying that you have a special environment that uses OS X 10.3 that we just broke? - FWIW: it is useful for OMPI *developers* to have -gstabs+. I'd venture that most end users don't care about -gstabs+ -- if their debuggers just step over MPI function calls (because they can't step in), they don't care. On Jul 27, 2010, at 6:15 PM, Ralph Castain wrote: > I do sympathize with the "the user said to do it" argument as that is in > keeping with our approach elsewhere. IIRC, what Jeff had implemented does > print out a warning if we override the flag, so this would only be a minor > change that might help alert people to what is going on. I would also suggest > an FAQ entry as well. > > > On Jul 27, 2010, at 4:08 PM, Barrett, Brian W wrote: > > > Ok, so there is some middle ground I would dislike but not hate enough to > > object to. How about having a AC_MSG_WARN if we find -g in the > > CFLAGS/CXXFLAGS on OS X version 10.4 or later? Users get educated, I can > > still make executables that are debugabble for my weird environment, and > > this thread can die. It's not perfect, but at least it seems to accomplish > > everyone's goals. > > > > Brian > > > > On Jul 27, 2010, at 4:02 PM, Barrett, Brian W wrote: > > > >> Unfortunately, there really is no middle ground. THe only option is to > >> ask Apple to fix -g to mean -gstabs on OS X. I'm cross compiling from one > >> version to another, so running an executable won't work. Looking at the > >> three or four ways that you can specify a target version won't work > >> (especially since at least in 10.4, you could change them without command > >> line or environment variables). > >> > >> Sorry, there's no middle ground - this patch broke a use case that used to > >> work. I know you guys didn't know about -gstabs. That doesn't make it > >> right to do evil things. > >> > >> Brian > >> > >> On Jul 27, 2010, at 3:47 PM, Ralph Castain wrote: > >> > >>> Can I offer a middle ground? I believe we have been burned enough with > >>> the -g vs -gstabs situation on OSX that it merits defaulting > >>> "appropriately". So... > >>> > >>> Can we detect if gstabs is actually supported by the OS vs the compiler? > >>> > >>> If not, can we add logic that checks the OS target version and "does the > >>> right thing"? > >>> > >>> My concern here is that our users are no more informed than Jeff or I > >>> were, and will almost certainly specify -g when what they really mean is > >>> "I want a debuggable executable". Unfortunately, as we all know, that > >>> isn't what you get on OSX once you hit 10.4 and above. > >>> > >>> > >>> > >>> On Jul 27, 2010, at 3:29 PM, Barrett, Brian W wrote: > >>> > >>>> On Jul 27, 2010, at 3:13 PM, Jeff Squyres wrote: > >>>> > >>>>> On Jul 27, 2010, at 5:02 PM, Barrett, Brian W wrote: > >>>>> > >>>>>> Yes, but say I'm using a custom built version of gcc that doesn't do > >>>>>> -gstabs quite right. Now you've screwed me. > >>>>> > >>>>> The configure test checks to see if -gstabs+ is accepted by the > >>>>> compiler. > >>>> > >>>> Yes, but acceptance and usefulness are not the same thing. > >>>> > >>>> If the TARGET_VERSION is 10.3, the compiler will accept -gstabs, but the > >>>> executable won't be debugable on 10.3, because 10.3 didn't use gstabs. > >>>> So I really, really want -g and you've just prevented me from doing what > >>>> I want. That's not just bad, it's awful. > >>>> > >>>>>> I'm a firm believer that our configure script should do what the user > >>>>>> says, as exactly as possible. Changing AC behavior a little bit is a > >>>>>> gray area, but one I'm almost ok with (since AC_PROG_CC will add -g if > >>>>>> CFLAGS is empty). > >>>>> > >>>>> We override that, though -- we take out that -g if CFLAGS was empty. > >>>>> > >>>>> I understand what you're saying, and in general I agree -- that we > >>>>> should add as little as possible to what the user said. But I don't > >>>>> quite know how to balance: > >>>>> > >>>>> * adding as few flags as possible > >>>>> * making debugging symbols work for those of us who aren't familiar > >>>>> enough with OSX to know that you need the special/secret -gstabs+ flag > >>>>> (and just expect -g to be enough) > >>>>> > >>>>> I've been developing POSIX software on a Mac for several years (i.e., > >>>>> not Mac-specific software, so I never dived into the details of > >>>>> Mac-specific functionality) and fell into the 2nd category until about > >>>>> a week ago. > >>>>> > >>>>> Got any suggestions? > >>>> > >>>> Yes, don't cause problems - if the user specified -g, assume he meant > >>>> -g. I understand what you're saying, but I'm against changing what the > >>>> user specified because we know better. We usually don't, and in this > >>>> case, there are known use cases where that's true. > >>>> > >>>> Brian > >>>> > >>>> -- > >>>> Brian W. Barrett > >>>> Dept. 1423: Scalable System Software > >>>> Sandia National Laboratories > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> devel mailing list > >>>> de...@open-mpi.org > >>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel > >>> > >>> > >>> _______________________________________________ > >>> devel mailing list > >>> de...@open-mpi.org > >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel > >>> > >> > >> -- > >> Brian W. Barrett > >> Dept. 1423: Scalable System Software > >> Sandia National Laboratories > >> > >> > >> > > > > -- > > Brian W. Barrett > > Dept. 1423: Scalable System Software > > Sandia National Laboratories > > > > > > > > > > > > _______________________________________________ > > devel mailing list > > de...@open-mpi.org > > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
