 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / CodeWarrior / January 2005sysbool.h error building on Tiger
Hi all, When building an Mach-O target under Tiger, I get the following error: stdbool.h line 2 #error "stdbool.h has moved to avoid accidental use with a non-GCC compiler. Only GCC should have used stdbool.h due to licensing restrictions." When I looked at stdbool.h, all it has is the above error pragma. I did a preprocess on my .pch++ to see where stdbool.h is included, but honestly cannot find it. Any ideas for a work around? Best regards, -- Allen Cronce > When building an Mach-O target under Tiger, I get the following error: > [quoted text clipped - 6 lines] > honestly cannot find it. > Any ideas for a work around? Tiger is covered by your NDA with Apple and should not be discussed in a public forum. If you're having trouble doing something on Tiger that works fine on Panther (as in this example), file a bug report with Apple at <http://bugreport.apple.com/>. -Eric  SignatureEric Albert ejalbert@cs.stanford.edu http://outofcheese.org/ > > When building an Mach-O target under Tiger, I get the following error: > > [quoted text clipped - 11 lines] > works fine on Panther (as in this example), file a bug report with Apple > at <http://bugreport.apple.com/>. All that being true, I think a bug report to Apple on this one is going to get closed really quick. What the OP describes, and the little bit I have to infer, suggests that it's doing exactly what is intended. SignatureChange account to gw when responding by mail. > > > When building an Mach-O target under Tiger, I get the following error: > > > [quoted text clipped - 15 lines] > to get closed really quick. What the OP describes, and the little bit I > have to infer, suggests that it's doing exactly what is intended. I can see how you'd infer that, but you'd be wrong. :) For that matter, the basic principle[1] here is obvious: If something that's supported works correctly on OS release N and it hasn't been deprecated for some reason, it should work correctly on OS release N + 1. Anything that doesn't work that way is a bug. -Eric [1] Exceptions may exist. This thread isn't one of them. SignatureEric Albert ejalbert@cs.stanford.edu http://outofcheese.org/ > > > > When building an Mach-O target under Tiger, I get the following error: > > > > [quoted text clipped - 17 lines] > > I can see how you'd infer that, but you'd be wrong. :) So you are asserting that the OP is using GCC? > For that matter, the basic principle[1] here is obvious: If something > that's supported works correctly on OS release N and it hasn't been > deprecated for some reason, it should work correctly on OS release N + > 1. Anything that doesn't work that way is a bug. What's obvious is not always what's true. What about something that works incorrectly on OS release N, but that incorrect behavior is more convenient to some people than the correct behavior would be? If the correct behavior is imposed on release N + 1, that's not a bug no matter how much it inconveniences those people. I work in an environment where the correct way and the convenient way are routinely at odds with each other. If we choose convenient over correct we'll be out of business by the end of the quarter no matter how good we are in every other respect. Correctness is mandatory in my industry. Abiding by licensing requirements on a redistributed file is certainly mandatory for a large, high-profile vendor. SignatureChange account to gw when responding by mail. > > > > > When building an Mach-O target under Tiger, I get the following > > > > > error: [quoted text clipped - 21 lines] > > So you are asserting that the OP is using GCC? No. > > For that matter, the basic principle[1] here is obvious: If something > > that's supported works correctly on OS release N and it hasn't been [quoted text clipped - 6 lines] > correct behavior is imposed on release N + 1, that's not a bug no matter > how much it inconveniences those people. No, it's a bug in release N + 1, then, or Apple should provide a workaround that allows your currently shipping software to work correctly on the new release without your software having to be changed. That's not to say that this always happens -- there's just too much software out there to be able to ensure that everything works -- but that's the way it should happen. -Eric SignatureEric Albert ejalbert@cs.stanford.edu http://outofcheese.org/ > > > I can see how you'd infer that, but you'd be wrong. :) > > > > So you are asserting that the OP is using GCC? > > No. Then you can't say I was wrong. > > > For that matter, the basic principle[1] here is obvious: If something > > > that's supported works correctly on OS release N and it hasn't been [quoted text clipped - 10 lines] > workaround that allows your currently shipping software to work > correctly on the new release without your software having to be changed. Reliance on a bug is a bug. The availability of the header in version N was a bug. The elimination of that availability is a bug fix. An OS vendor is under no compulsion to support third-party code that breaks because an assumption turned out not to be true. G SignatureChange account to gw when responding by mail. >Reliance on a bug is a bug. The availability of the header in version N >was a bug. The elimination of that availability is a bug fix. An OS >vendor is under no compulsion to support third-party code that breaks >because an assumption turned out not to be true. That isn't a good way to keep developers interested in your platform. Breaking them from release to release will scare them away, no matter how wrong their code is. It would be really nice to be able to do that, but it just isn't feasible. > >Reliance on a bug is a bug. The availability of the header in version N > >was a bug. The elimination of that availability is a bug fix. An OS [quoted text clipped - 5 lines] > how wrong their code is. It would be really nice to be able to do that, > but it just isn't feasible. It's also not long-term feasible to support people who are doing things that aren't supported. Apple tried that. It was a mess. Point to an OS vendor that handles this situation differently. SignatureChange account to gw when responding by mail. >It's also not long-term feasible to support people who are doing things >that aren't supported. Apple tried that. It was a mess. Point to an OS >vendor that handles this situation differently. Apple. Mac OS 9 still runs despite being a 'mess'. Apple. Mac OS X has workarounds, I'm sure. MicroSoft. Doesn't it still have DOS shells, and DOS shell programs run? What OS vendor doesn't bend over backwards for compatibility that has the numbers of MicroSoft or Apple? Even half of Apple? Linux doesn't count. Everything requires a simple re-compile of the kernel! ;) > >It's also not long-term feasible to support people who are doing things > >that aren't supported. Apple tried that. It was a mess. Point to an OS > >vendor that handles this situation differently. > > Apple. Mac OS 9 still runs despite being a 'mess'. Apple. Mac OS X has > workarounds, I'm sure. I wasn't saying OS 9 was a mess. I was saying that the task of supporting software that wasn't officially supported became a mess. > MicroSoft. Doesn't it still have DOS shells, and DOS shell programs run? No, and not reliably. > What OS vendor doesn't bend over backwards for compatibility that has the > numbers of MicroSoft or Apple? Even half of Apple? To the degree we're talking about here? None that I know of. Sure, Mac OS 9 still runs. But lots of marginal software from the period between 1984 and 1999 doesn't because Apple gave up supporting code that was simply wrong or that used techniques or APIs that had been deprecated years earlier. SignatureChange account to gw when responding by mail. > > >Reliance on a bug is a bug. The availability of the header in version N > > >was a bug. The elimination of that availability is a bug fix. An OS [quoted text clipped - 9 lines] > that aren't supported. Apple tried that. It was a mess. Point to an OS > vendor that handles this situation differently. There's nothing about #include <stdbool.h> that isn't supported. -Eric SignatureEric Albert ejalbert@cs.stanford.edu http://outofcheese.org/ > > > >Reliance on a bug is a bug. The availability of the header in version N > > > >was a bug. The elimination of that availability is a bug fix. An OS [quoted text clipped - 11 lines] > > There's nothing about #include <stdbool.h> that isn't supported. But using that rendition of stdbool.h with something other than GCC is(n't). Context matters. SignatureChange account to gw when responding by mail. > > > > >Reliance on a bug is a bug. The availability of the header in version > > > > >N [quoted text clipped - 15 lines] > But using that rendition of stdbool.h with something other than GCC > is(n't). Context matters. Geez, you're arguing that some random error message from some random build of some unreleased operating system means that a #include of a standard supported header isn't supported. I don't even know why I'm bothering to convince you otherwise. -Eric SignatureEric Albert ejalbert@cs.stanford.edu http://outofcheese.org/ > > > > > >Reliance on a bug is a bug. The availability of the header in > > > > > >version [quoted text clipped - 23 lines] > standard supported header isn't supported. I don't even know why I'm > bothering to convince you otherwise. I would agree that you don't know why you're trying to convince me, since your summary of what I'm saying lacks a little feature known as "accuracy." SignatureChange account to gw when responding by mail. >situation differently. > > > [quoted text clipped - 7 lines] > standard supported header isn't supported. I don't even know why I'm > bothering to convince you otherwise. Well, based on my bugreporter experiences there is a high chance the bug will be closed as "duplicate" and the original bug as "works as designed": The pragma explicitely states the desired behavior is to prevent non-GCC (Metrowerks users) to use the LGPL C libraries. BTW: Given the interdependency mess of the system and standard-C headers, and that I primarily develop plugins that need to be developed with CodeWarrior, I find this far more undesirable than most others... Regards, Tom_E SignatureThis address is valid in its unmodified form but expires soon. > >situation differently. > > > > [quoted text clipped - 12 lines] > designed": The pragma explicitely states the desired behavior is to > prevent non-GCC (Metrowerks users) to use the LGPL C libraries. This is not "works as designed". CodeWarrior users must be able to use the BSD (not LGPL) system library on Mac OS X. That said, there's no need to file this bug at this point. -Eric SignatureEric Albert ejalbert@cs.stanford.edu http://outofcheese.org/ You're right, of course. I should not have brought this up on a public channel. I'll pursue an answer with Apple and MetroWerks support. Best regards, -- Allen Cronce |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.