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
Related
I wanted to start writing c++ code again and I just realized that the homebrew version of gcc does not compile any c++, c, or even fortran programs.
For example, I tried to compile the following simple hello_world.cpp program:
#include<iostream>
int main()
{
std::cout << "Hello World!" << std::endl;
return 0;
}
using
g++-9 hello_world.cpp
The output I get is:
FATAL:/usr/local/Cellar/cctools/855/bin/../libexec/as/x86_64/as: I don't understand 'm' flag!
I tried installing gcc#8, gcc#7, and compile but I still get the same message.
Moreover, the same error message is shown when I try to compile a hello_world.c program using gcc-9 and a hello_world.f90 program using gfortran-9.
The programs *.c and *.cpp compile fine with the clang and clang++ compilers respectively. I also learned that as is an assembler, and that gcc can output a *.s file using the flag gcc -S but I still don't understand the error message.
I think I exhausted my c++ knowledge and internet search before posting so thank you in advance!
I ended up reinstalling all packages using
brew list | xargs brew reinstall
This fixed the problem!
For anyone else who has stumbled across this problem, you do not need to reinstall all of your brew packages. The troublemaker is cctools, which is no longer in the brew formulae list. If for some reason it is still hanging around on your system, you can either
mv /usr/local/Cellar/cctools{,-backup}
to make sure it is no longer seen by the gcc tool suite installed through homebrew, or you can outright remove it
brew uninstall cctools
I opted for the first, at the moment, because I am not sure what, if anything, removal would break. Once I have confirmed that there are no ill effects caused by not having this installed, I will remove it altogether from my system. That being said, I have confirmed that simply moving the directory takes care of the
FATAL:/usr/local/Cellar/cctools/855/bin/../libexec/as/x86_64/as: I don't understand 'm' flag!
error being reported when you try and compile something with the GNU compiler on Mac OSX (in my case Catalina, but should be the same for Big Sur and Monterrey).
Since I installed gcc-49 on my Mac I can't get Homebrew to find the C++ compiler anymore. It always fails with error messages like:
configure: error: C++ preprocessor "/lib/cpp" fails sanity check
Running "brew upgrade -v" spits out this:
...
==> ENV
HOMEBREW_CC: llvm-gcc
HOMEBREW_CXX: llvm-g++
...
I have no idea why Homebrew wants to use these compilers. Why can't it use the normal CC/CXX environment variables like everything else?
I already found, that by editing the formula directly like described in Using Homebrew with alternate GCC, I can change the HOMEBREW_CXX to use /usr/local/bin/g++ for example, which makes compiling formulas that need C++ work again.
But I don't want to edit every single formula by hand for the rest of my days. How can I change this HOMEBREW_CXX environment variable permanently? I tried setting them in my .bash_profile and running "export HOMEBREW_CXX=..." in the console and neither of those work, only editing the formula directly.
Does anyone have an idea?
A poor man's solution, to be sure, but this works: put an alias in your .bashrc or .bash_profile:
alias brew='HOMEBREW_CC=gcc-4.8 HOMEBREW_CXX=g++-4.8 brew'
Now, whenever you use brew it will use the compilers you want. Check that it works by doing:
brew --env
HOMEBREW_CC: gcc-4.8
HOMEBREW_CXX: g++-4.8
...
HTH
I am having trouble compiling Fortran code with references to DISLIN. I have downloaded DISLIN from the website, unzipped the file and ran the setup. I have added an environment variable called DISLIN (C:\dislin) and added C:\dislin\win to the PATH section of my system variables.
I am trying to compile some example code of the DISLIN website which includes line
USE DISLIN
I am using a MinGW shell to compile with command gfortran -o progrname -ldislin EX11_1.f90 and am getting the following error:
Fatal Error: Cant open module file 'dislin.mod' for reading at (1): No such file or directory.
I have tried changing the variable path and even moving the dislin.mod file (which is there) but still get the same message.
Ok I fixed this problem so thought I come back and post what worked for me incase any one else needs it...
Install both DISLIN and MinGW on the c drive
Copy disgf.a from /c/dislin and dislin.f90 from /c/dislin/gf into the directory containing your fortran files
(for me this is /c/MinGW/pnote)
Using the MinGW shell navigate to you files: cd /c/MinGW/pnote
compile dislin.f90 and your fortran program: gfortran -c dislin.f90 progName.f90 (dislin.f90 obviously only needs to be done once)
link libraries etc and compile: gfortran progName.o disgf.a -luser32 -lgdi32 -lopengl32 -o exeName
'run' exeName
You probably need to specify the path to the DISLIN module files:
gfortran EX11_1.f90 -o progrname -ldislin -I/path/to/DISLIN/modules
and, if not already configured like described here, also the path to the library itself:
gfortran EX11_1.f90 -o progrname -ldislin -I/path/to/DISLIN/modules \
-L/path/to/DISLIN/library
They provide a batch file (windows) to do the compiling and linking for you.
f90link -c My_Program
This is located in c:\dislin\Win
Also, if you are having trouble with the dislin.mod file which resides in c:\dislin\gf then recompile that with the -c compile option. I found all of this info in c:\dislin\readme.inf
near as I can tell (Jan 2018) dislin (64 bit) fails miserably with gfortran 7.2, period; and probably with many other newer compilers.
When trying to link, gfortran 7 says 'dislin.mod' is an unrecognizable format.
I think this program is highly dependent on exactly correct version synchronization - something that renders such software useless imho after many years in research.
and no, the correctness of various 'paths' seems not to help.
after all, gnuplot works, "at all". Not sure why I spent so much time on brand x.
jrc
I have just downloaded clang 3.3 (homebrew) from the LLVM web page to my mac (OS X 10.8.4), but get this compiler error when using std=c++11 stdlib=libc++:
In file included from /usr/include/c++/v1/string:434:
In file included from /usr/include/c++/v1/algorithm:594:
In file included from /usr/include/c++/v1/memory:590:
In file included from /usr/include/c++/v1/typeinfo:61:
/usr/include/c++/v1/exception:146:5: error: an attribute list cannot appear here
_LIBCPP_NORETURN friend void rethrow_exception(exception_ptr);
^~~~~~~~~~~~~~~~
/usr/include/c++/v1/__config:190:28: note: expanded from macro '_LIBCPP_NORETURN'
# define _LIBCPP_NORETURN [[noreturn]]
^~~~~~~~~~~~
It seems that I also need another libc++ (even though it was said that it was 100% complete on MAC ...), but I cannot find any. Any help appreciated. Just for your info:
> clang++ -v
clang version 3.3 (tags/RELEASE_33/final)
Target: x86_64-apple-darwin12.4.0
Thread model: posix
And, yes, I googled it and found this: http://comments.gmane.org/gmane.comp.compilers.llvm.bugs/24138 claiming it's resolved in libc++ trunk ???
Okay, as suggested by Howard, I've downloaded tip-of-the-trunk libc++ into /opt/local/share/libcxx, but have trouble building it. The manual says to cd libcxx/lib, export TRIPLE=-apple-, and run ./buildit. I presume this implies bash (I'm usually a tcsh user, so I moved my .tcshrc, got a new shell and started bash). I did that and the compilations worked, but the library build failed. Apparently ./buildit doesn't see $TRIPLE=-apple-, as it picks the wrong LDSHARED_FLAG (not that on line 81, but that on line 103, which is to be used if $TRIPLE is not set), even though echo $TRIPLE yields -apple- as it should. When I add the statement echo TRIPLE = $TRIPLE at the top of buildit, it reports nothing. How come? What is wrong here?
The failure was that because the wrong LDSHARED_FLAG was picked the loading didn't work (ld complaint about the unknown option -soname which, I think, makes sense under linux). I don't know why buildit (a #! /bin/sh file) didn't pick up the TRIPLE environment variable (it did pick up several unwanted ones such as CXX and CC). I now simply added TRIPLE=-apple- at the top of that file and it did built the library. However, the loader spitted out several warnings all of which were of the form
ld: warning: direct access in ___cxa_bad_typeid to global weak symbol typeinfo for std::bad_typeid means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
But most importantly, it works (the compilation at least, I have yet to test the library). I have one final question. The advice was to use -I and -L to tell the compiler about the whereabouts of this version. Is it not possible to put it into the usual place /usr/include/c++/v1/? Note that Xcode has its version somewhere else anyway and I had put in a symbolic link (/usr/include/c++/v1/) to that one to get my homebrew clang 3.2 working (after the some Xcode update). What about the library? Can I also put it in a standard place?
Here is the home page of libc++:
http://libcxx.llvm.org
You can download the tip-of-trunk libc++ from there. You can tell clang to point to your download with -nostdinc++ -I<path-to-libc++>/include. You can also tell clang to link to your tip-of-trunk libc++ with -L<path-to-libc++>/lib and export DYLD_LIBRARY_PATH=<path-to-libcxx>/lib. The directions are all on the libc++ home page.
Xcode is the easiest way to get clang + libc++. But if you want the very latest, this is the place to go.
Congratulations!
Don't worry about the ld warning. It is a harmless ld bug that will be fixed in a future release. I see it on 10.8.4 too and it doesn't hurt anything.
The libc++ headers no longer live at /usr/include/c++/v1. Xcode has migrated them into itself. Having libc++ headers at /usr/include/c++/v1 from older installs has been a source of confusion and bugs. I regularly use -nostdinc++ -I to point to the libc++ headers I want (I often have several versions going at the same time), and that works well for me.
It is possible for you to replace your /usr/lib/libc++.1.dylib with that you have built. I do not recommend doing this. I have to sometimes to do a proper test, but I always do so very carefully because sometimes this causes me to have to reboot onto a backup disk and restore my /usr/lib to its original state. If you do go this route, it is a very good idea to have a backup of the original /usr/lib/libc++.1.dylib very handy.
I recommend instead -L on the command line, and export DYLD_LIBRARY_PATH=<path-to-libcxx>/lib in the shell. More than one person (including myself) has gotten their computer into a really nasty place by not following this advice.
If you run testit (under test/), all you need is DYLD_LIBRARY_PATH in that shell. The testit script is set up to point to the right places without an install.
Also I recommend figuring out why you had to modify buildit. No one else is seeing that behavior. printenv on your command line may help in this endeavor.
libc++ is updated often. We try to keep tip-of-trunk always in a shippable state.
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.