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
