Issues configuring scons to use posix arguments in a windows command prompt - build

First off I should forewarn you that I am a new grad(and EE at that), and not terribly familiar a build process more advanced than my hello world programs.
My issue is: We are attempting to use SCons ton build our project at work. Our compiler is called 'i686-pc-elf-gcc' and uses posix style command line arguments. But whenever I try and use scons it forces Windows arguments, so instead of:
i686-pc-elf-gcc -o hello.o -c hello.cpp
I get
i686-pc-elf-gcc /Fohello.obj /c hello.cpp /TP /nologo
Which our compiler doesn't like.
Here is what my SConscript file looks like
import os
path = ['c:\\compiler\GCC\i686\bin',
'../../build/include']
env = Environment(ENV = {'PATH' : path,'TEMP' : os.environ['TEMP']})
env.Replace(CC = "i686-pc-elf-gcc")
env['platform'] = 'posix'
env.Program('hello.cpp')
The environment is in a DOS prompt with cygwin installed. I was hoping setting the platform to posix was all that was needed, but I have been beating my head against the wall with no results.

Looks like the default SCons compiler detection is picking up the Microsoft compiler suite. Instead of:
env = Environment(ENV = {'PATH' : path,'TEMP' : os.environ['TEMP']})
maybe try:
env = Environment(tools = ['gcc', 'g++', 'gnulink'],
ENV = {'PATH' : path,'TEMP' : os.environ['TEMP']})
This way it will use the gcc toolset instead of the msvc one. If you only overwrite CC then all the flags are still MSVC style, while the compiler is really GNU. So the full SConstruct would be:
import os
path = [r'c:\compiler\GCC\i686\bin', '../../build/include']
env = Environment(tools = ['gcc', 'g++', 'gnulink'],
ENV = {'PATH' : path,'TEMP' : os.environ['TEMP']})
env.Replace(CC = "i686-pc-elf-gcc")
env.Program('hello.cpp')

Related

Qt web assembly: configure kit

I want to test out QT WebAssembly for my scientific program.
Therefore, I installed emscripten.
$em++ --version
returns
emcc (Emscripten gcc/clang-like replacement) 1.38.30 (commit a5082b232617c762cb65832429f896c838df2483)...
Then I installed Qt using the Qt WebInstaller.
In my installation directory I have a wasm_32 folder which contains bin and qmake:
$ ~/Qt_web/5.13.2/wasm_32/bin/qmake --version
return
QMake version 3.1
Using Qt version 5.13.2 in /home/myName/Qt_web/5.13.2/wasm_32/lib
However, when I start Qt creator, click on Projects I see a Kit called: Qt 5.13.2 WebAssembly but I cannot select it (it is grayed out).
When I click on manage Kits I saw that there is no C and C++ compiler selected for Qt 5.13.2.WebAssembly.
I also get an warning when I change to Qt Versions. The warning says:
ABI detection failed: Make sure to use a matching compiler when building. No qmlscene installed.
This is a list of all compilers which are selectable:
Question:
I do not really understand what emscripten has to do with all that. Is emscripten a compiler? If yes should it have been auto-selected by the Qt 5.13.2 WebAssembly kit?
How does a proper Qt WebAssembly kit look like?
If I select gcc as my compiler I get an error saying:
/home/myName/Qt_web/5.13.2/wasm_32/plugins/platforms/libqwasm.a:-1: error: error adding symbols: File format not recognized
EDIT:
When I open the qt maintenance tool and look at the installed packages I get the following:
EDIT2:
After changing to Qt Creator 4.11.0-beta2 (4.10.83) I was able to follow parts of this description. I was able to select the Plugin, but I still can not change the Device type.
Maybe it has to do with this error that I get now:
EDIT3:
seems as if my emscripten compiler has some problems.
Is the compiler located in:
emscripten/emsdk/clang/e1.38.30_64bit/clang++
emscripten/emsdk/clang/e1.38.30_64bit/clang
One thing I noticed is that If I use add in QtCreator >> Kits >> Compilers and I select Add >> WebAssembly >> C It generates a new entry in Manual >> C++ >> Emscripten Compiler and not in Manual >> C >> Emscripten Compiler. Is this a problem?
EDIT
This is how my Compilers page looks like:
You need to copy the .emscripten file from emsdk directory to your home (/home/myUsername).
You need to fix the paths in the file manually (See example below).
Notice that .emscripten file , at least in the version (1.39.8) i am using, is a python script (maybe a bug?)
example file before edit:
import os
emsdk_path = os.path.dirname(os.environ.get('EM_CONFIG')).replace('\\', '/')
NODE_JS = emsdk_path + '/node/12.18.1_64bit/bin/node'
LLVM_ROOT = emsdk_path + '/upstream/bin'
BINARYEN_ROOT = emsdk_path + '/upstream'
EMSCRIPTEN_ROOT = emsdk_path + '/upstream/emscripten'
TEMP_DIR = emsdk_path + '/tmp'
COMPILER_ENGINE = NODE_JS
JS_ENGINES = [NODE_JS]
after edit:
import os
emsdk_path = os.path.dirname(os.environ.get('EM_CONFIG')).replace('\\', '/')
NODE_JS = '/home/myUsername/node/12.18.1_64bit/bin/node'
LLVM_ROOT = '/home/myUsername/upstream/bin'
BINARYEN_ROOT = '/home/myUsername/upstream'
EMSCRIPTEN_ROOT = '/home/myUsername/upstream/emscripten'
TEMP_DIR = '/home/myUsername/tmp'
COMPILER_ENGINE = NODE_JS
JS_ENGINES = [NODE_JS]
When above steps are completed qt creator was able to detect the Emscripten Compiler with no errors.
Have you try in the kits tab to set your compiler with this values?
Compiler:
C compiler x86 64 e1.38.27_bit
C++ compiler x86 64 e1.38.27_bit
Qt version:
path to you qmake built with webassembly, for example webassembly binaries or your custom binaries.
Qt mkspec:
wasm-emscripten
Hope this information helps, if you face any other problem let me know.

Gradle Cpp-Application not detecting gcc in windows

I am starting to get into c++ more and I have began learning gradle to use as the build too for it. I am using gradle's cpp-application plugin for compiling the code. However when I try to build it gradlew tells me that it can't detect gcc, my only installed compiler.
I have for the most part followed the guide on gradle's website (https://guides.gradle.org/building-cpp-executables/). That is where I came up with most of the code so far.
I have gcc from ming-w32 installed in my path correctly (I can run it from the command prompt and through make without any issues)
I am also using a gradlew install that was made with gradle 5.2.1
I am, for the most part, using the exact setup in the gradle guide.
apply plugin : 'cpp-application'
application {
baseName = "test"
}
^ /$Project/build.gradle
This is the command line output when i run gradlew assemble
* What went wrong:
Execution failed for task ':compileDebugCpp'.
> No tool chain is available to build C++ for host operating system 'Windows 10' architecture 'x86-64':
- Tool chain 'visualCpp' (Visual Studio):
- Could not locate a Visual Studio installation, using the command line tool, Windows registry or system path.
- Tool chain 'gcc' (GNU GCC):
- Could not determine GCC metadata: failed to execute gcc.exe -m64 -dM -E -v -.
- Tool chain 'clang' (Clang):
- Could not find C++ compiler 'clang++' in system path.
When I run the command that they say failed to execute in the same command prompt (gcc.exe -m64 -dM -E -v -.)
I do get output from gcc without any errors that I can see
If you are curious on what it outputs you can find it here
I would expect that the issue isn't with my cpp code because it isn't ever recognizing the compiler but it is fairly short so I might as well.
#include <iostream>
int main(int argc, char** argv) {
std::cout << "Hello World!!" << std::endl;
return 0;
}
^ /$Project/src/main/cpp/main.cpp
By default, Gradle tries to locate a tool chain that matches your system's architecture (x86_64), but you only have a 32-bit MinGW
A workaround is to explicitly configure a 32-bit target in your Gradle script:
application {
targetMachines = [ machines.windows.x86 ]
}

SCons can't pick the compiler (MinGW) [duplicate]

This question already has answers here:
How to tell scons to use MinGW instead of MSVC
(2 answers)
Closed 7 years ago.
I have a simple SConstruct file with the following code
path = ['C:\\MinGW\\bin']
env = Environment(ENV = {'PATH' : path})
Program(target = 'myprogram', source = ['main.cpp'])
running 'scons' on cmd gives the following error message:
cl /Fomain.obj /c main.cpp /TP /nologo
'cl' is not recognized as an internal or external command,
operable program or batch file.
scons: *** [main.obj] Error 1
scons: building terminated because of errors.
It looks like SCons does not pick my compiler (MinGW). What am I doing wrong?
I'm on Windows 7 64bit.
After setting tools variable in environment you should use env.Program('...') instead of Program('...'). Below is my working SConstruct for mingw:
path = ['C:\\Dev\\MinGW\\x64-4.9.2-posix-seh-rt_v3-rev1\\mingw64\\bin']
temp = 'C:\\Temp'
env = Environment(ENV={'PATH': path, 'TEMP': temp},
tools=['mingw'])
env.Program('solver-tikhonov.cpp')
SCons is trying to build with the default Windows tools, namely cl, which is the visual studio compiler. You need to tell it to use the mingw toolset, as follows:
path = ['C:\\MinGW\\bin']
env = Environment(tools=['mingw'], ENV = {'PATH' : path})
After doing this, if it still cant find the mingw compiler, you can set it as follows:
env.Replace(CC='path/to/mingw/cc/compiler',
CXX='path/to/mingw/c++/compiler')

Choosing compiler options based on the operating system in boost-build

Currently I can build my program using boost build in different platforms by setting the toolset and parameters in the command line. For example :
Linux
b2
MacOS
b2 toolset=clang cxxflags="-stdlib=libc++" linkflags="-stdlib=libc++"
Is there a way to create a rule in the Jamroot file to decide which compiler to use based on the operating system? I am looking for something along these lines:
import os ;
if [ os.on-macos ] {
using clang : <cxxflags>"-stdlib=libc++" <linkflags>"-stdlib=libc++c ;"
}
in linux it automatically decides to use gcc but in the mac if I don't specify the clang toolset it will try (without success) to compile it with gcc.
Just for reference, here is my current jamroot (any suggestions also appreciated):
# Project requirements (note, if running on a Mac you have to build foghorn with clang with libc++)
project myproject
: requirements <cxxflags>-std=c++11 <linkflags>-std=c++11 ;
# Build binaries in src
lib boost_program_options ;
exe app
: src/main.cpp src/utils src/tools boost_program_options
;
How abou using a Jamroot? I have the following in mine. It selects between two GCC versions on Linux, depending on what's in an environmen variable, and chooses vacpp on AIX.
if [ os.name ] = LINUX
{
switch [ modules.peek : ODSHOME ]
{
case *gcc-4* : using gcc : 4.4 : g++-4.4 ;
case *gcc-3.3* : using gcc : 3.3 : g++-3.3 ;
case * : error Only gcc v4 and gcc v3.3 supported. ;
}
}
else if [ os.name ] = AIX
{
using vacpp ;
}
else
{
error Only Linux and AIX supported at present. ;
}
After a long time I have found out that there is really no way (apart from very hacky) to do this. The goal of Boost.Build is to let the toolset option for the user to define.
The user has several ways to specify the toolset:
in the command line with --toolset=gcc for example
in the user configuration by setting it in the user-config.jam for all projects compiled by the user
in the site configuration by setting it in the site-config.jam for all users
the user-config.jam can be in the user's $HOME or in the boost build path.
the site-config.jam should be in the /etc directory, but could also be in the two locations above.
In summary, setup your site-config or user-config for a pleasant experience, and write a nice README file for users trying to compile your program.
Hope this helps someone else.

cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++

I am building a C++ extension for use in Python. I am seeing this warning being generated during the compilation process - when a type:
python setup.py build_ext -i
What is causing it, and how do I fix it?
BTW, here is a copy of my setup file:
#!/usr/bin/env python
"""
setup.py file for SWIG example
"""
from distutils.core import setup, Extension
example_module = Extension('_foolib',
sources=['example_wrap.cxx',
'../wrapper++/src/Foo.cpp'
],
libraries=["foopp"]
)
setup (name = 'foolib',
version = '0.1',
author = "Me, Myself and I",
description = """Example""",
ext_modules = [example_module],
py_modules = ["example"],
)
I am using gcc 4.4.3 on Ubuntu
I can answer part of the question, why you're getting the message.
Something in your build process is invoking gcc on a C++ source file with the option -Wstrict-prototypes. For C and Objective-C, this causes the compiler to warn about old-style function declarations that don't declare the types of arguments.
For C++, this option doesn't make sense; such declarations aren't even allowed by the language (prototypes are mandatory).
(I don't know why the message mentions Ada; -Wstrict-prototypes makes even less sense for Ada than for C++. It's not a huge deal, but I've submitted this bug report, marked as RESOLVED/FIXED as of 2015-12-06.)
The solution should be to remove the -Wstrict-prototypes option from the invocation of gcc. But since you're not invoking gcc directly, it's difficult to know how to do that.
I was able to reproduce the warning using your setup.py, after manually creating a dummy example_wrap.cxx file:
% python setup.py build_ext -i
running build_ext
building '_foolib' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c example_wrap.cxx -o build/temp.linux-i686-2.7/example_wrap.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
...
So it's probably a minor bug in Python's build_ext.
But since it's only a warning, not a fatal error, I'd say you can safely ignore it. gcc warns about the meaningless option, but then it just ignores it.
EDIT:
Looking through the Python-2.7.2 sources, this section of configure.in might be the culprit:
case $GCC in
yes)
if test "$CC" != 'g++' ; then
STRICT_PROTO="-Wstrict-prototypes"
fi
(I'm assuming that's invoked when using build_ext.)
It turns on the -Wstrict-prototypes option only if the compiler is not being invoked as g++ -- but in your case it's using the gcc command to compile C++ source code. And in Lib/distutils/command/build_ext.py, build_extension() doesn't pay attention to the source file language when invoking self.compiler.compile(), only when invoking self.compiler.link_shared_object(). (Which seems odd; for compilers other than gcc, you wouldn't necessarily be able to use the same command to compile C and C++ -- and it makes more sense to use the g++ command anyway, even if you're not linking.)
UPDATE: A Python bug report was submitted: https://bugs.python.org/issue9031, and closed as a duplicate of this one: https://bugs.python.org/issue1222585, which is still open as I write this.
But as I said, it's only a warning and you can probably safely ignore it. Perhaps the Python maintainers can use the above information to fix the problem in a future release.
Removing -Wstrict-prototypes from the OPT environment variable has no effect. What works is to subclass build_ext as follows:
from distutils.command.build_ext import build_ext
from distutils.sysconfig import customize_compiler
class my_build_ext(build_ext):
def build_extensions(self):
customize_compiler(self.compiler)
try:
self.compiler.compiler_so.remove("-Wstrict-prototypes")
except (AttributeError, ValueError):
pass
build_ext.build_extensions(self)
and then use my_build_ext inside the setup function:
setup(cmdclass = {'build_ext': my_build_ext})
-Wstrict-prototypes option is read by distutils from /usr/lib/pythonX.Y/config/Makefile as part of OPT variable. It seems hackish, but you can override it by setting os.environ['OPT'] in your setup.py.
Here is a code that seems not too harmful:
import os
from distutils.sysconfig import get_config_vars
(opt,) = get_config_vars('OPT')
os.environ['OPT'] = " ".join(
flag for flag in opt.split() if flag != '-Wstrict-prototypes'
)
The following code fragment in setup.py will remove all instances of this pesky flag:
# Remove the "-Wstrict-prototypes" compiler option, which isn't valid for C++.
import distutils.sysconfig
cfg_vars = distutils.sysconfig.get_config_vars()
for key, value in cfg_vars.items():
if type(value) == str:
cfg_vars[key] = value.replace("-Wstrict-prototypes", "")
# ==================================
This is a Python 3.x solution with setuptools.
from setuptools import setup
from setuptools.command.build_ext import build_ext
# Avoid a gcc warning below:
# cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid
# for C/ObjC but not for C++
class BuildExt(build_ext):
def build_extensions(self):
if '-Wstrict-prototypes' in self.compiler.compiler_so:
self.compiler.compiler_so.remove('-Wstrict-prototypes')
super().build_extensions()
setup(
...
cmdclass={'build_ext': BuildExt},
...
)
More specifically, distutils uses the same options that python was built with, you can add options using extra_compile_args in creating the distutils.core.Extension but there does not appear to be a way to remove existing arguments in gcc or distutils.
See http://bugs.python.org/issue9031 for details, it has been closed as a duplicate of http://bugs.python.org/issue1222585, but 9031 details this aspect of the problem
For the sake of anyone arriving here after trying to install pydoop under pypy, this solution which was adopted in pydoop 1.0.0:
from distutils.sysconfig import get_config_var
_UNWANTED_OPTS = frozenset(['-Wstrict-prototypes'])
os.environ['OPT'] = ' '.join(
_ for _ in get_config_var('OPT').strip().split() if _ not in _UNWANTED_OPTS
breaks the installation under pypy because pypy sysconfig does not supply the 'OPT' variable at all, causing it to abort when it tries to apply strip() to None. Solution is just to comment out the whole block.