I'm trying to create an application using the NDK. I'm using ndk-build because I'm also using some external libraries which don't yet support CMake. This is the relevant line in Android.mk:
LOCAL_LDLIBS := -lEGL -lGLESv3
Everything builds (compiles and links) just fine, but when I try to use a function from OpenGL ES 3.0+ (like glGenVertexArrays), I get a segmentation fault.
When I look into the debugger, though, I see this:
So, it is linking against libGLESv1_CM.so for reasons I don't understand.
Also, on my header files, I have #include <GLES3/gl3.h> and my device supports OpenGL ES 3.2 (I also saw the libGLESv3.so file on /system/lib/).
What could I be missing?
The external library I was using included the source gl3stub.c, presumably for supporting older OpenGL ES specifications. This was nullifying the pointers to newer APIs. Removing this source and recompiling the external library solved the issue.
Related
I installed SOIL on my Mac (BigSur) in the normal way with make and make install. When I do cmake . to my OpenGL Project, everything is ok and SOIL is found. But when i do make, i get following warning/error: ld: warning: ignoring file /usr/local/lib/libSOIL.a, building for macOS-x86_64 but attempting to link with file built for macOS-x86_64.
I tried everything i found on the internet. I also included -m64 in the Makefile.
Does somebody know to solve this issue?
libSOIL uses the Carbon API (see here). The Carbon API has been deprecated with Montain Lion and removed with Catalina. I have removed libSOIL from a project for this reason, it is unlikely you can get it to work without rewriting some of its code.
A possible replacement would be libSDL along with SDL_image. These libs are much more heavy-weight, but can be used while still doing raw OpenGL rendering and ignoring the SDL rendering API.
You can use SOIL2 replace libSOIL, see SOIL2 for more.
We're developing an SDK for our technology for iOS, the sdk is delivered in a static framework. Our code uses openCV and we link OpenCV into the delivered framework binary.
This normally works well but we're having an issue with a client which is indirectly using a different version of openCV in another framework.
This is causing a conflict and the clients app crashes.
Beside switching to the same version of openCV, removing our openCV dependency or switching to a dynamic library (which allows to hide open CV inside), is there an another option to fix this?
I tried to compile our lib using "Perform Single-Object Prelink and add the openCV libs in "Prelink libraries" but this produced link error when I tried to integrate it and it looks as if it ignored "Prelink libraries", maybe I'm doing something wrong here.
Any thoughts or ideas on the matter would be much appreciated.
I'm having trouble linking an Xcode project using the AAF SDK, with Xcode 5.1.1 on MacOS 10.9.5. When I link the main dynamic library, these symbols come up missing:
_StgCreateDocfile
_StgCreateDocfileOnILockBytes
_StgOpenStorage
_StgOpenStorageOnILockBytes
AssertProc
I can't find a definition for them anywhere in the entire source tree for the SDK. The first four appear to be part of Structured Storage on Windows. A Structured Storage library is provided in the SDK and I'm already linking that.
Can anyone tell me of a Mac system library that defines these? Or is there a linker argument that pulls in a library for them? Thanks for any help.
A late answer (!), but in case anyone comes across this... The solution is either:
To use the makefiles with the AAF SDK to generate the AAF dylib,
which works fine. or...
If you use Xcode to build the AAF SDK, ensure the correct
#defines are kept, namely:
_DEBUG OM_DEBUG OM_STACK_TRACE_ON_ASSERT OM_USE_SCHEMASOFT_SS OM_STRUCTURED_STORAGE
Note that DEBUG=1 is absent (it is added by default by Xcode) - if defined, this brings in AssertProc. Define NDEBUG on release builds and omit the debug defines.
The Stg... functions are part of the MS implementation of Structured storage as you stated, but should not be referenced on a Mac, the Schemasoft implementation being used.
I am trying install OpenGL on VS2010.
I use this tutorial.
And I get the following error:
Unable to start program 'C:\Users\s151310\Tutorial 0.3.8\frameworkD.lib'.
The specified file is an unrecognized or unsupported binary format
How can I fix this?
Actually don't have to install anything at all to start OpenGL development with Visual Studio. As long as you limit yourself to OpenGL-1.1 and core Win32 APIs everything is already in place for you.
However to get modern OpenGL features one must use the so called extension mechanism to load pointers to functions of newer versions – a tedious and uninteresting process. Hence extension loader wrappers have been developed.
Also creating a window and setting up a matching OpenGL context is laborous as well. So you want to use some framework for that two.
Extension loader wrappers and frameworks are 3rd party libraries that need to be installed separately.
Unable to start program 'C:\Users\s151310\Tutorial 0.3.8\frameworkD.lib
Why are you trying to execute a library file? This is the framework library that's supposed to be linked into your executables. So this raises the question: How did you setup your project, specifically which build options did you configure. Without that I can't give better advice.
I have a C++11 project that uses Google Test, and it builds great in Linux. On a Mac, I am having more difficulty integrating it into my code base. The issue seems to be that while my code uses C++11, the Google code uses TR1. As a result, TR data structures like enum and unordered_set are included differently.
The Google Test samples build and run perfectly as provided. The samples also build just fine if I use clang++ instead of g++. (My code works only on clang++, so I use that to build.) Finally, Google's code also builds and runs if I use -std=c++11.
However, Google test does not build using clang++ on my mac if I use -stdlib=libc++. It reports that it cannot find tr1/tuple, which, of course, is true. This is a problem, because my code does not build if I use -stdlib=libstdc++ (or no stdlib argument).
Of course, I could switch all of my code over to the older standard. This, however, is extremely yuck. Is there a way to make these code bases live happily side-by-side on the Mac?
My code builds happily with Google test using g++ 4.6.3 on an Ubuntu 12.04 computer. The mac is running OSX 10.8.3. It's running g++ 4.2.1 and clang 4.2++.
Thanks for any help,
David
PS: I am somewhat new to C++, so forgive me if this is a foolish question.
Edit: Changed "OS/X" to "OSX." (Yes, I am that old.)
You can instruct Google test to use its own implementation of tr1::tuple
In cmake I use the following line to compile with "old" compilers:
add_definitions(-DGTEST_HAS_TR1_TUPLE=0)
I'm sure you can add it to your build system, it's a simple preprocessor definition.
You can look at include/gtest/internal/gtest-port.h for more options. GTEST_USE_OWN_TR1_TUPLE may be useful. Most of the parameters are correct with default values.