When compiling a very simple program with Clang++, vanilla version 16 (not intel version), I get warnings that do not arise when compiling with the dpcpp compiler. I am concerned since I have no way to know if the warnings will mean that my code will be malfunctioning in some way at runtime.
This minimal code generates some warnings about interop_handler being deprecated:
#include <CL/sycl.hpp>
int main(){}
The command issued is the following, where INCLUDEDIR is used to indicate where the SYCL headers are:
clang++ -std=c++17 -I$INCLUDEDIR -c t.cpp
The warnings are:
In file included from t.cpp:1:
In file included from /ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl.hpp:16:
In file included from /ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl/backend.hpp:18:
In file included from /ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl/detail/backend_traits_opencl.hpp:26:
In file included from /ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl/queue.hpp:20:
In file included from /ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl/handler.hpp:14:
In file included from /ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl/detail/cg.hpp:27:
/ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl/detail/cg_types.hpp:234:32: warning: 'interop_handler' is deprecated: interop_handler class is deprecated, use interop_handle instead with host-task [-Wdeprecated-declarations]
std::function<void(cl::sycl::interop_handler)> MFunc;
^
/ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl/interop_handler.hpp:18:7: note: 'interop_handler' has been explicitly marked deprecated here
class __SYCL_DEPRECATED("interop_handler class is deprecated, use"
^
/ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl/detail/defines_elementary.hpp:45:38: note: expanded from macro '__SYCL_DEPRECATED'
#define __SYCL_DEPRECATED(message) [[deprecated(message)]]
^
In file included from t.cpp:1:
In file included from /ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl.hpp:16:
In file included from /ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl/backend.hpp:18:
In file included from /ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl/detail/backend_traits_opencl.hpp:26:
In file included from /ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl/queue.hpp:20:
In file included from /ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl/handler.hpp:14:
In file included from /ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl/detail/cg.hpp:27:
/ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl/detail/cg_types.hpp:237:44: warning: 'interop_handler' is deprecated: interop_handler class is deprecated, use interop_handle instead with host-task [-Wdeprecated-declarations]
InteropTask(std::function<void(cl::sycl::interop_handler)> Func)
^
/ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl/interop_handler.hpp:18:7: note: 'interop_handler' has been explicitly marked deprecated here
class __SYCL_DEPRECATED("interop_handler class is deprecated, use"
^
/ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl/detail/defines_elementary.hpp:45:38: note: expanded from macro '__SYCL_DEPRECATED'
#define __SYCL_DEPRECATED(message) [[deprecated(message)]]
^
In file included from t.cpp:1:
In file included from /ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl.hpp:16:
In file included from /ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl/backend.hpp:18:
In file included from /ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl/detail/backend_traits_opencl.hpp:26:
In file included from /ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl/queue.hpp:20:
In file included from /ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl/handler.hpp:14:
In file included from /ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl/detail/cg.hpp:27:
/ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl/detail/cg_types.hpp:239:23: warning: 'interop_handler' is deprecated: interop_handler class is deprecated, use interop_handle instead with host-task [-Wdeprecated-declarations]
void call(cl::sycl::interop_handler &h) { MFunc(h); }
^
/ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl/interop_handler.hpp:18:7: note: 'interop_handler' has been explicitly marked deprecated here
class __SYCL_DEPRECATED("interop_handler class is deprecated, use"
^
/ONE_API_2022.3/compiler/2022.2.0/linux/include/sycl/CL/sycl/detail/defines_elementary.hpp:45:38: note: expanded from macro '__SYCL_DEPRECATED'
#define __SYCL_DEPRECATED(message) [[deprecated(message)]]
^
3 warnings generated.
As said, this happens with a minimal example; with more complicated SYCL code there would be more warnings. I want to know if I should be concerned and if there is some way to solve the warnings.
When you copy /ONE_API_2022.3/compiler/2022.2.0/linux/include/ into local directory and invoke dpcpp with these includes copied includes
dpcpp -Iinclude/sycl/ -Iinclude -c t.cpp
then you'll also see a lot of deprecation warnings.
dpcpp does some magic so you don't have to specify -I manually when calling dpcpp. I guess the same magic silences deprecation warning from these automatically included files.
You cannot compile a SYCL program with clang like that.
In order to compile a SYCL program you will need:
A working SYCL compiler (i.e. openSYCL, oneAPI DPC++)
Or a library implementation of the SYCL standard to link your program against (but I don't know if such implementation exists).
You can check the available SYCL implementation here
I have a solution with 2 projects, one is a static library and the other is an application that
links to it. In the static library I have a pre-compiled header file with the following code:
#pragma once
//C standard Library
#include <stdio.h>
//C++ Standard Library
#include <iostream>
#include <fstream>
#include <sstream>
#include <memory>
#include <functional>
//Data Structures
#include <string>
#include <vector>
#include <array>
#include <map>
#include <set>
#include <unordered_map>
#include <unordered_set>
I have also added the necessary .cpp file and configured the project properties to use this specific pre-
compiled header. I also added the .h file to the top of every .cpp file as required. I proceeded to my
latter project and properly referenced the static library and wrote some simple code, here is an
example:
class Test : public Craft::Application
{
public:
Test()
{
}
~Test()
{
}
};
Craft::Application* Craft::CreateApplication()
{
return new Test;
}
This returned Test object will be linked with an entry point and proceeds through the pipeline and
encounters code from the std library, that's when I get these errors:
error C2039: 'string': is not a member of 'std'
message : see declaration of 'std'
error C3646: 'Title': unknown override specifier
error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
error C2039: 'string': is not a member of 'std'
message : see declaration of 'std'
error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
error C2143: syntax error: missing ',' before '&'
error C2065: 'title': undeclared identifier
error C2065: 'width': undeclared identifier
error C2065: 'height': undeclared identifier
error C2614: 'Craft::Window::WindowProps': illegal member initialization: 'Title' is not a base or member
error C2039: 'unique_ptr': is not a member of 'std'
message : see declaration of 'std'
error C2143: syntax error: missing ';' before '<'
error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
error C2238: unexpected token(s) preceding ';'
I understand that this project doesn't recognize the header files in my pre-compiled header. I can
confirm that as I included these files in the application and this resolved all errors. This sparks many
questions though: This project links to the library, so why doesn't it recognize this pre-compiled
header? What's the best solution for this? Is it a pre-compiled header per project? Is it something
entirely else?
The solution is simply including your pch in every source file and adding any necessary headers used by the header file. The compiler will still use the pch but will also be able to define your functions in the header file.
I am using Xcode 7.3, and I am getting an "Ambiguous expansion of macro" warning, for a macro which was defined in Foundation, but which I have undefined and re-defined in my prefix file. I have modules enabled.
To reproduce:
Set "Enable Modules (C and Objective-C)" to Yes in build settings
Use the following prefix file:
#import <Foundation/Foundation.h>
#undef assert
#define assert(e) NSLog(#"hi") // implementation is not important
Use the following main source file:
int main() {
assert(42);
return 0;
}
Then build in Xcode.
It shows an "Ambiguous expansion of macro 'assert'" warning on the line in the source file that uses the "assert" macro. The "Expanding this definition of 'assert'" points to the definition from the system header, not my redefinition. The "Other definition of 'assert'" points to the definition in my prefix file.
This warning does not happen when modules is disabled.
This is a bug in Xcode; we'd appreciate if you could file a bug report at https://bugreport.apple.com and leave the bug # in a comment here. Your options for working around this bug in the meantime are:
You could use a different name than "assert" for this macro.
You could set the GCC_PRECOMPILE_PREFIX_HEADER build setting to NO, since PCH don’t provide a lot of benefit when you already have modules. The prefix header will still work, it just won’t be turned into a PCH.
You could turn off modules.
I want to start using Swift in my Objective-C project. So i added a swift class:
import Foundation
#objc class System : NSObject {
#objc func printSome() {
println("Print line System");
}
}
And imported it into a .m file:
#import "MyProjectName-Swift.h"
When building my project i get the following error:
Bridging header 'PathToMyProject/MyProjectName-Bridging-Header.h' does not exist
NOTE: Under "Build Settings->Swift Compiler - Code Generation->Objective-C Briding Header" is set to MyProjectName-Bridging-Header.h
What should i do to solve this issue?
Any help is much appreciated.
EDIT: Bridging-Header file:
#if defined(__has_include) && __has_include()
# include
#endif
#include <objc/NSObject.h>
#include <stdint.h>
#include <stddef.h>
#include <stdbool.h>
#if defined(__has_include) && __has_include(<uchar.h>)
# include <uchar.h>
#elif __cplusplus < 201103L
typedef uint_least16_t char16_t;
typedef uint_least32_t char32_t;
#endif
#if !defined(SWIFT_PASTE)
# define SWIFT_PASTE_HELPER(x, y) x##y
# define SWIFT_PASTE(x, y) SWIFT_PASTE_HELPER(x, y)
#endif
#if !defined(SWIFT_METATYPE)
# define SWIFT_METATYPE(X) Class
#endif
#if defined(__has_attribute) && __has_attribute(objc_runtime_name)
# define SWIFT_RUNTIME_NAME(X) __attribute__((objc_runtime_name(X)))
#else
# define SWIFT_RUNTIME_NAME(X)
#endif
#if !defined(SWIFT_CLASS_EXTRA)
# define SWIFT_CLASS_EXTRA
#endif
#if !defined(SWIFT_PROTOCOL_EXTRA)
# define SWIFT_PROTOCOL_EXTRA
#endif
#if !defined(SWIFT_CLASS)
# if defined(__has_attribute) && __has_attribute(objc_subclassing_restricted)
# define SWIFT_CLASS(SWIFT_NAME) SWIFT_RUNTIME_NAME(SWIFT_NAME) __attribute__((objc_subclassing_restricted)) SWIFT_CLASS_EXTRA
# else
# define SWIFT_CLASS(SWIFT_NAME) SWIFT_RUNTIME_NAME(SWIFT_NAME) SWIFT_CLASS_EXTRA
# endif
#endif
#if !defined(SWIFT_PROTOCOL)
# define SWIFT_PROTOCOL(SWIFT_NAME) SWIFT_RUNTIME_NAME(SWIFT_NAME) SWIFT_PROTOCOL_EXTRA
#endif
#if !defined(SWIFT_EXTENSION)
# define SWIFT_EXTENSION(M) SWIFT_PASTE(M##_Swift_, __LINE__)
#endif
#if !defined(OBJC_DESIGNATED_INITIALIZER)
# if defined(__has_attribute) && __has_attribute(objc_designated_initializer)
# define OBJC_DESIGNATED_INITIALIZER __attribute__((objc_designated_initializer))
# else
# define OBJC_DESIGNATED_INITIALIZER
# endif
#endif
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wproperty-attribute-mismatch"
#if defined(__has_feature) && __has_feature(modules)
#endif
#pragma clang diagnostic pop
If the bridging file is created at the same level as the other classes, you might need to add the relative path, as these pictures show. Note here that the bridging file is created at the same level as the other classes:
I have the name entered correctly in the Build Settings,
but the compiler doesn't find the file.
Therefore, if I add the relative path from the root of the project (that is, I add ./ProjectName/BridgerFileName.h),
now it compiles and I can call a method in my Objective C class:
I found that after creating the bridging header file manually and choosing the default name and location, the bridging header will be placed in the project directory, which is under the root directory.
This requires the following value for the setting: Targets > [Your App Target] > Build Settings > Swift Compiler - Code Generation > Objective-C Bridging Header:
$(SRCROOT)/$(PROJECT_NAME)/$(PROJECT_NAME)-Bridging-Header.h
Note that if your project is a swift module (framework) then, as pointed out in the comments, you might prefer:
$(SRCROOT)/$(PROJECT_NAME)/$(SWIFT_MODULE_NAME)-Bridging-Header.h
For those who are removing the Bridging Header
I was going the opposite way as most of the other answers here. I had been using a Bridging Header previously, but I didn't need it anymore. After I deleted it from my project I started getting the error mentioned in the question. I performed the following steps to solve my problem.
Go to Targets > [Your App Target] > Build Settings > Swift Compiler - General > Objective-C Bridging Header and delete the path. (Thanks to #Donamite for the idea.) （You can just start typing "bridging" into the search box to find it.)
Delete the derived date. Go to Xcode > Preferences > Locations and click the gray arrow by the Derived Data folder. Then delete your project folder.
In Swift 4.1
your project you don't have bridging-Header.h file, but your project has that path. For this you need to delete that path...
Go to targets file and select Build Settings, ---->Swift Compiler - General, and delete the bridging-Header.h. Follow below screen shots....
Delete the bridging-Header.h file in Swift Compiler - General
Now you got like this...
These are steps to create Bridging header.
File->New->iOS->Header File, Give the bridging file name as like "yourProjectName-Bridging-Header.h"
Build-Settings->Objective-C Bridging Header, Just give the bridging header file name be like "ProjectName-Bridging-Header.h"
NOTE: Bridging header file should be located in the main root folder of the project where the ".xcodeproj" file located. If not move the Bridging header file to the root folder of the project. This way Xcode able to access the bridge file.
Build the project, and import necessary files in Bridging header.
To add Bridge File in Swift project.
Step 1. Go to File > Add Cocoa with Objective-C File (For temporary Purpose)
Step 2. Then the following pop up will appear
Now press Create Bridging Header Button
DONE
YOU WILL GET BRIGDE FILE IN BUNDLE
THANKS
For me it helped to use $(SRCROOT)/$(PROJECT_NAME)/ in front of my bridging header file path
For me it helped to use $(SRCROOT) in front of my Objective-C bridging header path.
$(SRCROOT)/swiftLibraries/swiftLibraries-Bridging-Header.h
Follow the steps below:
Delete bridging header file . . . (Maybe you create manually) and;
Create new Swift file in Objective-C Project . . . (Not import, first create it)
Maybe these two things will help solve your problem.
The following worked for me:
Bridging header file should be located in the main root folder of the project where the ".xcodeproj" file located. Move to project directory and drag and drop bridging header to root if it is inside any other folder.
Correct spelling mistakes in header name.
Clear Derived data
Target -> Build Settings -> Swift Compiler : General -> Add Obj C Header name.
Clean and run again.
Creating Bridging Header File Manually
First of all delete the Bridging header file which Xcode is created. And Select your project goto > Build Settings > Search the keyword. Swift Compiler - Code Generation. Click on Objective-C Bridging Header , delete that path. Now clean your Project.
Now select your project > Window in the navigation bar . Select Projects and delete your derived data from there.
Now create a new file , select the Source and then select the Header File and create your Bridging header file . File name must be your projectname-Bridging-Header.h and then create it
Select your project goto > Build Settings > Search the keyword. Swift Compiler - Code Generation. Click on Objective-C Bridging Header and now add the path in this Objective-C Bridging Header like projectname-Bridging-Header.h
Now import your classes into bridging header file and you can compile it your code easily.
Your bridging header file looks like this when you are creating your file manually.
What helped me was to move the file manually to the path mentioned in an error message. So:
I deleted the file (moved to trash)
Moved it from trash to the path in an error message
Later I also had to clean the project
This error happens when I try to import the file "VARendererViewController.h" from the file "VAMenuScreenViewController"
duplicate symbol _gestureMinimumTranslation in:
/Users/Sam/Library/Developer/Xcode/DerivedData/Virtual_Human_Avatar-fwgdkxpnkzapxrdzkggtmbnfhjwb/Build/Intermediates/Virtual Human Avatar.build/Debug-iphonesimulator/Virtual Human Avatar.build/Objects-normal/i386/VARendererViewController.o
/Users/Sam/Library/Developer/Xcode/DerivedData/Virtual_Human_Avatar-fwgdkxpnkzapxrdzkggtmbnfhjwb/Build/Intermediates/Virtual Human Avatar.build/Debug-iphonesimulator/Virtual Human Avatar.build/Objects-normal/i386/VAMenuScreenViewController.o
ld: 1 duplicate symbol for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Could anyone provide me with some
You have two compilation units -- two source files -- that are defining the same symbol.
This may be because you defined the symbol in two separate .m files (or other compilation unit; .c, .mm, etc...) or because you defined the symbol in a header file and imported it into those two files. Alternatively, if you shove a variable declaration into a header file without the extern, then it'll cause a symbol by that name to be created in every .m file it is imported into.
Assuming gestureMinimumTranslation is a variable, then if you really want a global variable, it should be defined in only one .m file as follows:
int gestureMinimumTranslation;
Then, in the corresponding header:
extern int gestureMinimumTranslation;
And the other .m file should import the above header.
The linker is trying to join a set of objects with a common symbol. This often happens when the Compile Sources Build Phase has duplicate entries or a header file. Try removing these.