I'm trying to run the ZeroMQ multithreaded C++ server example, which builds fine with
$ g++ server.cpp -lpthread -lzmq -o server -Wall
Using OS X 10.6.5, gcc version 4.2.1 (Apple Inc. build 5664), and zeromq2's lastest master branch (Dec 1st). However I'm getting a runtime error immediately after I start the server (with ./server)
terminate called after throwing an instance of 'zmq::error_t'
what(): Operation not supported by device
Is the code provided on the blog no longer current? Or or have I misconfigured? ZMQ seems to be working fine for me otherwise on this machine (simple request/reply socket patterns).
Ridiculous. "tcp://localhost:5555" will fail, but "tcp://127.0.0.1:5555" works fine.
Update 1:
/etc/hosts has an entry for localhost so I don't believe that's the problem. I've also tried using tcp://lo:5555 to no success.
Related
I have the newest (2020.3 EAP ATM) version of CLion and I currently use it to remote debug a program on an embedded target (linux-mipsel).
Everything works as expected, after a bit of configuration, using self-built cross-toolchain and gdbserver.
My only problem is hitting the "red square" to stop execution will neither kill the running program nor gdbserver itself.
This means next iteration of edit-compile-debug cycle I will have two copies of both (I can get more, if I insist) which will not work as each tries to open the same resources (e.g.: a serial port) concurrently.
I have to manually log into target and kill the offending processes.
Am I missing something, is it a known bug or what?
Small update:
gdbserver is actually killed (does not show in ps ax) but underlying program (debugee) is still there. I am unsure why I was convinced otherwise, my bad.
This is a known issue and will hopefully be fixed soon.
Here is the link to the youtrack issue: https://youtrack.jetbrains.com/issue/CPP-20346
You could try the suggested workarounds:
Add pre-deploy configuration which kills running instances of the program
Follow the instructions for the gdb configuration in the comments:
GDB Server: /bin/bash
GDB Server args: -c "gdbserver :1234 /home/pi/myapp; pkill -e myapp"
The second config did not work for me, so I added the execution of an external tool where I run in /bin/bash the command -c "pkill -e myapp || true". The true is mandatory to avoid errors if the program is not running.
I have a simple helloworld.cpp to instrument with Score-P or Vampirtrace.
Installation of the performance/ tracing tools works fine. After compiling and running:
# score-p
scorep-g++ helloworld.cpp -o hello
export SCOREP_ENABLE_TRACING=true
export SCOREP_ENABLE_PROFILING=true
# vampirtrace
vtcxx -DVTRACE helloworld.cpp -o hello
# run
./hello
The created OTF files (OTF for vampirtrace/ OTF2 for Score-P) are more or less empty (no timeline data). I'm using Vampir to visualize the data.
More details:
I'm testing on Mac OS X (g++-8) and Xubuntu (g++-7; VirtualBox).
For Mac OS X I have installed brew install gcc.
For the instrumented Score-P version I also got a warning
[Score-P] src/measurement/profiling/scorep_profile_callpath.c:206: Warning: Master thread contains no regions.
but I can't find related issues/ help.
I also installed TAU and PDT for Vampirtrace, but nothing changed. By the way manual instrumentation works for Vampirtrace:
#include "vt_user.h"
...
VT_TRACER("name");
For Vampirtrace I also tested OpenMP instrumentation and this was working, but only that (no application tracing around).
For both environments I did not install Open MPI.
It would be great, if somebody has similar issues and could help.
PS: Later, I want to instrument an application with Poco::Threads. I only read about partial support for POSIX Threads.
Update
The problem is g++. I tried the same instrumentation with Intel icc and it worked.
The missing instrumentation with g++ is also possible with icc, if you add the parameter --nocompiler like
score-p --nocompiler icc helloworld.cpp -o hello
Update
I had to install missing packages. There are logging outputs for ./configure with hints. One of the following package solved it:
apt-get install llvm libwrap0-dev libclang-dev gcc-7-plugin-dev
While searching for an HTTP client C++ based library, I have decided to use the casablanca -- so I needed to build it.
I'm running on Ubuntu 16.04.
While following the "common" build steps described here: How-to-build-for-Linux I have encountered a build error (when running the make command as the last operation of step 4).
The entire error output can be found here (now it is the last comment in the thread cpprestsdk-build-error#266).
Just to be sure my system has the needed build tools and libraries I performed the command mentioned in step 2 and this is the output:
--> Which means my system is "good to go".
So after I struggled it a little more, I have found "an alternative" way to build it:
I have downloaded the source code from here: Source Package: casablanca (2.8.0-2) [universe], and again, followed the same instructions STARTING FROM STEP 4 from the link mentioned in the question (How-to-build-for-Linux).
This time the make phase was successful !! (it is worth to mention that not all the unit tests that are recommended to be run on step 5 passed - I did not spend time trying to understand why...).
Went on and "copied-pasted" the complete sample provided at the bottom of the following link: cpprestsdk-Getting-Started-Tutorial.
Built the program with the following command (the program contained a single cpp file called main):
g++ -std=c++11 main.cpp -o myProg -lboost_system -lcrypto -lssl -lcpprest
Ran the program
./myProg
and it passed (there was output in the console saying:"Received response status code:200").
Would be glad to hear if you have encountered the same issue, or perhaps I did something wrong in my first attempt (or in any other step along the way).
I have an issue compiling amqpcpp on a centos virtual machine, But it works fine on my iMac.
when I am running make I get this error:
g++ -Wall -I/usr/local/include -L/usr/local/lib -Iinclude/ -c -o src/AMQPExchange.o
src/AMQPExchange.cpp src/AMQPExchange.cpp: In member function ‘void
AMQPExchange::sendDeclareCommand()’: src/AMQPExchange.cpp:73: error: cannot convert ‘amqp_table_t’
to ‘amqp_boolean_t’ for argument ‘7’ to ‘amqp_exchange_declare_ok_t*
amqp_exchange_declare(amqp_connection_state_t_*, amqp_channel_t,
amqp_bytes_t, amqp_bytes_t, amqp_boolean_t, amqp_boolean_t, amqp_boolean_t, amqp_boolean_t,
amqp_table_t)’
make: *** [src/AMQPExchange.o] Error 1
Github Issue Url
g++ version
g++ --version
g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11)
Unfortunately, I do not know enough of C++ or make yet to fully understand the issue. It seems that the compiler is complaining about a type cast style conversion in the code, which is confusing as it works fine on the mac.
Any ideas?
Thanks
Edit: I have downloaded the latest version of amqpcpp on both machines and re-compiled them, with the same results.
Edit 2: I realised that I installed librabbitmq-c on my mac a couple of months ago, I've just updated it to the latest version and it compains of a similar error to the centos machine, It appears that amqpcpp is not compatible with the latest changes to the librabbitmq codebase. It seems that this particular commit causes the issue:
Commit 2340b039f029f3b8101a164d3bcd547be1106906
I am going to try and update the AmqpCpp codebase to apply a fix, will post a link to pull request if it works. Otherwise, using an earlier commit when checking out the code should allow it to work.
Thanks
I finally found the cause and 2 (temporary) resolutions.
Option One.. pull the librabbitmq code before the breaking changes:
$ git clone https://github.com/alanxz/rabbitmq-c
$ cd rabbitmq-c/
$ git checkout e1746f92585d59364fc48b6305ce25d7fc86c2a4
And then compile as normal. I have tested this method and it works fine for me. Keep an eye out for future update on the AMQPCpp github page so that you know when its safe to update to the latest version.
Option Two .. Update the AMQPCPP code:
AMQPExchange.cpp:
Un-comment line 69 so that it reads:
amqp_boolean_t autodelete = (parms & AMQP_AUTODELETE) ? 1:0;
Change Line 73 so that it reads:
amqp_exchange_declare(*cnn, (amqp_channel_t) 1, exchange, exchangetype, passive, durable, autodelete, 0, args );
Then you should be able to compile without an error. BEWARE: there are more changes in the librabbitmq code than just this function, which is why I stated this is a temporary fix. The AMQPCpp project will need to be updated properly to reflect the most recent changes. This fix works for what I need it to, You may find some other functionality is broken.
I personally decided to use Option One and it's now working as expected.
Thanks
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.