Premake not working with g++ on Linux? - c++

Premake Version: 4.3 (downloaded here)
When running make on Linux, I get the following error: "g++: x86_64: No such file or directory." Upon removing the $(ARCH) from CFLAGS, make works fine.
Red Hat:
System Version ("cat /etc/redhat-release"): Red Hat Enterprise Linux Server release 6.5 (Santiago)
Kernel Version ("uname -r"): 2.6.32-431.11.2.el6.x86_64
"uname -p": x86_64
"uname -m": x86_64
C++ compiler: g++
Ubuntu:
System Version ("cat /etc/issue"): Ubuntu 12.04.5 LTS
Kernel Version ("uname -r"): 3.2.0-67-generic
"uname -p": x86_64
"uname -m": x86_64
C++ compiler: g++
I've also run the same program successfully on Mac.
Mac:
System Version: OS X 10.10 (14A389)
Kernel Version: Darwin 14.0.0
"uname -p": i386
"uname -m": x86_64
C++ compiler: clang
premake4.lua
solution "Hello"
configurations { "Debug", "Release" }
configuration { "Debug" }
defines { "_DEBUG", "DEBUG" }
flags { "Symbols", "ExtraWarnings" }
configuration { "Release" }
defines { "NDEBUG" }
flags { "Optimize" }
project "hello"
kind "ConsoleApp"
language "C++"
location "."
files { "hello.cpp" }
hello.cpp is the standard hello world program.
Is there a reason for the $(ARCH)? From looking at the documentation for both clang and g++, it does not seem like providing just the architecture type without a flag is a compiler option. Am I missing something?

That $(ARCH) variable has been in the generated makefiles for quite some time, but it appears it has outlived its usefulness. I have removed it for now; if there is still a need to inject flags into the build we can find a safer name.
You can get a fixed version from the Premake 4.x BitBucket repository.

Related

Does llvm 9 support std::filesystem on versions of the mac prior to 10.15?

I have an old Mac (circa 2009) running El Capitan version 10.11.6. Apple doesn't allow further updates of its OS on my machine, but through Macports it serves as a fine development environment for non-Apple-specific software.
I'm compiling with g++ 9.2, which supports std::filesystem out of the box, and with clang 8.0, which doesn't. (Using each compiler's native standard library, in each case.) And I'm compiling with --std=c++2a.
I've noticed the llvm 9 is supposed to support std::filesystem out of the box (https://libcxx.llvm.org/docs/UsingLibcxx.html#using-filesystem), so I downloaded clang/llvm 9 through Macports. Unfortunately, I'm hitting a snag.
Minimal code to reproduce error is a simplification of the example from cppreference.com (https://en.cppreference.com/w/cpp/filesystem/path/path)
#include <filesystem>
#include <iostream>
namespace fs = std::filesystem;
int
main()
{
fs::path p1 = "/usr/lib/sendmail.cf";
std::cout << "p1 = " << p1 << '\n';
}
And here's the CmakeLists.txt
cmake_minimum_required(VERSION 3.15.5)
project(bug LANGUAGES CXX)
add_executable (bug main.cpp)
target_compile_options(bug PRIVATE "-std=c++2a")
And here's the compiler's complaints:
[build] Starting build
[proc] Executing command: /opt/local/bin/cmake --build ~/temp/build/debug/clang --config debug --target all -- -j 10
[build] [1/2 50% :: 1.598] Building CXX object CMakeFiles/bug.dir/main.cpp.o
[build] FAILED: CMakeFiles/bug.dir/main.cpp.o
[build] /opt/local/bin/clang++ -g -std=c++2a -MD -MT CMakeFiles/bug.dir/main.cpp.o -MF CMakeFiles/bug.dir/main.cpp.o.d -o CMakeFiles/bug.dir/main.cpp.o -c ../../../main.cpp
[build] ../../../main.cpp:9:8: error: 'path' is unavailable: introduced in macOS 10.15
[build] fs::path p1 = "/usr/lib/sendmail.cf";
[build] ^
[build] /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/filesystem:738:24: note: 'path' has been explicitly marked unavailable here
[build] class _LIBCPP_TYPE_VIS path {
...
Working backward, I find this bit of code in /opt/local/libexec/llvm-9.0/include/c++/v1/__config:
# define _LIBCPP_AVAILABILITY_FILESYSTEM \
__attribute__((availability(macosx,strict,introduced=10.15))) \
__attribute__((availability(ios,strict,introduced=13.0))) \
__attribute__((availability(tvos,strict,introduced=13.0))) \
__attribute__((availability(watchos,strict,introduced=6.0)))
As far as I can determine, this #define is the ultimate cause of the above error message.
So, my questions are:
Is this a bug with LLVM? After all, GCC doesn't introduce a dependency between std::filesystem and the OS version.
Is this a bug with Macports? Maybe they didn't use the correct flags when building?
If I were to build LLVM and Clang natively, can I work around this issue?
Is it an issue at all? Maybe the good folks at LLVM know something that the good folks at GCC don't.
NOTE: There's a similar question involving clang/llvm downloaded through Homebrew. Unfortunately, the commentary was not helpful. [LLVM-9 clang-9 OSX]: std::filesystem::path unrecognized
I've been looking through LLVM and encountered the following lines:
// Decide whether to use availability macros.
#if !defined(_LIBCPP_BUILDING_LIBRARY) && \
!defined(_LIBCPP_DISABLE_AVAILABILITY) && \
__has_feature(attribute_availability_with_strict) && \
__has_feature(attribute_availability_in_templates)
# ifdef __APPLE__
# define _LIBCPP_USE_AVAILABILITY_APPLE
# endif
#endif
So I passed -D_LIBCPP_DISABLE_AVAILABILITY to the compiler and it worked! I doubt that it's a valid solution, but it may help someone. Another option could be sticking to https://github.com/gulrak/filesystem which is basically std::filesystem, but outside of the standard library.
Answering some of your questions:
Is this a bug with LLVM? After all, GCC doesn't introduce a dependency between std::filesystem and the OS version.
Well, it's not a bug, but yes, it's a feature of LLVM and it seems that it's made especially for Apple.
Is this a bug with Macports? Maybe they didn't use the correct flags when building?
No, it's not a bug of Macports or Homebrew.
If I were to build LLVM and Clang natively, can I work around this issue?
As you could see this availability feature is in the sources, so it seems that it doesn't matter if you build it from sources or using a package manager.
Is it an issue at all? Maybe the good folks at LLVM know something that the good folks at GCC don't.
Unfortunately, I can't state anything here, but it should've been done for a reason.

Issue compiling a piece of open source software written in C++ on MacOS Sierra

I am trying to install a piece of open source software (AB3P) on MacOS Sierra. When I issue the command make I get this error: ld: library not found for -lops. The make command issued before the error is thrown is: g++ -g -o make_wordSet make_wordSet.o -L./Library -lops -D_POSIX_C_SOURCE=199506L -lpthread
I have the latest version of MacOS Sierra and Xcode + the Xcode command line developer tools (as of this writing). In addition gcc is installed, the command gcc --version returns:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 8.1.0 (clang-802.0.42)
Target: x86_64-apple-darwin16.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
I am not sure how to approach the problem, any suggestions?
Get into Library folder, and make it first.
cd Library
make
There it will find the libops.a
On the updated version of the Ab3P as #ridoro1 mentioned, you need to make first NCBITextLib and edit the both Makefiles under Ab3P and also under Library.
First get into Library and make it. Then make Ab3P.
You need to download this library and compile it, then edit Makefile in the folder of this library and the Makefile in the lib folder inside it to point to NCBITextLib-master folder on your disk, after that You can compile the ABP3 library.

XCode compiler error, with a project built using CMake

I'm trying to build a XCode (version 5.0) project that was generated from CMake 3.x.
clang compiler version:
Apple LLVM version 5.0 (clang-500.2.76) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
When I try to build the project
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x c++ -arch x86_64 blah blah -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk blah blah -Wno-unknown-pragmas -F/usr/local/bin/Debug ;**-std=c++0x -stdlib=libc++** -Wall -MMD -MT blah blah
I get this error:
clang: error: no such file or directory: ';-std=c++0x'
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang failed with exit code 1
How can I fix this error?
-std and -stdlib are coming from these project properties:
Apple LLVM 5.0 - Language C++ ==> Dialect and Standard library
How do I set this from CMAKE?
If I recall correctly there is no c++0x language dialect in Xcode 5, but there is a c++11 dialect.
These properties can be changed in the CMake project in two ways:
(I've never managed to do this) by setting CMAKE_XCODE_ATTRIBUTE_ and then the name of the attribute you see in the Xcode project
By setting the ''generic'' compiler property CMAKE_CXX_FLAGS variable
There is a stray semi-colon in that command line:
-F/usr/local/bin/Debug ;-std=c++0x -stdlib=libc++
^
So the shell is seeing two commands; the first starts with c++ and the second with -std=c++0x. Find and remove that semi-colon and it should start working.

How can I compile Boost 1.54.0 (1.54) for the iOS simulator (6.1) on OS X 10.8.4?

I have successfully managed to compile several of the Boost libraries and create a framework for use with OS X, iOS, and the iOS simulator using this script: https://github.com/wuhao5/boost/blob/188e905626dbd522f65950102ed0c8ce77cb28e8/boost.sh based on Peter Goodliffe's work here: http://goodliffe.blogspot.com/2010/09/building-boost-framework-for-ios-iphone.html with Boost 1.53.0 using clang and linking against libc++.
The script fails when compiling for the iOS simulator with Boost 1.54.0 with the following error:/bin/sh: line 1: -ftemplate-depth-128: command not found.
I did quite a bit of digging and here is what I know:
In boost.sh, the iOS simulator bjam and compiler options include "-arch i386"
The release notes for Boost 1.54.0 state that "Boost no longer supports the 80386 target CPU"
Boost 1.53.0 appears to compile fine for OS X, iOS, and the iOS simulator using the same script
Boost 1.54.0 appears to compile fine for OS X and iOS itself using the same script
Here is what I think I know:
When passing "-d13" to bjam (to generate debug information), it appears that the variable "CONFIG_COMMAND" is not being set when building for the iOS simulator. For the other configurations, this variable is set to the path to clang and includes the compiler options. For the simulator, it is empty which I believe leads to the error above as when bjam attempts to run the compiler using this variable, it instead runs some appended options which begin with the template depth. Therefore, the CONFIG_COMMAND variable does not appear to be being set properly causing the failure.
I have no idea why it's not being set as I don't know enough about the Boost build system to sift through the rest of the 100+MB output it generated with the "-d13" flag. I suspect an incompatibility with the "-arch i386" option was introduced with 1.54.0. I've tried changing this to "-arch i486" and "-arch x86_32" but the same problem occurs.
Has anyone else had success with this? I'd like to use Boost.Log which is why I'm even attempting this.
I got it building with the boost.sh given here by changing the line in buildBoostForiPhoneOS()
./bjam -j16 --build-dir=iphonesim-build --stagedir=iphonesim-build/stage --toolset=darwin architecture=x86 target-os=iphone macosx-version=iphonesim-${IPHONE_SDKVERSION} link=static stage
to
./bjam -j16 --build-dir=iphonesim-build --stagedir=iphonesim-build/stage --toolset=darwin-${IPHONE_SDKVERSION}~iphonesim architecture=x86 target-os=iphone macosx-version=iphonesim-${IPHONE_SDKVERSION} link=static stage
Modified boost.sh with Boost pkg download and unpacking. Just need to run and all done!
Boost 1.54
MacOSx 10.8.4
Xcode 4.6.3
I figured this out a while ago by reading through diffs of every single jam file between boost 1.53.0 and 1.54.0, which was a serious undertaking. I meant to post a patch, but just finding the cause took time I didn't have, and now I don't remember what it was.
At any rate, I DO remember the quick fix I used to move along and meet a deadline. It is, for boost 1.54.0, to supply bjam with the "toolset=darwin-[version]~iphonesim" argument. You can also give arm builds toolset=darwin-[version]~iphone, though it doesn't need it.
For example, using the iOS 6.1 SDK:
./b2 toolset=darwin-6.1~iphonesim architecture=x86 target-os=iphone macosx-version=iphonesim-6.1 link=static variant=debug define=BOOST_TEST_NO_MAIN define=BOOST_TEST_ALTERNATIVE_INIT_API linkflags="-stdlib=libc++" -j2 -d+2 -sICU_PATH=/usr/local/icu --without-python --layout=tagged --build-dir="/Users/wix/Desktop/boost_1_54_0/_build/simd_build" --stagedir="/Users/wix/Desktop/boost_1_54_0/_build/simd_stage" --debug-configuration stage
If this doesn't work for you, let me know and if I have a moment I'll get the old build dir off backup to see if there's anything else I did. The command above is from my histfile.
Also, FYI, to make the ICU check pass for arm builds targeting only v7 and v7s with ICU libs built likewise, apply the following patch to tools/build/v2/tools/darwin.jam:
460,464c460,465
< if $(instruction-set) {
< options = -arch$(_)$(instruction-set) ;
< } else {
< options = -arch arm ;
< }
---
> #if $(instruction-set) {
> # options = -arch$(_)$(instruction-set) ;
> #} else {
> # options = -arch arm ;
> #}
> options = -arch armv7 ;
Also, more generally, you may need something like the following in your ~/user-config.jam:
using clang : : : <cxxflags>"-std=c++11 -stdlib=libc++" <linkflags>"-stdlib=libc++" ;
using darwin : 6.1~iphone
: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -arch armv7 -arch armv7s -fvisibility=hidden -fvisibility-inlines-hidden -std=c++11 -stdlib=libc++ -miphoneos-version-min=5.1 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk
: <striper> <root>/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer
: <architecture>arm <target-os>iphone
;
using darwin : 6.1~iphonesim
: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -arch i386 -fvisibility=hidden -fvisibility-inlines-hidden -std=c++11 -stdlib=libc++ -miphoneos-version-min=5.1 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk
: <striper> <root>/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer
: <architecture>x86 <target-os>iphone
;
Also, for boost::context to build correctly for the simulator, I needed to add the following to libs/context/build/Jamfile.v2:
alias asm_context_sources
: asm/make_i386_sysv_macho_gas.S
asm/jump_i386_sysv_macho_gas.S
: <address-model>32
<architecture>x86
<binary-format>mach-o
<target-os>iphone
<toolset>darwin
;
Based on responses in this post and scripts created by other people I put together a bash script that builds boost framework for iOS and OSX with Xcode 5, that means for armv7, armv7s, arm64, i386 and x86_64.
Check it out here https://github.com/mgrebenets/boost-xcode5-iosx.
I know for sure it builds boost starting with 1.49.0
For those interested in keeping up to date:
You can use the BOOST 1.57.0 with ofxiOSBoost static libraries and headers:
https://github.com/danoli3/ofxiOSBoost
Releases for libc++ (c++11), libstdc++.
All build scripts are in the /scripts folder (updated Peter Goodliffe script)

"-std=gnu++0x"option for MacOS

I'm trying to compile a CMake project which uses
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} "-Wall -std=gnu++0x")
in the CMakeLists.txt file under MacOS X Lion. I have installed XCode 4.2.1. but the compiler fails with this:
cd something/src/lib && /usr/bin/c++ -Dlib_ginacra_EXPORTS -Wall -std=gnu++0x -fPIC -o CMakeFiles/lib_ginacra.dir/utilities.cpp.o -c something/src/lib/utilities.cpp
cc1plus: error: unrecognized command line option "-std=gnu++0x"
The compiler's verion is:
c++ --version
i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
GCC 4.2 is ancient, but Apple don't ship a newer version.
You can either install a modern GCC from somewhere like Mac Ports (which is probably simpler and quicker) or build it yourself following the instructions at http://gcc.gnu.org/wiki/InstallingGCC
For Lion users facing this issue:
Download and Install the MacPorts-2.2.1-10.7-Lion.pkg MacPorts
installer package from here
in a terminal, search for newer GCC versions:
$ port search --name --glob 'gcc*'
install a newer version (I went with gcc5)
$ sudo port install gcc5
get the name of your new version, and set it as default
$ port select --list gcc
Available versions for gcc:
llvm-gcc42
mp-gcc5
none (active)
$ sudo port select --set gcc mp-gcc5
open a new terminal and validate you're updated:
$ c++ --version
c++ (MacPorts gcc5 5.2.0_0) 5.2.0
Most of you getting that error "cc1plus: error: unrecognized command line option -std=gnu++0x" while installing nodejs extension which requires C++ compilation with node-gyp.
So how to solve this error so here is the solution. Basically you get these errors because of Nodejs different version as many node libraries requires C or C++ compilation while installing. So Nodejs older version uses python 2.7 with gcc compiler less than version 4.2 but Nodejs newer version uses gcc44 compiler that's why you get above error while installing any nodejs library.
So you need to degrade your nodejs and node-gyp version and specify the python version if you have multiple python versions installed on your system and then you will not get above error anymore.
Click here to see full tutorial