I'm trying to compile the silicon webserver hello world example on FreeBSD 10.2 RELEASE using clang++38. The framework uses c++14. I have installed libmicrohttpd.
When I try to compile the program using
clang++38 -O2 -Wall -std=c++14 -I/usr/local/include -L/usr/local/lib -lmicrohttpd -o sws01 sws01.cpp
I get the error
In file included from sws01.cpp:2:
/usr/local/include/silicon/backends/mhd.hh:158:22: error: use of undeclared identifier 'MHD_http_unescape'
value.resize(MHD_http_unescape(&value[0]));
The sws01.cpp:
#include <silicon/api.hh>
#include <silicon/backends/mhd.hh>
#include "symbols.hpp"
using namespace sl;
using namespace s;
auto hello_api = http_api(
GET / _hello = [](){ return D(_message = "Hello from Silicon Webserver!"); }
);
int main() {
sl::mhd_json_serve(hello_api, 9876);
}
I tried to apply this SO thread answer but -Wl and specifying /usr/local/lib/libmicrohttpd.a like
clang++38 -O2 -Wall -std=c++14 -I/usr/local/include /usr/local/lib/libmicrohttpd.a -o sws01 sws01.cpp
did not work either.
Works on os x using xcode 7.3.
Turns out the libmicrohttpd-server that ships with the FreeBSD ports-system is ver. 0.9.37 and libmicrohttpd.so does not have MHD_http_unescape() but libmicrohttpd.a does. The newest is currently 0.9.48. Replacing the ports-version with this solves my compilation issue.
Related
I would like to experiment with newer C++ features from (at least) C++20 and I'm new to C++ development on macOS in particular.
How do I enable importing of library headers in the 'module way'?
import <iostream>;
using namespace std;
int main(int argc, const char * argv[]) {
cout << "Hello, World!\n";
return 0;
}
The build errors are
Use of undeclared identifier 'iostream'
Use of undeclared identifier 'std'
I was looking at this answer and tried installing llvm and I suppose that I could run the provided commands from the terminal, but I have not tried. Is there a way to make Xcode issue the commands provided in that answer (see below)? Where would I enter them in XCode? And what do they do? I'd like to avoid thinking about terminal commands and just have something that works.
/opt/homebrew/opt/llvm/bin/clang++ -std=c++20 -c -Xclang -emit-module-interface mathlib.cpp -o mathlib.pcm
/opt/homebrew/opt/llvm/bin/clang++ -std=c++20 -fmodules -c -fprebuilt-module-path=. main.cpp -o main.o
/opt/homebrew/opt/llvm/bin/clang++ -std=c++2a -fmodules -o main main.o *.pcm
I saw that when making a new C++ project, Xcode defaults to the Apple Clang compiler and GNU++20 [-std=gnu++20] C++ Language dialect. There is also another option C++20 [-std=c++20] (what's the difference?) which I also tried, resulting in the same errors.
FYI, when I do clang -v I get
Apple clang version 14.0.0 (clang-1400.0.29.102)
Target: arm64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
And a general question about other build systems such as CMake, which I discovered during my research for C++ compilation on mac. After making a CMake project, is it possible to use the regular IDE tools such as code suggestions and debugging?
i try to learn c++20 concepts my compiler version is "Clang 13" i try to compile very simple code block but i got errors following.
"error: no type named 'floating_point' in namespace 'std'"
"error: no type named 'integral' in namespace 'std'"
i try gcc 11.2 version also but i got same error.
my build commands is following;
clang++ -Wall -Wextra -std=c++20 -g -Iinclude -Llib src/main.cpp -o bin/main
clang++ -Wall -Wextra -std=c++2a -g -Iinclude -Llib src/main.cpp -o bin/main
Code
#include <iostream>
#include <concepts>
#include <vector>
auto addUnconstrained = [](auto fir, auto sec){ return fir + sec; };
std::floating_point auto addConstrained(std::integral auto fir,
std::floating_point auto sec){
return fir + sec;
}
int main() {
std::cout << "Hello Easy C++ project!" << std::endl;
std::cout << addUnconstrained(2000, 11.5); // 2011.5
std::cout << addConstrained(2000, 11.5); // 2011.5
}
i will be very appreciate if anyone help me.
thanks
output of compiling with "-v" following link. gist.github.com/RamazanDemirci/c43db2743792a5afa5b297456c03a423
Apple clang version 13.0.0 (clang-1300.0.29.30)
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
You were using the Apple Clang. Its implementation for concepts is not completed.
after brew install llvm command i got following output "Warning: llvm 13.0.1_1 is already installed and up-to-date."
If you have installed llvm-13 from Homebrew, run brew info llvm to find where it is installed. For my case, the command outputs
If you need to have llvm first in your PATH, run:
echo 'export PATH="/opt/homebrew/opt/llvm/bin:$PATH"' >> ~/.zshrc
Then I can use /opt/homebrew/opt/llvm/bin/clang++. I also prepended the path into $PATH so that I can use clang++ directly to run it instead of Apple Clang.
Run with --version to check if it is regular/upstream Clang(the one from homebrew) or Apple Clang.
❯ /opt/homebrew/opt/llvm/bin/clang++ --version
Homebrew clang version 13.0.1
Target: arm64-apple-darwin21.4.0
Thread model: posix
InstalledDir: /opt/homebrew/opt/llvm/bin
I'm trying to recompile a huge legacy app with g++ 4.8 in order debug a glibc detected memory corruption problem (using AddressSanitizer). Previously we used g++ 4.4.7.
However, compilation fails with:
/opt/rh/devtoolset-2/root/usr/include/c++/4.8.2/bits/exception_ptr.h:40:4: error: #error This platform does not support exception propagation.
while compiling a custom exception handler (I guess). The custom exception handler uses exception_ptr in only one place:
void reportOtherException(void) const
{
std::exception_ptr p = std::current_exception();
std::string s = (p != 0 ? p.__cxa_exception_type()->name() : "null");
printf("DvMain Bad Exception: '%s'\n", s.c_str());
mErrorReporter(0, DvLog::WARNING, 0, Dv::NO_PROFILE, 0, DvLog::UNHANDLED_OTHER_EXCEPTION);
}
And reportOtherException() is used like this:
try
{
// Catch and log uncaught exceptions, then exit.
catch (const std::bad_exception& e) { exHandler.reportBadException(e); }
catch (const std::exception& e) { exHandler.reportStandardException(e); }
catch (...) { exHandler.reportOtherException(); }
}
I'm pretty new to C++ and don't know what the error even means. Worked with 4.4.7 and doesn't work with 4.8.
Any pointers on what needs to be changed to compile on 4.8?
EDIT I
Here's some additional info:
g++ --version
g++ (GCC) 4.8.2 20140120 (Red Hat 4.8.2-15)
Minimum Code
DvComDefaultExceptionHandler_test.h
#include "DvCommon.h"
#include "evt/DvEvt.h"
#include "log/DvLog.h"
#include "com/DvComErrorReporter.h"
#include <new>
#include <exception>
#include <sys/time.h>
#include <sys/resource.h>
#include <stdlib.h>
#include <unistd.h>
#include <malloc.h>
#include <bits/exception_ptr.h>
class DvComDefaultExceptionHandler
{
public:
DvComDefaultExceptionHandler(const DvComErrorReporter& er) {}
~DvComDefaultExceptionHandler() { }
void reportOtherException(void) const
{
std::exception_ptr p = std::current_exception();
}
private:
static const DvComDefaultExceptionHandler* mpInstance;
};
DvComDefaultExceptionHandler_test.cpp
#include "DvCommon.h"
#include "com/DvComDefaultExceptionHandler_test.h"
// Pointer to the single instance of the DvComDefaultExceptionHandler class.
const DvComDefaultExceptionHandler*
DvComDefaultExceptionHandler::mpInstance = 0;
Compile command and output
g++ -c -g -O0 -DDEBUG -Wall -Wextra -Wno-sign-compare -Wcast-align
--ftemplate-depth-32 -march=native -ggdb -fPIC -Iinclude -I../../include
-I../../src -I/usr/include/libxml2 -D_GNU_SOURCE
-I/mnt/swdevel/DVMon/source_build/ext/ACE -D__ACE_INLINE__
-I/usr/local/include -I/usr/lib/qt-3.3/include
-o DvComDefaultExceptionHandler.o DvComDefaultExceptionHandler_test.cpp
In file included from ../../include/com/DvComDefaultExceptionHandler_test.h:76:0,
from DvComDefaultExceptionHandler_test.cpp:13:
/opt/rh/devtoolset-2/root/usr/include/c++/4.8.2/bits/exception_ptr.h:40:4: error: #error This platform does not support exception propagation.
# error This platform does not support exception propagation.
EDIT II
Tracing through the include files comes down to the value of __GCC_ATOMIC_INT_LOCK_FREE. Running this simple program prints '2' as the value for __GCC_ATOMIC_INT_LOCK_FREE.
int
main(int argc, char **argv)
{
printf("__GCC_ATOMIC_INT_LOCK_FREE = %d\n", __GCC_ATOMIC_INT_LOCK_FREE);
}
G++ VERSION:
$ g++ --version
g++ (GCC) 4.8.2 20140120 (Red Hat 4.8.2-15)
EDIT II
I've tried it with g++ 6.3.1, running on a Centos 7 VM. Still the same problem.
Source File - one line only
#include <bits/exception_ptr.h>
Compile command: g++ -c -o test.o test.cpp
First of all, including <bits/exception_ptr.h> directly is technically unsupported. It says so right in the header file. This worked in GCC 4.4 by more or less by accident. The C++11 migration of this header file broke it because for namespace reasons, C++98 code cannot use the ATOMIC_INT_LOCK_FREE macro, and the header does not work anymore.
In GCC 7, this was fixed (again accidentally) as part of this bug:
std::future broken on armel
The trick to include <bits/exception_ptr.h> directly should work again in this version.
This means that your options are:
Compile your code in C++11 or later mode (C++14 with GCC 6 recommended).
Upgrade to DTS 7 with GCC 7 if and when it becomes available, which has the upstream fix which re-enables the C++98 hack.
Wrap the use of std::exception_ptr in an opaque type, compile its implementation in C++11 or later mode, and keep the rest of the system in C++98 mode.
Use another hack, perhaps like this one:
#include <exception>
#ifndef ATOMIC_INT_LOCK_FREE
# define ATOMIC_INT_LOCK_FREE __GCC_ATOMIC_INT_LOCK_FREE
#endif
#include <bits/exception_ptr.h>
Again, this is completely unsupported, but it should not be any worse than what you have today (with GCC 4.4).
I was able to reproduce your issue using dockerized Centos6, with gcc 4.8.2. After upgrading dev tools to version 6 (gcc 6.3.1), your code compiled without any problem. Try upgrading dev tools using these steps (suggested for testing only):
add sclo centos6 repository via adding file /etc/yum.repos.d/devtools-sclo.repo :
[testing-devtools]
name=devtools multiple for CentOS
baseurl=http://mirror.centos.org/centos/6/sclo/x86_64/rh/
gpgcheck=0
install devtoolset-6 packages:
yum install devtoolset-6-binutils devtoolset-6-gcc-c++
set bash environment to new version:
scl enable devtoolset-6 bash
Now try recompiling your base example and full source.
NOTE: This same repository contains packages for devtoolset-3 and devtoolset-4 also. Very easy to try if ever needed.
#include <iostream>
using namespace std;
int main(){
std::cout << "Hello World\n";
return 0;
}
command 1 (works)
clang hello.cc -o hello -lc++
command 2 (don't works)
/path/to/custom/clang hello.cc -o hello -lc++
main.cc:2:10: fatal error: 'iostream' file not found
#include <iostream>
^
1 error generated.
Why I can't compile with command 2 ?
It looks like you're trying to compile C++ with a C compiler. Try running clang++ instead.
clang++ hello.cc -o hello
Without running clang as a C++ compiler it won't have the C++ standard library headers available for you to include. Using clang++ the C++ standard library headers are available and the C++ standard library is linked for you automatically.
That is a known Ubuntu issue. Their clang just isn't set up right. I complained about it here -- and this remained unfixed for years.
But the good news is that it now works with the most recent 16.10 release.
Edit: Based on your updated question I would say that "custom clang" does not know about its include files.
My code:
#include <iostream>
#include <string>
int main()
{
std::string test = "45";
int myint = std::stoi(test);
std::cout << myint << '\n';
}
Gives me the compile error:
error: 'stoi' is not a member of 'std'
int myint = std::stoi(test);
^
However, according to here, this code should compile fine. I am using the line set(CMAKE_CXX_FLAGS "-std=c++11 -O3") in my CMakeLists.txt file.
Why is it not compiling?
Update: I am using gcc, and running gcc --version prints out:
gcc (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010
In libstdc++, the definitions of stoi, stol, etc., as well as the to_string functions, are guarded by the condition
#if ((__cplusplus >= 201103L) && defined(_GLIBCXX_USE_C99) \
&& !defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF))
I have had this fail on one platform before (namely Termux on Android), resulting in to_string not being available even with g++ 6.1 and the C++14 standard. In that case, I just did
#define _GLIBCXX_USE_C99 1
before including anything, and voilà, suddenly the functions existed. (You should put this first, or even on the command line, rather than just before including <string>, because another header may include <string> first, and then its include guards will keep it from ever seeing your macro.)
I did not investigate why this macro wasn't set in the first place. Obviously this is a cause for concern if you want your code to actually work (in my case I didn't particularly, but FWIW there were no problems.)
You should check if _GLIBCXX_USE_C99 is not defined, or if _GLIBCXX_HAVE_BROKEN_VSWPRINTF is defined (which may be the case on MinGW?)
std::stoi is a C++11 function. You have to use the -std=c++11 to enable it in both g++ and clang++. This is the actual issue, not a linking error or a specific preprocessor define.
$ cat test.cxx
#include <iostream>
#include <string>
int main()
{
std::string test = "45";
int myint = std::stoi(test);
std::cout << myint << '\n';
}
$ g++ -otest test.cxx
test.cxx: In Funktion »int main()«:
test.cxx:7:17: Fehler: »stoi« ist kein Element von »std«
int myint = std::stoi(test);
^
$ g++ -otest test.cxx -std=c++11
$ ./test
45
$
edit: I just saw that you used c++11. Are you sure that's making it into your compile options? Check the generated makefile and watch the executed commands to be certain.
Your version seems up to date, so there shouldn't be an issue. I think it may be related to gcc. Try g++ instead.(Most likely automatically linking issue. If you just run gcc on a C++ file, it will not 'just work' like g++ does. That's because it won't automatically link to the C++ std library, etc.). My second advise is try std::atoi.
# I have fixed the issue. std::stoi uses libstdc++. It is about The GNU Standard C++ Library. In gcc you have to link adding -lstdc++. However, in g++, libstdc++ is linked automatically.
using gcc and using g++
Pay attention how it is compiled
using g++: g++ -std=c++11 -O3 -Wall -pedantic main.cpp && ./a.out
using gcc: gcc -std=c++11 -O3 -Wall -pedantic -lstdc++ main.cpp && ./a.out
I think you should set flag like set(CMAKE_EXE_LINKER_FLAGS "-libgcc -lstdc++") (Not tested)
#include <cstdlib>
int myInt = std::atoi(test.c_str());
If you are using Cmake to compile, add line:
"add_definitions(-std=c++11)"
after find_package command.
Use 'set(CMAKE_CXX_STANDARD 11)' for Cmake