error is coming while compiling cpp file with linaro toolchain - c++

I am trying to cross-compile openmcu-ru with linaro toolchain ,I am getting error in compiling conference.cxx file
It compiled correctly in ubuntu using gcc toolchain
but getting error with linaro toolchain
Following is error
conference.cxx:1503:6: error: prototype for 'void
ConferenceMember::Dial(PBoolean)' does not match any in class
'ConferenceMember' void ConferenceMember::Dial(BOOL _autoDial)
Following is code
////////////////////////////////////////////////////////////////////////////////////////////////////
#define BOOL PBoolean
BOOL autoDial ;
void ConferenceMember::Dial()
{
Dial(autoDial);
}
////////////////////////////////////////////////////////////////////////////////////////////////////
void ConferenceMember::Dial(BOOL _autoDial) // **Line no. 1503**
{
if(IsSystem())
return;
PWaitAndSignal m(dialMutex);
autoDial = _autoDial;
if((autoDial && (OpenMCU::Current().autoDialDelay < 20)) || IsOnline())
return;
MCUH323EndPoint & ep = OpenMCU::Current().GetEndpoint();
if(dialToken != "" && ep.HasConnection(dialToken))
return;
dialToken = ep.Invite(conference->GetNumber(), GetName());
}
Regards

got the solution
changing BOOL to int in line 1503

Related

libsndfile Emscripten environment

I am running just a little code using libsndfile, in the emscripten environment
#include <iostream>
#include <sndfile.h>
int main()
{
SF_INFO info;
const char * path = "~/data/somefile.wav";
SNDFILE* sf = sf_open(path,SFM_READ, &info);
if(sf == NULL)
{
std::cout<< sf_strerror(sf) << std::endl;
return 1;
}
std::cout<<info.samplerate<<std::endl;
std::cout<<"Hello world" << std::endl;
}
So ideally if I run this with normal cmake (Apple Clang compiler) everything works fine, the samplerate and hello world are printed, but when I run this with emcmake cmake (em++ compiler) and run the compiled node main.js file it says System error: no such file or directory. Who can help me with this? Who has experienced such thing?
So I figured it out.
The problem is that Emscripten has its virtual file environment. So if you want this file to be uploaded and later be seen in compiled .js file, you need to add compile flag --preload-file <FILE_PATH> , after that the file with given path will be recognized by emscripten environment.

C++ CodeBlocks upgrade to C++17 can't use std::filesystem

I need to be able to list the files in a directory, and so I'm trying to upgrade my C++ version in CodeBlocks to C++ 17 so i can use filesystem. To do this I followed the steps outlined at http://candcplusplus.com/enable-c17-in-code-blocks-mingw-gcc-for-all-version-with-pictures#:~:text=Enabling%20the%20C%2B%2B17,Create%20a%20project.
I didnt have to change much, CodeBlocks 20.03 and MinGW 8.1.0 are already installed. MinGW is already in my path from when I built wxWidgets. The Settings->Compiler...->Toolchain executables tab I didnt have to make any changes to, and appears in CodeBlocks as:
I also checked the box to use C++ 17 in compiler settings like so
I ran the test program on the website with the instructions and got "True!".
However when I change the basic test program to this, to try and use filesystem to read files in a directory, I get an error:
#include <iostream>
#include <filesystem>
using namespace std;
int main()
{
const int i=90;
if constexpr (i) //'if constexpr' is part of C++17
{
cout << "True!";
}
else
{
cout<<"False" ;
}
std::string path = "../MagicProgCPP/files/debug images/";
for (const auto & entry : filesystem::directory_iterator(path))
{
cout << entry.path() << std::endl;
}
cin.get();
return 0;
}
The program stops building, opens the file fs_path.h and stops on this line:
#ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
if (__p.is_absolute()
|| (__p.has_root_name() && __p.root_name() != root_name())) <----- ******STOPS HERE
operator=(__p);
else
{
string_type __pathname;
if (__p.has_root_directory())
__pathname = root_name().native();
else if (has_filename() || (!has_root_directory() && is_absolute()))
__pathname = _M_pathname + preferred_separator;
__pathname += __p.relative_path().native(); // XXX is this right?
_M_pathname.swap(__pathname);
_M_split_cmpts();
}
#else
// Much simpler, as any path with root-name or root-dir is absolute.
if (__p.is_absolute())
operator=(__p);
else
{
if (has_filename() || (_M_type == _Type::_Root_name))
_M_pathname += preferred_separator;
_M_pathname += __p.native();
_M_split_cmpts();
}
#endif
return *this;
}
I get this error in the build log:
C:\Program Files\CodeBlocks\MinGW\lib\gcc\x86_64-w64-mingw32\8.1.0\include\c++\bits\fs_path.h|237|error: no match for 'operator!=' (operand types are 'std::filesystem::__cxx11::path' and 'std::filesystem::__cxx11::path')|
I'm prety confident the path exists as I entered it and there's files in it. The build log message suggests maybe I'm not using C++17? But when I click build, this is the line the program uses to build:
g++.exe -Wall -fexceptions -g -Wall -std=c++17 -c E:\testc17\main.cpp -o obj\Debug\main.o
What am I doing wrong? Thanks
The bug 78870 was fixed since 2018-07.
You should add to project options -> linker settings -> link libraries the following library: stdc++fs.
I tried to compile your code with MinGW gcc 8.1.0 (via CodeBlocks) and everything works well (clearly with another path, since I don't have the same directories as you).
You could also add a check on the existence of the search directory like this:
namespace fs = std::filesystem;
std::string mypath { "../MyDir" };
if(fs::exists(mypath))
{
for(const auto & entry : fs::directory_iterator(path))
{
cout << entry.path() << std::endl;
}
}
It appears that this exact problem is a known bug in mingw 8.1. The bug report is here: https://sourceforge.net/p/mingw-w64/bugs/737/
and has the error in the same location:
operator != is declared and defined in line 550, but referenced in line 237.
The problem is triggered by operator/= in line 233:
path& operator/=(const path& __p)
{
#ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
if (__p.is_absolute()
|| (__p.has_root_name() && __p.root_name() != root_name()))
operator=(__p);
else
{
string_type __pathname;
if (__p.has_root_directory())
__pathname = root_name().native();
else if (has_filename() || (!has_root_directory() && is_absolute()))
__pathname = _M_pathname + preferred_separator;
__pathname += __p.relative_path().native(); // XXX is this right?
_M_pathname.swap(__pathname);
_M_split_cmpts();
}
The bug report said this was fixed in master meaning you need to install a version of mingw with the fix applied. I believe the best method is to upgrade mingw to a version greater than 8.1
user4581301 commented above in the main question that the following link has instructions on how to get a mingw install: How to install MinGW-w64 and MSYS2?

clang-tidy fails bugprone check

I'm experimenting with clang-tidy using the following file:
#include <stdio.h>
int main(int argc, char **argv)
{
int i=2; int j=1;
if (argc = 5) { return 2; }
while (i<argc) { j++; }
return 0;
}
I aim to detect the infinite loop with:
$ clang-tidy -checks=bugprone-infinite-loop main.c
but all that clang-tidy finds is the = instead of == thing:
Error while trying to load a compilation database:
Could not auto-detect compilation database for file "main.c"
No compilation database found in /home/oren or any parent directory
fixed-compilation-database: Error while opening fixed database: No such file or directory
json-compilation-database: Error while opening JSON database: No such file or directory
Running without flags.
1 warning generated.
/home/oren/main.c:6:11: warning: using the result of an assignment as a condition without parentheses [clang-diagnostic-parentheses]
if (argc = 5) { return 2; }
~~~~ ^ ~
( == )
/home/oren/main.c:6:11: note: place parentheses around the assignment to silence this warning
/home/oren/main.c:6:11: note: use '==' to turn this assignment into an equality comparison
You are using a feature from a yet unreleased version of LLVM (10.0.0).
On my system (windows) your file works as expected:
>clang-tidy10 -checks=bugprone-infinite-loop infloop.c --
1 warning generated.
\infloop.c:6:5: warning: this loop is infinite; none of its con
dition variables (i, argc) are updated in the loop body [bugprone-infinite-loop]
while (i<argc) { j++; }
^
The only modification I did on the file is removing the unecessary #include. I also added -- (double dash) to the command to get rid of missing compilation database errors. I am using a prebuilt binary from https://llvm.org/builds/
My best guess here is that you are using an older build of clang-tidy where this is not detected. For reference my version is 10.0.0-e20a1e486e1, you can see yours by running:
>clang-tidy --version
I'd also check if you are actually running the check(s) you are expected to run via:
$ clang-tidy -checks=bugprone-infinite-loop main.c --list-checks
P.S. The warning message you got at first was clang-diagnostic based, this has nothing to do with clang-tidy but rather with clang compilation

Linker error when compiling a program that uses spidermonkey

I've been trying to learn spidermonkey and so have written the following code, adapted from this guide and while the program compiles properly, I get the following error during linking:
/usr/bin/ld: cannot open linker script file symverscript: No such file or directory
I'm using 64-bit Ubuntu 13.10, and here is the code (seems irrelevant to the problem, but can't hurt)
#include <jsapi.h>
#include <iostream>
#include <string>
int main()
{
std::string script = "var x = 10;x*x;";
jsval rval;
JSRuntime* runtime = 0;
JSContext* context = 0;
JSObject* globalob = 0;
if((!(runtime = JS_NewRuntime(1024L*1024L, JS_NO_HELPER_THREADS)))||
(!(context = JS_NewContext(runtime, 8192)))||
(!(globalob = JS_NewObject(context, NULL, NULL, NULL))))
{
return 1;
}
if(!JS_InitStandardClasses(context, globalob))
{
return 1;
}
if(!JS_EvaluateScript(context,globalob,script.data(),script.length(),"script",1,&rval))
{
return 1;
}
std::cout << JSVAL_TO_INT(rval) << "\n";
JS_DestroyContext(context);
JS_DestroyRuntime(runtime);
JS_ShutDown();
return 0;
}
compiled with the command
g++ main.cpp -o out $(js24-config --cflags --libs | tr "\n" " ")
Try to write this command instead,
g++ main.cpp -o main -I/usr/local/include/js/ -L/usr/local/lib/ -lmozjs1.8.5
regarding the path I wrote above, you must write your own path which include the library and JSAPI.h file included in,
And the last term is spidermonkey library, you will find it in lib folder, for me it exists in /usr/local/lib

SIP Python/C++ binding fails to compile for simple example

After successfully compiling a Python/C binding with SIP I wanted to do the same thing with Python/C++. For some reason this doesn't work.
Here's the files:
fib.cpp
#include "fib.h"
int fib1(int n)
{
if (n <= 0) {
return 0;
} else if (n <= 2) {
return 1;
} else {
return fib1(n-1) + fib1(n-2);
}
}
fib.h
int fib1(int n);
fib.sip
%Module fib
%Include fib.h
I run the following command to build the intermediate files:
sip -c . fib.sip
So far everything works.
Now I want to build the .pyd file using distutils.
setup.py
from distutils.core import setup, Extension
import sipdistutils
setup(
name = 'fib',
versione = '1.0',
ext_modules=[
Extension("fib", ["fib.sip", "fib.cpp"]),
],
cmdclass = {'build_ext': sipdistutils.build_ext}
)
I run the following command:
python setup.py build
This fails with the following error:
build\temp.win32-2.7\Release\sipfibcmodule.cpp:29:29: error: 'fib1' was not declared in this scope
error: command 'gcc' failed with exit status 1
What could the problem be? Shouldn't c++ be used as a compiler instead of gcc, by the way?
Any help appreciated!
Kind regards
David
I've found a solution that is good enough: namespaces. Next time I'll read the documentation better. I should also mention that a solution with a Fibonacci class could solve the problem, but I didn't find that to be satisfying.
Below the content of the files can be found.
fib.cpp
#include "fib.h"
namespace test
{
int fib1(int n)
{
if (n <= 0) {
return 0;
} else if (n <= 2) {
return 1;
} else {
return fib1(n-1) + fib1(n-2);
}
}
}
fib.h
namespace test
{
int fib1(int n);
}
fib.sip
%Module fib
namespace test {
%TypeHeaderCode
#include "fib.h"
%End
int fib1(int n);
};
setup.py - nothing was changed
Exactly the same commands as mentioned before were used.