Loading dted data using gdal with g++ in solaris 10? - c++

I want to load Digital Terrain Elevation(DTED) data using gdal using g++ in solaris 10. In solaris 10, the application with cc compiler loads the data successfully, but when I am using netbeans and g++. the application successfully reads Digital Terrain Elevation(DTED) data but application crashes at GetGeoTranformation(double *) when I print GDALdataset->getDriver()->GetDescription(). This function is working fine in cc. If I comment the line, the application crashes at GDALDataset->GetRasterBand(1), and error prints ld.so.1 fatal reallocation error symbol_ZN11GDALDataset13GetRasterBandIOEi reference symbol not found

Would you mind posting a part of the code which uses GDAL? There could be a few issues. Off the top of my head...
GDAL GetRasterBand starts at 1 when indexing. It seems like your snippet you provided does that.
GDAL requires that you initialize the drivers with GDALAllRegister().
Most GDAL functions return NULL when they return without data. You may want to test that before passing it into another function to prevent potential seg faults.
What does cc point to? I would check the symbolic link with something like
which cc
ls -la /usr/bin/cc (Solaris is Unix, not Linux so forgive me if I am wrong).

Related

Compiling and injecting code in GDB: C++ rather than C

I am running gdb 10.1.90.20210103-git and gcc/g++ 10.2.1 20210110 on x86-64 Debian 11. My IDE is Codelite, which uses the manual rather than the machine interface to gdb, and enables me to type commands directly to gdb, and see the response (potentially copying the response to the clipboard). This when the inferior is paused after hitting a breakpoiunt, via the gdb console, which is in Codelite's Debugger > Output pane.
I was able to use the instructions at: https://sourceware.org/gdb/current/onlinedocs/gdb#Compiling-and-Injecting-Code "Compiling and injecting code in GDB" to compile simple C code and make it run in the environment of the halted inferior. For instance: compile code blah++; increments a local variable int in the inferior, which I can see via the Locals or Watch panes.
The compile file command worked fine as long as I specified the absolute path of the source file.
I was unable to see console output (to the inferior's or gdb's console) for a simple printf() statement: `printf("xxx");' because the code would not compile if there was such a line
Despite using set debug compile and set debug compile-cplus-types and checking these are set with the show versions of these, I get no error messages or acknowledgements regarding whatever I try to compile.
The blah variable is an integer, which is accessible through C code and so gcc. The ability to increment this was the only indication that my code had compiled and run.
I could not get any responses to set/show compile gcc so I am presumably compiling with gcc. I did give the command set compile gcc /usr/bin/x86_64-linux-gnu-cpp-10, but there was still no response from show compile gcc or any change in the C-only behaviour.
I could not compile the file if it contained a C++ line which incremented a data member of a class object in an vector of such objects. Nor could I compile my code if it contained C++ code such as: #include <fstream> and/or std::fstream oFile;.
The gdb documentation mentioned above is general, but does have C examples.
Is it possible to compile C++ code under gdb, injecting it into the environment of the paused inferior, with any version of gdb and gcc?
I am keen to use this C++ code injection facility, if it exists, for dumping the contents of large, complex, data structures to files and and to modify some elements of same to aid debugging.
Summary: GDB's C++ compilation and injection system does not work for me, and it is reported to be buggy or non-functional. I only tested this compile command with single lines of C code, but it worked fine for these. I was able to run my function, which writes a text dump file containing the values of a vector of class objects' data members, while the inferior was paused after a breakpoint, by including it in a source file and calling it with GDB's print or call commands, giving it the required input argument of the name of the vector to dump.
I haven't tried using GDB on its own, but at present I have no reason to believe that Codelite is interfering with my ability to communicate with GDB via Codelite's "Debugger > Output" console.
I wrote to the GDB Developer list and received what I assume is a well informed reply. I was told that in my respondent's experience "the C++ plugin isn't very functional. It seems to have some bugs and crash pretty frequently as well. Also, it seems like nobody is actively working on it." This is consistent with my experience to date.
Perhaps later versions of GDB would work better. However, there has been minimal change to the library https://github.com/gcc-mirror/gcc/commits/master/libcc1/libcp1.cc since 2017, and I could find no indication of new work on C++ compilation and injection in https://www.sourceware.org/gdb/news/ since the announcement of its introduction:
GDB 8.3.1 was released on 2019-09-20, with: "Experimental support for compilation and injection of C++ source code into the inferior (requires GCC 7.1 or higher, built with libcp1.so)."
It is possible that my problem is related to not having this library. I do have the C equivalent: /usr/lib/x86_64-linux-gnu/libcc1.so.o. I could find no such library in a Debian package. It is possible I could get this going by compiling the latest GCC/G++ and GDB, but that is pretty daunting, involving installing later standard libraries than my current Debian installation has, while making those and the newer G++ and GDB available for Codelite sessions, but not interfering with other software on machine which needs the older compilation system.
The respondent suggested that instead of compiling and injecting fresh code in the middle of a debugging session, I could write it as a library, and run it by using the compile command, on a purely C piece of code which would call it. However, for my purposes, the function needs to be passed one or more C++ constructs, and any code which called a C++ function would be C++ code and so, presumably, not be compiled by GDB.
For my immediate purpose of doing text dumps of large vectors of class objects' data members, I was able to succeed by writing such a function in an existing source file, which also contains the functions I am debugging. Then I could call it with GDB's print or call commands. I imagine this would work if the debugging function was in any other linked source file, or in a linked library. (Perhaps there is a way of writing such a library, compiling and linking it while the inferior is halted.)
I was able to run this, from a debugging session in which the inferior was halted somewhere, with either the print or call command followed by the name of the function, with the name of the vector in brackets. There must be no semicolon. I found the print command better, since GDB would report the return value, which was "void". My function used C++ constructs such as "<<" to write to the text file.
A call within my dump function of the C function system("pwd") resulted in the current directory being output on the inferior's terminal window. Likewise: print system("pwd"). print system("mc") dutifully ran Midnight Commander in the inferior's terminal window.
I altered the function to return a string, which GDB reported in the GDB "Debugger > Output" console. I added a line: std::cout << "xyz"; - but nothing appeared on either the inferior's terminal window or in the GDB console.
My attempts to use the compile command to call my dump function in exactly the same way produced no results, with or without a trailing semicolon.
I found thatprint and call work with C and C++ code while `compile" only works with C code.
I tried print vvv[6].mmm for data members which were integers, floats, and strings and GDB returned their values correctly. Adding a ++ at the end caused it to return the original integer value, but the value itself was incremented.
When I tried print with a compound line of code, with a semicolon between the two logical lines, with and without one at the end, there was no response.
The GDB Developers list is not the place for support requests, but I did not know a better way to find out about the status of this facility.

OpenCL not finding platforms?

I am trying to utilize the C++ API for OpenCL. I have installed my NVIDIA drivers and I have tested that I can run the simple vector addition program provided here. I can compile this program with following gcc call and the program runs without problem.
gcc main.c -o vectorAddition -l OpenCL -I/usr/local/cuda-6.5/include
However, I would very much prefer to use the C++ API as opposed the very verbose host files needed for C.
I downloaded the C++ bindings from Khronos from here and placed the cl.hpp file in the same location as my other cl.h file. The code uses some C++11 so I can compile the code with:
g++ main.cpp -o vectorAddition_cpp -std=c++11 -l OpenCL -I/usr/local/cuda-6.5/include
but when I try to run the program I get the error:
clGetPlatformIDs(-1001)
I also tried the example provided here as well which gave a more helpful error message.
No platforms found. Check OpenCL installation!
The particular code which provides this error is this:
std::vector<cl::Platform> all_platforms;
cl::Platform::get(&all_platforms);
if(all_platforms.size()==0){
std::cout<<" No platforms found. Check OpenCL installation!\n";
exit(1);
}
This seems so strange given that the C implementation runs without problem. Any insights would be sincerely appreciated.
EDIT
The C implementation actually isn't running correctly. Each addition is printed to equal zero. Checking the ret_num_platforms also returns 0. For some reason my setup is failing to find my GPU. What could I have missed? My install consists of the nvidia-340 driver and cuda-6.5 installed via apt-get and the .run file respectively.
My sincerest thanks to #pasternak for helping me troubleshoot this problem. To solve it however I ended up needing to avoid essentially all ubuntu apt-get calls for install and just use the cuda run file for the full installation. Here is what fixed the problem.
Purge existing nvidia and cuda implementations (sudo apt-get purge cuda* nvidia-*)
Download cuda-6.5 toolkit from the CUDA toolkit archive
Reboot computer
Switch to ttyl (Ctrl-Alt-F1)
Stop the X server (sudo stop lightdm)
Run the cuda run file (sh cuda_6.5.14_linux_64.run)
Select 'yes' and accept all defaults
Required reboot
Switch to ttyl, stop X server and run the cuda run file again and select 'yes' and default for everything (including the driver again)
Update PATH to include /usr/local/cuda-6.5/bin and LD_LIBRARY_PATH
to include /usr/local/cuda-6.5/lib64
Reboot again
Compile main.c program (gcc main.c -o vectorAddition -l OpenCL -I/usr/local/cuda-6.5/include)
Verify works with ./vectorAddition
C++ API
Download cl.hpp file from Khronos here noting that it is version 1.1
Place cl.hpp file in /usr/local/cuda-6.5/include/CL with other cl headers.
Compile main.cpp (g++ main.cpp -o vectorAddition_cpp -std=c++11 -l OpenCL -I/usr/local/cuda-6.5/include)
Verify it works (./vectorAddition_cpp)
All output from both programs show the correct output for addition between vectors.
I personally find it interesting the Ubuntu's nvidia drivers don't seem to play well with the cuda toolkits. Possibly just for the older versions but still very unexpected.
It is hard to say without running the specific code on your machine but looking at the difference between the example C code you said was working and the cl.hpp might give us a clue. In particular, notice that the C example uses the following line to simply read a single platform ID:
cl_platform_id platform_id = NULL;
cl_int ret = clGetPlatformIDs(1, &platform_id, &ret_num_platforms);
Notice that is passes 1 as its first argument. This assumes that at least one OpenCL platform exists and requests that the first one found is placed in platform_id. Additionally, note that even though the return code is assigned to "ret" is it not used to actually check if an error is returned.
Now if we look at the implementation of the static method used to queue the set of platforms in cl.hpp, i.e. cl::Platform::get:
static cl_int get(
VECTOR_CLASS<Platform>* platforms)
{
cl_uint n = 0;
cl_int err = ::clGetPlatformIDs(0, NULL, &n);
if (err != CL_SUCCESS) {
return detail::errHandler(err, __GET_PLATFORM_IDS_ERR);
}
cl_platform_id* ids = (cl_platform_id*) alloca(
n * sizeof(cl_platform_id));
err = ::clGetPlatformIDs(n, ids, NULL);
if (err != CL_SUCCESS) {
return detail::errHandler(err, __GET_PLATFORM_IDS_ERR);
}
platforms->assign(&ids[0], &ids[n]);
return CL_SUCCESS;
}
we see that it first calls
::clGetPlatformIDs(0, NULL, &n);
notice that the first parameter is 0, which tells the OpenCL runtime to return the number of platforms in "n". If this is successful it then goes on to request the actual "n" platform IDs.
So the difference here is that the C version is not checking that there is at least one platform and simply assuming that one exists, while the cl.hpp variant is and as such maybe it is this call that is failing.
The most likely reason for all this is that the ICD is not correctly installed. You can see this thread for an example of how to fix this issue:
ERROR: clGetPlatformIDs -1001 when running OpenCL code (Linux)
I hope this helps.

Segmentation fault using mongodb c++ client driver

I am getting a segmentation fault in a program that uses the C++ mongodb client driver.
Attempting to isolate the problem I found this: there is some heap object of class X.
When commenting out all the mongo code the program runs fine.
But if I add a member variable of type BSONObjBuilder to X (just declare without using it),
then after about 200K iterations where X objects are allocated and deallocated the fault occurs.
Gdb bt shows it's in the destructor of X, which is actually {}, so it only disposes of the BSONObjBuilder.
It looks like the free memory list is getting corrupted.
Having a BSONObjBuilder as a local variable on the stack works though, over millions of iterations.
I have found this related question https://groups.google.com/forum/#!topic/mongodb-user/Ngxh4IOcSPA
which suggests there is a linkage problem. So I rebuilt the mongo C++ driver as indicated, but the
problem persists. There is also this question on the matter
MongoDB C++ Segmentation Fault
with similar rebuild recommendations but for older mongo versions.
Not being an expert, I would appreciate some help in finding out exactly what library mismatch may cause this and how to reinstall/rebuild/fix it properly.
Some details:
I have ubuntu 14.04.1 LTS
dpkg -S /usr/include/boost/version.hpp shows libboost1.54-dev
mongod 2.6 running, although after commenting out I'm not even connecting to it.
downloaded the legacy mongo C++ driver git clone https://github.com/mongodb/mongo-cxx-driver.git
built scons driver and scons install, which uses g++, compiled fine, generated libmongoclient.a
my code in Eclipse also uses g++, everything compiled with -pthread (there are multiple threads)
a single additional include path to mongo-cxx-driver/build/include for the mongo driver stuff
libraries linked as follows (in order): mongoclient, pthread, boost_thread, boost_system, boost_regex
tried with pthread the last library, no help
calling mongo::client::initialize first thing in main, status returned ok
I have some BSONObj members in X, they work fine until I also add the BSONObjBuilder member
Tried calling done() or abandon() on the BSONObjBuilder in the destructor, also no help.

Unable to run Woden Physics Example in Pharo

I am trying to run the Woden Physics Example inside Pharo which involves getting Bullet properly compiled and the smalltalk bindings properly installed in Pharo.
I am using Linux Mint 17 x64.
But NativeBoost seems unable to load the compiled libraries. I have been using the sources provided here:
https://github.com/ronsaldo/bullet-pharo
https://github.com/ronsaldo/swig
I built the modified version of swig as well as the bullet libraries and bindings with the provided build scripts.
I also have doublechecked that the bullet libraries are 32 bit.
Opening up the Woden physics example returns this error:
failed to get a symbol address:
PharoNB_new_BTDefaultCollisionConfiguration__SWIG_1
When examining the call stack in the debugger, it turns out that the module handle is 0.
I verified this by executing the same message as
BulletCInterface nbLibraryNameOrHandle
executes:
NativeBoost forCurrentPlatform loadModule: 'BulletPharo'
This message returns 0. I tried to specify the full path to libPharoBullet.so in the workspace, like:
NativeBoost forCurrentPlatform loadModule:
'/home/martin/.local/share/Pharo/bullet-pharo/libBulletPharo.so'
with the same result. I also verified it with a 32 bit system library of mine (liblzma) and there NativeBoost was able to load it, as it returned a non-zero handle.
So i suspect something during compilation went wrong...
I also did
readelf -h libPharoBullet.so
and its ABI was "UNIX - GNU" while the ABI of pharo-vm is "UNIX - System V"
Could this be the problem here ?
How can i force the ABI to be System V when compiling ? I use gcc 4.8.2
Or what steps could i otherwise perform ?

Issues compiling vmware web api client code into useable objects

I'm using vmware's web application api in an attempt just to simply retrieve the fields in the "ServiceContent" object. There is an example of how this should be accomplished located at the vmware forum. The example contained there compiles fine for me however I get segfaults when running the simple example - specifically the trace goes back to the soap_serializeheader() function (I believe these are defined in stdsoap2.cpp). My problem is that I do not know how to avoid this segfault and have no idea why this is occurring (as I am following the example almost word for word). I am using OS X tool chain (gcc version 4.0.1 (Apple Inc. build 5465) ) combined with (gsoap release 2.7.16). I tried gsoap 2.8 but got the same result. Below is the procedure I used to get to where I am now.
These are the commands I used to parse the wsdl:
wsdl2h -o vim25.h vimService.wsdl
Once this is parsed, I compiled using the following command:
soapcpp2 -x -C -pvsp vim25.h -I/place/where/stlvector.h/is
this generates files vspC.cpp, vspClient.cpp, and vspVimBindingProxy.cpp. Internally these files have the same prefixes for functions (i.e. ns1/ns2 etc) so my calls are the same as those in the example.
This is the command I am using to compile vspC.cpp and vspClient.cpp:
g++ -DWITH_COOKIES -DWITH_OPENSSL -c vspC.cpp
g++ -DWITH_COOKIES -DWITH_OPENSSL -c vspClient.cpp
This is the command I use to compile stdsoap2.cpp (if I do not compile with -DWITH_NONAMESPACES I get an error about an undefined symbol "_namepspaces" when I link everything):
g++ -DWITH_COOKIES -DWITH_OPENSSL -DWITH_NONAMESPACES -c stdsoap2.cpp
I then link everything together with the test code (again this is copied almost identically from the example, just with the changes to correctly refer to the files I created):
g++ -DWITH_COOKIES -DWITH_OPENSSL vspC.o vcpClient.o stdsoap2.o testcase.cpp -lssl -lcrypto -o doesntwork
This compiles correctly, but of course fails to run. I read about an OS X user in this vmware forum post who was also having trouble. It appears the gsoap guide says you cannot use stdsoap2.cpp's header and fault serialization codes, and you must compile them separately. The user in the OS X post seems to have done this, however I am not sure how to incorporate them into my test file (he creates the empty env.h file and then compiles it with soap2cpp) - if I include the envH.h file i get about naming conflicts with vspH.h. So a second question would be how do I use soap2cpp to compile all the stubs correctly so that there are not namespace conflicts (which is what I appear to be encountering).
I will not provide the source, as it is displayed at the first vwmare forum link by user stumpr. I do not believe the issue is in the source, but in the way I have used either wsdl2h, soap2cpp, or some incorrect combination of flags during compilation with g++.
Thanks for taking a look, and hopefully some one can resolve the issue!
EDIT I think I may have solved this - by using a 64bit system (and one with more memory). I tried compiling with -m32 on the X.6 and it was not able to do it (complaining about memory issues).
Hopefully someone will stumble upon this and be happy to know the answer.