-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Xcode 14.1RC command line tools bootstrap fail #98
Comments
I cannot see any statement in either the C23 or the Posix 7 documentation that says that sprintf is deprecated, so this seems to be a bug. |
( FAOD, I agree completely with the comment that this function has security concerns .. but 'highly recommended' is not the same thing as saying that the function is deprecated ) This seems to be a place that the compiler should warn (for -Wextra or similar) not that should make functional builds fail. |
I bootstrapped with -Wno-deprecated-declarations but there seem to be a large number of regressions in the testsuite too .. (not analysed yet) - would be interested in any one else's experience with the 14.1RC. edit: many (maybe most) of the objective c fails come from unguarded blocks use in objc/runtime.h. |
Just installed macOS 13.0 RC, and CLT 14.1 RC. I have not yet done a build, but I am not seeing an issue at the moment with a simple test case:
Is your issue coming from the headers, from GCC itself, or from the CLT tools? |
I see the message in the headers, though, for the macOS 13 SDK:
Apparently it was already there in prior betas: dotnet/runtime#71561 |
I am on 12.6 arm - and using the 14.1RC CLT. The problem is that the SDK headers are marking the i have checked in the places available to me (C23 draft n3047 and also in the C11 DIS) and on the posix online resources -- AFAICT there is no official deprecation of this function and so Apple are effectively rejecting standard-conforming code .. which will likely break a lot of people. It is perfectly reasonable for the compiler to emit a warning about these functions, but not to add a deprecation unless/until WG41 and/or Posix do so. |
Hmm so something else has changed that presumably affects the state of |
TBH I am not sure how the claim of "compatibility only" matches up to supplying a function mandated by C and Posix stds. |
OK so it does also fail on Arm64 for 14.1b3. I guess we will need to figure out what has to be set to enable Unfortunately not had an arm box to test on during these last transitions .. just got to it yesterday (when reviewing open issues) |
FWIW: building with
is a messy, but usable work-around. |
for the record 12.6 Intel also fails with 14.1RC on master .. now I need to figure out what actually worked for testing the 14.1b3 .. because we surely did check that it fixed the problem reported for GCC12. |
12.2darwin-pre-1 does build .. so the problem could well be new to master |
|
(having made an initial assessment) removing all uses of sprintf () from GCC is a non-trivial project [it might well be both acceptable, and welcomed, but it will take some work, likely too much to be done in GCC-13] |
So on Darwin21 (macOS 12) the CLT 14.1RC installs with MacOSX.sdk -> MacOSX13.0.sdk (usually, the install on an older OS version points to the correct SDK for the version - so, in this case, one might expect MacOSX.sdk -> MacOSX12.sdk) Sometimes there have been issues with Availability macros and building with a newer SDK .. so ...
I thought someone reported that this function had been deprecated in earlier SDKs - but it does not seem to be in MacOSX12.sdk |
hmm this is gradually becoming more complex. taking p.c/cc as
If we compile this with:
edit: checked the C++23 CD, there's no deprecation note associated with sprintf (the contents of The only difference in using !!! Xcode 13.4 CLT does honour right now, I did not succeed yet in tracking down what is happening differently (or even where |
OK so (i think) explained the reason that "C" does not give this warning; it is because we default to fortified sources, which causes us to use sprintf_chk instead of sprintf.
Fails too. |
OK so it seems that three factors and IMO a genuine bug together have led to confusion.
for example:
GCC-13 (master):
@fxcoudert - IDK if any of your lines of contact could help get this sorted? The bug: The code in #98 (comment) is standard-compliant C++ and should compile without any warnings for: clang++ -std=c++xx (for all current xx and 23 draft). it does not. We should try to get this fixed ASAP .. because there really is no simple way to work around it. The deprecations should be "opt-in" on some "clean up my sources" option... |
I think at this stage it is unlikely to be fixed. I got confirmation that the deprecation warning, even for standard code, was a deliberate decision. 😢 |
Then, AFAICT, that decision makes the implementation non-conforming :(.
|
In gcc we can fixinclude it. |
yeah, I will look into that as soon as the Xcode 14.1 release is made (I'm away from most of my infrastructure right now) .. fixincludes is sad, but necessary sometimes. |
since this effects upstream Darwin, I am closing here and tracking should be done in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568 |
I tried the RC on my latest master ...
Anyone else (@fxcoudert ?) have experience with this RC on other branches?
The text was updated successfully, but these errors were encountered: