Does the onvif have any problem with gsoap 2.8.43 version?
we have two different vendors onvif camera (one is Cohu and one is Axis) that we need to test it under Oracle Linux 7.1
If I use gsoap 2.8.17r wsdl2h with devicemgmt.wsdl and use GetSystemDateAndTime, I can get response with both camera.
But with gsoap 2.8.43 with same code I cannot compile it.
It keep complain that
main.cpp:26:98: error: no matching function for call to ‘DeviceBindingProxy::GetSystemDateAndTime(_tds__GetSystemDateAndTime*&, _tds__GetSystemDateAndTimeResponse*&)’
result = proxy.GetSystemDateAndTime(tds__GetSystemDateAndTime, tds__GetSystemDateAndTimeResponse);
Any idea what I do wrong?
many thanks in advance
Is the GetSystemDateAndTime function signature different when using wsdl2h 2.8.43? That might be the problem.
If so, then simply use the 2.8.17r version to generate the .h file and use the 2.8.43 version to generate all the rest with soapcpp2. You can use an older .h file generated with wsdl2h with a newer gSOAP version of soapcpp2 and libraries.
Related
I'm using ffmpeg lib.
I try #include "libavutil/internal.h" but received error 'libavutil/internal.h' file not found.
What should I have to do?
FFmpeg is a C application (mainly). But still support some object orientation features like information hiding (Encapsulation).
You should stick with the exposed interface (API - libav). There is a good reason for this. The header and its functions as the name suggest is "internal". Not safe to use (may change, etc..).
Have you installed ffmpeg?
First, ffmpeg is a software, not a library. It contains several libraries such as libavutil.
Then, once ffmpeg is installed, look if it's in your library path.
I suppose you're trying to compile with gcc/g++, so, you can also try to add -I[dir_where_libavutil_is]
Of course, you need libavutil-dev installed in your system.
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.
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.
My project is using ACE library, and need link another library libsdk.so, it's using another version ACE library.
The link order like : ...-lMyAce -lsdk -lAnotherAce
When application running, libsdk.so called method in MyAce(I checked the core dump), and the application crash.
If I change link order to: ...-lsdk -lAnotherAce -lMyAce
My code called method in AnotherAce, it's also crash.
If I only link my ACE, it's crash. There are some link error if only link AnotherAce.
Let the libsdk.so call its ACE library, and my code call my ACE library.
How can I resolve the problem?
The Solaris linker has an option that may help, though really redesigning your application to not need two sets of libraries with the same names in the same program
is going to be the best solution.
Direct Bindings record in each library or program which library it found a symbol in, so if libsdk.so is built with -B direct -lAnotherAce, it will record each of its references go to AnotherAce, not MyAce. You'd then link your code with -B direct -lsdk -lMyAce (do not include -lAnotherAce, as the libsdk dependencies take care of that), and your code would record that it's calls to to MyAce.