Error use of undeclared identifier nullptr - Исправление ошибок и поиск оптимальных решений проблем

Я пытаюсь скомпилировать исходники с Visual Studio 2008 Express, но я получаю эту ошибку:

Error C2065: 'nullptr' undeclared identifier.

Мой код:

if (Data == nullptr)
{
show("Data is null");
return 0;
}

Я прочитал в Google, что мне нужно перейти на Visual Studio 2010, но я не хочу этого делать из-за intelisense 2008 года. Это можно починить или заменить?

Решение

Вы получаете ошибку, потому что компилятор не распознает nullptr ключевое слово. Это потому что nullptr была представлена в более поздней версии Visual Studio, чем та, которую вы используете.

Есть два способа заставить это работать в старой версии. Одна идея пришла из книги Скотта Мейерса c ++, где он предлагает создать заголовок с классом, который эмулирует nullptr как это:

const // It is a const object...
class nullptr_t
{
public:
template<class T>
inline operator T*() const // convertible to any type of null non-member pointer...
{ return 0; }

template<class C, class T>
inline operator T C::*() const   // or any type of null member pointer...
{ return 0; }

private:
void operator&() const;  // Can't take address of nullptr

} nullptr = {};

Таким образом, вам просто нужно условно включить файл в зависимости от версии msvc

#if _MSC_VER < 1600 //MSVC version <8
#include "nullptr_emulation.h"#endif

Это имеет преимущество в использовании того же ключевого слова и делает обновление до нового компилятора довольно простым (и, пожалуйста, сделайте обновление, если можете). Если вы сейчас компилируете с более новым компилятором, то ваш пользовательский код вообще не используется, и вы используете только язык c ++, я чувствую, что это важно в будущем.

Если вы не хотите использовать этот подход, вы можете использовать что-то, что эмулирует старый подход в стиле C (#define NULL ((void *)0)) где вы делаете макрос для NULL как это:

#define NULL 0

if(data == NULL){
}

Обратите внимание, что это не совсем то же самое, что NULL как найдено в C, для дальнейшего обсуждения см. этот вопрос: Почему указатели NULL по-разному определяются в C и C ++?

Недостатками этого является то, что вы должны изменить исходный код, и он не является безопасным nullptr, Так что используйте это с осторожностью, это может привести к некоторым тонким ошибкам, если вы не будете осторожны, и именно эти тонкие ошибки мотивировали развитие nullptr на первом месте.

Другие решения

nullptr является частью C ++ 11, в C ++ 03 вы просто используете 0:

if (!Data)

Источник

Ошибка, которую вы получаете, заключается в том, что компилятор не распознает ключевое слово nullptr. Это связано с тем, что nullptr был представлен в более поздней версии визуальной студии, чем тот, который вы используете.

Есть два способа, с помощью которых вы можете работать в более старой версии. Одна идея взята из книги Скотта Мейерса С++, где он предлагает создать заголовок с классом, который эмулирует nullptr следующим образом:

const // It is a const object...
class nullptr_t 
{
  public:
    template<class T>
    inline operator T*() const // convertible to any type of null non-member pointer...
    { return 0; }

    template<class C, class T>
    inline operator T C::*() const   // or any type of null member pointer...
    { return 0; }

  private:
    void operator&() const;  // Can't take address of nullptr

} nullptr = {};

Таким образом вам просто нужно условно включить файл на основе версии msvc

#if _MSC_VER < 1600 //MSVC version <8
     #include "nullptr_emulation.h"
#endif

Это имеет преимущество при использовании одного и того же ключевого слова и упрощает обновление для нового компилятора (и, пожалуйста, обновите его, если возможно). Если вы сейчас компилируете новый компилятор, тогда ваш собственный код вообще не будет использоваться, и вы используете только язык С++, мне кажется, что это важно в будущем.

Если вы не хотите использовать этот подход, вы можете пойти с чем-то, что эмулирует старый подход стиля C (#define NULL ((void *)0)), где вы создаете макрос для NULL следующим образом:

#define NULL 0

if(data == NULL){
}

Обратите внимание, что это не совсем то же самое, что NULL, как найдено в C, для более подробного обсуждения этого вопроса: Почему указатели NULL определены по-разному в C и С++?

Недостатком этого является то, что вам нужно изменить исходный код, и он не типизируется, как nullptr. Поэтому используйте это с осторожностью, он может ввести некоторые тонкие ошибки, если вы не будете осторожны, и именно эти тонкие ошибки в первую очередь мотивировали развитие nullptr.

Источник

Hi Thanks for the work.

I am trying to build latest JOCL on Mac OS X. I generated XCode builds.
However, it is failing with undefined references for nullptr.

/Users/abc/JOCLRoot/JOCLCommon/src/main/native/ConversionsCL.hpp:134:14: 
error: no member named 'memcpy' in namespace 'std'
        std::memcpy(nativeObject, primitiveArray, length * sizeof(JavaType));

Users/abc/JOCLRoot/JOCLCommon/src/main/native/ConversionsCL.hpp:138:20: error: use of undeclared identifier 'nullptr'
    nativeObject = nullptr;

Would it be possible to get Mac Build any time sooner ?

ashishnegi

changed the title
Breaking builds for Mac

Builds breaking for Mac

Apr 3, 2016

Copy link

Contributor

Author

I added c++11 support flags to Xcode and now simpler errors have gone.
I am now getting :

Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/ConversionsCL.hpp:63:9: error: use of undeclared identifier 'ThrowByName'
        ThrowByName(env, "java/lang/OutOfMemoryError",

and

/Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/ConversionsCL.cpp:312:23: error: no member named 'x' in 'cl_float2'
        values_native.x = (cl_float)localValues[0];

Can you give some reference to how to solve them ?

Copy link

Contributor

Author

Finally i managed to generate the jar and dylib. That required some changes in XCode project settings as well. To port them to CMake, i would require some help. I have not worked on CMake before.
Changes are :

JOCL Project chagnes :

In xcode :
Build Settings : Search Paths : Header Search Paths :
Add «/System/Library/Frameworks/OpenGL.framework/Headers»
I found that their is flag JNI_INCLUDE_DIRS. Can this be used for it ?
Would setting this flag during configuration/generation would be right. This would add a step in Readme?

I found that currently their is «/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/JavaVM.framework/Headers» also added to Header-Paths.
Is that the wrong detected «JNI_INCLUDE_DIRS» ?

** We can also add compiler flag «-framework OpenCl».
However, it does not seem to work for me.

JOCL and JOCLCommon:

In Xcode : C++ Language Dialect :

C++11 => -std=c++11
C++ standard library => libc++
How is c++11 is used in windows ?
I could not find any reference in CMakefiles.

Apart from the project changes, their are some code changes as well.

Thanks for investigating this. Until now, I did not receive similar hints from the contributors of the MacOS binaries, so I’m a bit surprised to see that it seems to be such a hassle to compile it.

But the nullptr might indeed be new. Until now, I usually used NULL, but with C++11, I think that nullptr should be used. According to https://cmake.org/cmake/help/v3.1/prop_tgt/CXX_STANDARD.html , it should be possible to add the required flag in CMake.It would be great if you could confirm that adding

set_property(TARGET JOCLCommon PROPERTY CXX_STANDARD 11)

and

set_property(TARGET JOCL_${JOCL_VERSION}-${JOCL_HOST}-${JOCL_ARCH} PROPERTY CXX_STANDARD 11)

to the JOCLCommon and JOCL makefiles, respectively, resolves this. (I’ll have to increase the required CMake version to 3.1 then, but that should be fine)

Regarding the GL headers: I’ll have to investigate this a bit further (and am currently wondering why this is not required on other platforms — I’ll have to check whether the GL includes come from on Windows, I obviously overlooked something here…)

However, adding

find_package(OpenGL REQUIRED)
link_directories(${OpenGL_LIBRARY_DIRS})
include_directories(${OpenGL_INCLUDE_DIR})

should also solve this, correct?

(The JNI_INCLUDE_DIRS do only refer to JNI itself, and it looks like they are found correctly. The OpenGL include should be covered with the OpenGL_INCLUDE_DIR, which should be found as described above.)

Did the code changes that you mentioned refer to an

that may be missing at https://github.com/gpu/JOCLCommon/blob/master/src/main/native/JOCLCommon.hpp#L42 ?

What I did not yet understand was your comment regarding the compiler flag -framework OpenCl — or was this just an attempt to find the OpenGL headers? (They should be fairly unrelated, though…)

Copy link

Contributor

Author

Copy link

Contributor

Author

Please ignore my comment d) about __CL_HAS_ANON_STRUCT__.
This error went away after the CMakefile changes.

Copy link

Contributor

Author

I have raised pull requests in JOCL and JOCLCommon for that builds the project.

Thanks for the pull requests. I have tested them, and would pull them with minor corrections tomorrow.

EDIT: For reference
gpu/JOCLCommon#1
#2

I just pulled the fixes that you provided, and also updated the CL header files with the latest 2.0 headers from Khronos. Interestingly, the cl_platform.h was unmodified, but others now include the cl_platform.h on Apple. However, this should not affect this issue, so I think it can be closed now.

So thanks again for your contribution!

Copy link

Contributor

Author

Would you need the mac binaries with latest changes ?

Sure, the Mac binaries of the last version are not yet available in the current download or Maven Central. If you could provide them, that would be great.

Copy link

Contributor

Author

I would be able to give by this weekend.

Copy link

Contributor

Author

Unfortunately.. because of header upgrades.. the build is now failing..
Like : undefined cl_queue_properties

As we are now including opencl/cl.h instead of cl.h , these types are not defined in opencl/cl.h..

Errors :

In file included from /Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/ConversionsCL.cpp:33:
/Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/CLJNIUtils.hpp:174:1: error: unknown type name 'cl_queue_properties'
cl_queue_properties* createQueuePropertiesArray(JNIEnv *env, jobject properties);
^
/Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/CLJNIUtils.hpp:175:1: error: unknown type name 'cl_pipe_properties'; did you mean 'cl_context_properties'?
cl_pipe_properties* createPipePropertiesArray(JNIEnv *env, jobject properties);
^~~~~~~~~~~~~~~~~~
cl_context_properties
In file included from /Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/ConversionsCL.cpp:27:
In file included from /Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/ConversionsCL.hpp:35:
In file included from /Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/JOCLCommon.hpp:42:
In file included from /Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/include/CL/opencl.h:40:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/OpenCL.framework/Headers/cl.h:62:29: note: 'cl_context_properties' declared here
typedef intptr_t            cl_context_properties;
                            ^
In file included from /Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/ConversionsCL.cpp:33:
/Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/CLJNIUtils.hpp:176:1: error: unknown type name 'cl_sampler_properties'; did you mean 'cl_context_properties'?
cl_sampler_properties* createSamplerPropertiesArray(JNIEnv *env, jobject properties);
^~~~~~~~~~~~~~~~~~~~~
cl_context_properties
In file included from /Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/ConversionsCL.cpp:27:
In file included from /Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/ConversionsCL.hpp:35:
In file included from /Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/JOCLCommon.hpp:42:
In file included from /Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/include/CL/opencl.h:40:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/OpenCL.framework/Headers/cl.h:62:29: note: 'cl_context_properties' declared here
typedef intptr_t            cl_context_properties;
                            ^
3 errors generated.

Current OpenCl/cl.h

/*******************************************************************************
 * Copyright (c) 2008 - 2012 The Khronos Group Inc.
 *
 * Permission is hereby granted, free of charge, to any person obtaining a
 * copy of this software and/or associated documentation files (the
 * "Materials"), to deal in the Materials without restriction, including
 * without limitation the rights to use, copy, modify, merge, publish,
 * distribute, sublicense, and/or sell copies of the Materials, and to
 * permit persons to whom the Materials are furnished to do so, subject to
 * the following conditions:
 *
 * The above copyright notice and this permission notice shall be included
 * in all copies or substantial portions of the Materials.
 *
 * THE MATERIALS ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
 * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
 * IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
 * CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
 * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
 * MATERIALS OR THE USE OR OTHER DEALINGS IN THE MATERIALS.
 ******************************************************************************/

#ifndef __OPENCL_CL_H
#define __OPENCL_CL_H

#ifdef __APPLE__
#include <OpenCL/cl_platform.h>
#else

From googling around the last 2 hours.. i think that it is not possible to get newer version of opencl on Mac OS X.. However, Khronos website says that All of the following headers should be present in a directory CL/ (or OpenCL/ on MacOS X). even for 2.1 headers..
Can you give some suggestions about this ?
Thanks.

(EDIT: Also see the notes at the bottom)

It seems that in this https://github.com/gpu/JOCLCommon/blob/master/src/main/include/CL/opencl.h#L40 it is including the header from the «Frameworks» directory, although it should use the local ones. Sure, locally there is no «OpenCL» directory, so it can not find them. (The headers in the «Frameworks» directory seem to be from OpenCL 1.2, and not 2.0).

I’m not sure about the best and most portable solution for this (I’m afraid there are subtle details regarding the include path search on Mac and this «Frameworks» folder handling…).

A very crude «hack», just to see whether this really is the reason: What happens when you copy the local «/include/CL» folder to create an additional folder «/include/OpenCL» ?

I guess, somehow it has to be told to not use the «Frameworks» headers, but the local ones…

EDIT: In doubt, it worked properly with the previous version, without the Apple-Specific includes. So instead of copying the whole folder, could you try whether it works when using the previous version of the opencl.h:

https://github.com/gpu/JOCLCommon/blob/39183e245a8a3366ef9e6ebb1b602df4d81870af/src/main/include/CL/opencl.h

If this works, I’ll just omit the Apple-specific lookup, so that it only works on the files in the local include path.

Note that there has been another update that may be related to this one — see #3 (comment)

On Mac OS X 10.11.3 ：
[linkerlin@MBP JOCLCommon]$ make
[ 16%] Building CXX object CMakeFiles/JOCLCommon.dir/src/main/native/Logger.cpp.o
[ 33%] Building CXX object CMakeFiles/JOCLCommon.dir/src/main/native/CLJNIUtils.cpp.o
In file included from /Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:31:
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.hpp:174:1: error: unknown type
name ‘cl_queue_properties’
cl_queue_properties* createQueuePropertiesArray(JNIEnv env, jobject properties);
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.hpp:175:1: error: unknown type
name ‘cl_pipe_properties’; did you mean ‘cl_context_properties’?
cl_pipe_properties createPipePropertiesArray(JNIEnv env, jobject properties);
^~~~~~~~~~~~~~~~~~
cl_context_properties
/System/Library/Frameworks/OpenCL.framework/Headers/cl.h:62:29: note:
‘cl_context_properties’ declared here
typedef intptr_t cl_context_properties;
^
In file included from /Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:31:
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.hpp:176:1: error: unknown type
name ‘cl_sampler_properties’; did you mean ‘cl_context_properties’?
cl_sampler_properties createSamplerPropertiesArray(JNIEnv env, jobject properties);
^~~~~~~~~~~~~~~~~~~~~
cl_context_properties
/System/Library/Frameworks/OpenCL.framework/Headers/cl.h:62:29: note:
‘cl_context_properties’ declared here
typedef intptr_t cl_context_properties;
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:213:1: error: unknown type
name ‘cl_queue_properties’
cl_queue_properties createQueuePropertiesArray(JNIEnv env, jobject properties)
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:235:5: error: unknown type
name ‘cl_queue_properties’
cl_queue_properties *nativeProperties = new cl_queue_properties[javaProperties…
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:235:49: error: unknown
type name ‘cl_queue_properties’
cl_queue_properties *nativeProperties = new cl_queue_properties[javaProperties…
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:245:32: error: use of
undeclared identifier ‘cl_queue_properties’
nativeProperties[i] = (cl_queue_properties)javaPropertyValues[i];
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:261:1: error: unknown type
name ‘cl_pipe_properties’; did you mean ‘cl_context_properties’?
cl_pipe_properties createPipePropertiesArray(JNIEnv env, jobject properties)
^~~~~~~~~~~~~~~~~~
cl_context_properties
/System/Library/Frameworks/OpenCL.framework/Headers/cl.h:62:29: note:
‘cl_context_properties’ declared here
typedef intptr_t cl_context_properties;
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:283:5: error: unknown type
name ‘cl_pipe_properties’; did you mean ‘cl_context_properties’?
cl_pipe_properties *nativeProperties = new cl_pipe_properties[javaPropertiesSize + 1];
^~~~~~~~~~~~~~~~~~
cl_context_properties
/System/Library/Frameworks/OpenCL.framework/Headers/cl.h:62:29: note:
‘cl_context_properties’ declared here
typedef intptr_t cl_context_properties;
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:283:48: error: unknown
type name ‘cl_pipe_properties’; did you mean ‘cl_context_properties’?
cl_pipe_properties *nativeProperties = new cl_pipe_properties[javaPropertiesSize + 1];
^~~~~~~~~~~~~~~~~~
cl_context_properties
/System/Library/Frameworks/OpenCL.framework/Headers/cl.h:62:29: note:
‘cl_context_properties’ declared here
typedef intptr_t cl_context_properties;
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:293:32: error: unknown
type name ‘cl_pipe_properties’; did you mean ‘cl_context_properties’?
nativeProperties[i] = (cl_pipe_properties)javaPropertyValues[i];
^~~~~~~~~~~~~~~~~~
cl_context_properties
/System/Library/Frameworks/OpenCL.framework/Headers/cl.h:62:29: note:
‘cl_context_properties’ declared here
typedef intptr_t cl_context_properties;
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:309:1: error: unknown type
name ‘cl_sampler_properties’; did you mean ‘cl_context_properties’?
cl_sampler_properties createSamplerPropertiesArray(JNIEnv env, jobject properties)
^~~~~~~~~~~~~~~~~~~~~
cl_context_properties
/System/Library/Frameworks/OpenCL.framework/Headers/cl.h:62:29: note:
‘cl_context_properties’ declared here
typedef intptr_t cl_context_properties;
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:331:5: error: unknown type
name ‘cl_sampler_properties’; did you mean ‘cl_context_properties’?
cl_sampler_properties *nativeProperties = new cl_sampler_properties[javaProper…
^~~~~~~~~~~~~~~~~~~~~
cl_context_properties
/System/Library/Frameworks/OpenCL.framework/Headers/cl.h:62:29: note:
‘cl_context_properties’ declared here
typedef intptr_t cl_context_properties;
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:331:51: error: unknown
type name ‘cl_sampler_properties’; did you mean ‘cl_context_properties’?
cl_sampler_properties *nativeProperties = new cl_sampler_properties[javaProper…
^~~~~~~~~~~~~~~~~~~~~
cl_context_properties
/System/Library/Frameworks/OpenCL.framework/Headers/cl.h:62:29: note:
‘cl_context_properties’ declared here
typedef intptr_t cl_context_properties;
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:341:32: error: unknown
type name ‘cl_sampler_properties’; did you mean ‘cl_context_properties’?
nativeProperties[i] = (cl_sampler_properties)javaPropertyValues[i];
^~~~~~~~~~~~~~~~~~~~~
cl_context_properties
/System/Library/Frameworks/OpenCL.framework/Headers/cl.h:62:29: note:
‘cl_context_properties’ declared here
typedef intptr_t cl_context_properties;
^
15 errors generated.
make[2]: ** [CMakeFiles/JOCLCommon.dir/src/main/native/CLJNIUtils.cpp.o] Error 1
make[1]: *** [CMakeFiles/JOCLCommon.dir/all] Error 2
make: *** [all] Error 2

It still seems to refer to the System/Library/Frameworks/OpenCL.framework/Headers/ — although it should refer to the local headers from the repository. (It needs the OpenCL 2.0 headers, even if only OpenCL 1.2 is installed in the «Frameworks» directory).

(I’ll re-check the headers from the repo, but they should already be the 2.0 headers)

Do you know any way to convince CMake to not look into the Frameworks directory, but only into the local one? (Otherswise, I’ll try to dig into this, but it’s hard to test on non-MacOS-machines)

Copy link

Contributor

Author

@gpu I would be able to look into this day after tomorrow.
I would like to ask one thing though. Even if we compile it with 2.0 headers, at run-time.. does JOCL falls back to the actual run-time opencl version present on the user’s system ?

Yes, this is the basic idea. (I recently also wrote a few words about this in the forum: https://forum.byte-welt.net/byte-welt-projekte-projects/jocl/19229-jocl_0_2_0-windows-x86_64-dll-link-opencl-dll.html?langid=2#post132024 )

To summarize it: JOCL does not link against a particular OpenCL implementation, It only offers the OpenCL functions, which are then resolved against the OpenCL implementation at runtime (this is done with the OpenCL ICD (Installable Client Driver)).

So JOCL will/should be compiled with the «newest» OpenCL headers. For example, it must be possible to call an OpenCL 2.0 function via JOCL, even if the current OpenCL installation on the target system (or the system where JOCL is compiled) only supports OpenCL 1.2.

(That’s what I tried to accomplish by putting the matching headers into the repo, but obviously, there are some issues with that. On the one hand, because Apple needs directory names like OpenCL/cl.h instead of CL/cl.h, and on the other hand, because it has to be told to not use pre-2.0-headers that it may find in the «Frameworks» directory…)

Copy link

Contributor

Author

Tried with following ways :

Making a copy of CL directory to OpenCL : normal code starts taking the new files.
Omitting the Apple-specific lookup.

New changes are needed also for both ways :

#define CL_EXT_SUFFIX__VERSION_1_2_DEPRECATED   CL_EXTENSION_WEAK_LINK AVAILABLE_MAC_OS_X_VERSION_10_7_AND_LATER_BUT_DEPRECATED_IN_MAC_OS_X_VERSION_10_8

#define CL_EXT_PREFIX__VERSION_1_2_DEPRECATED   CL_EXTENSION_WEAK_LINK

New pull request with change 2

I did not liked 1 as changes in separate files would not be versioned controlled easily due to duplication.

Copy link

Contributor

Author

Also.. running mvn test

[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building JOCL 0.2.0-RC01-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-enforcer-plugin:1.2:enforce (enforce-maven) @ jocl ---
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ jocl ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /Users/ashishnegi/gitprojs/JOCLRoot/JOCL/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ jocl ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) @ jocl ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /Users/ashishnegi/gitprojs/JOCLRoot/JOCL/src/test/resources
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ jocl ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ jocl ---
[INFO] Surefire report directory: /Users/ashishnegi/gitprojs/JOCLRoot/JOCL/target/surefire-reports

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running org.jocl.test.JOCLBasicTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.04 sec - in org.jocl.test.JOCLBasicTest
Running org.jocl.test.JOCLMinimalPlatformTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in org.jocl.test.JOCLMinimalPlatformTest

Results :

Tests run: 2, Failures: 0, Errors: 0, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.243 s
[INFO] Finished at: 2016-04-15T18:03:46+05:30
[INFO] Final Memory: 12M/245M
[INFO] ------------------------------------------------------------------------

I see their are 3 tests.. Why only 2 runs ?

Regarding the test cases: One of them is an abstract test, intended as a base class that is no test for itself, but only contains the boilerplate code (platform setup etc.) for other tests.

According to gpu/JOCLCommon#4 , this should be resolved now. Further investigations of why it did not compile with the original headers may be worthwhile, however: Right now, one has to assume that this will be reopened after the update to OpenCL 2.1 …

Copy link

Contributor

Author

Here are the Mac builds :
JOCL-Mac-Builds.zip

It has four folders : Profiling, Release, Running, Testing.
Release should be what you would like to ship.
Others would be helpful for debugging, if need arises.

Thanks again for your contributions!

I wonder whether the current version also compiles on Linux ( @linkerlin — did you gain any new insights regarding #3 ?). If it worked, it could become version 0.2.0-RC2 …

So on the one hand, I’d like to include this in the download package and Maven. On the other hand, I’m a bit unsure about the version of the Java part that you tested them with. (It has to work with https://github.com/gpu/JOCL/releases/tag/jocl-0.2.0-RC00 ).

Obviously, now that the transition to GitHub completes, and contributions are popping up here, I’ll have to streamline the compilation of the natives, the versioning and the releases a bit. (Something like https://docs.travis-ci.com/user/deployment/releases/ might be a solution here, but I’m still investigating this…)

Copy link

Contributor

Author

Java version on my machine :

➜  admin git:(trigger-history) ✗ java -version
java version "1.8.0_73"
Java(TM) SE Runtime Environment (build 1.8.0_73-b02)
Java HotSpot(TM) 64-Bit Server VM (build 25.73-b02, mixed mode)

Travis ci would be great to have. 👍

The first part of the comment referred to the fact that the native library has to work together with the JAR file that is contained in http://jocl.org/downloads/JOCL-0.2.0-RC-bin.zip (and in the corresponding maven package).

I’ll try to read more about Travis CI, and how well it works with the mix of natives (for different platforms) and the JAR that should eventually contain the native libraries. The current build/release process has too many bottlenecks.

gpu

mentioned this issue

Apr 20, 2016

Источник

SFML community forums »
Help »
General »
Plethora of compile errors

Topic: Plethora of compile errors (Read 1296 times)

0 Members and 1 Guest are viewing this topic.

Mac OS X 10.8.2
Xcode 4.5.1 (4G1004)

I’m getting a bunch of compile errors when building an unmodified project. I’m at a loss as to what causes them, though I guess it could be compiler related. If anyone is able to assist with this I’d be most grateful.

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/type_traits
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/type_traits:214:46: Use of undeclared identifier ‘nullptr_t’; did you mean ‘nullptr’?
/Users/Jocke/Dropbox/Dev/Projects/Xcode/Dwarf/Dwarf/main.cpp:1:10: In file included from /Users/Jocke/Dropbox/Dev/Projects/Xcode/Dwarf/Dwarf/main.cpp:1:
/usr/local/include/SFML/Graphics.hpp:32:10: In file included from /usr/local/include/SFML/Graphics.hpp:32:
/usr/local/include/SFML/Window.hpp:32:10: In file included from /usr/local/include/SFML/Window.hpp:32:
/usr/local/include/SFML/System.hpp:34:10: In file included from /usr/local/include/SFML/System.hpp:34:
/usr/local/include/SFML/System/Err.hpp:32:10: In file included from /usr/local/include/SFML/System/Err.hpp:32:
/usr/local/include/boost/tr1/tr1/ostream:16:12: In file included from /usr/local/include/boost/tr1/tr1/ostream:16:
/usr/local/include/boost/tr1/detail/config_all.hpp:151:17: In file included from /usr/local/include/boost/tr1/detail/config_all.hpp:151:
/usr/local/include/boost/tr1/tr1/utility:21:20: In file included from /usr/local/include/boost/tr1/tr1/utility:21:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/utility:125:10: In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/utility:125:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/__tuple:16:10: In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/__tuple:16:
/usr/local/include/boost/tr1/tr1/type_traits:22:20: In file included from /usr/local/include/boost/tr1/tr1/type_traits:22:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/type_traits:343:42: Use of undeclared identifier ‘nullptr_t’; did you mean ‘nullptr’?
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/type_traits:350:14: Too few template arguments for class template ‘__is_function’
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/type_traits:419:46: Use of undeclared identifier ‘nullptr_t’; did you mean ‘nullptr’?
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/exception
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/exception:128:45: Field has incomplete type ‘std::exception_ptr’
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/exception:128:55: Expected ‘;’ at end of declaration list
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/memory
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/memory:1558:20: No member named ‘memcpy’ in namespace ‘std::__1’; did you mean ‘memcpy’?
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/memory:1586:20: No member named ‘memcpy’ in namespace ‘std::__1’; did you mean ‘memcpy’?
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/memory:2564:52: Expected ‘;’ at end of declaration list
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/memory:2743:52: Expected ‘;’ at end of declaration list
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/memory:2993:45: C++ requires a type specifier for all declarations
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/memory:3001:1: ‘operator==’ cannot be the name of a variable or data member
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/memory:3001:12: Use of undeclared identifier ‘nullptr_t’; did you mean ‘nullptr’?
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/memory:3001:55: Expected ‘;’ at end of declaration
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/memory:3002:1: Expected unqualified-id
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/memory:3760:26: Expected ‘;’ at end of declaration list
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/memory:3782:37: Unknown type name ‘nullptr_t’
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/memory:3783:51: Unknown type name ‘nullptr_t’
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/memory:4028:18: Qualified reference to ‘shared_ptr’ is a constructor name rather than a type wherever a constructor can be declared
Too many errors emitted, stopping now

[attachment deleted by admin]

« Last Edit: October 29, 2012, 10:38:52 pm by jlowgren »

Logged

SFML community forums »
Help »
General »
Plethora of compile errors

Источник

Решение

Другие решения

<img decoding="async" onError="javascript: wp_broken_images = window.wp_broken_images || function(){}; wp_broken_images(this);" src="https://en.sfml-dev.org/forums/Themes/ds-natural_20/images/topic/normal_post.gif" alt /> Topic: Plethora of compile errors (Read 1296 times)

Topic: Plethora of compile errors (Read 1296 times)