Project ERROR: Cannot run compiler 'g++'. Maybe you forgot to setup the environment whithin gitlab env - g++

I've a strange phenomenom happening that I don't know how to investigate.
I hope someone already encountered this an can provide tips
I'm using gitlab CI to build some Qt based projects.
gitlab runner calls a script named build.sh that works just fine when I run it manually as "me" in my env dev.
However runner raises an error stating "Project ERROR: Cannot run compiler 'g++'. Maybe you forgot to setup the environment".
So I made sure g++ was available (g++ -version is OK) and in g++ is in PATH but pbm is still there.
here is part of the script where the problem resides and the investigation I performed
echo ">>>>>> now generating makefiles for ${PROJECT_FILE} <<<<<<"
export QTDIR=/usr/lib64/qt5
echo $QTDIR
echo QMAKESPEC is
qmake-qt5 -query QMAKE_SPEC
echo gcc version is
gcc --version
g++ --version
echo $PWD
whoami
$cmd_qMake -v
$cmd_qMake -makefile -o qMakefile ../src/${PROJECT_FILE}
echo PATH is $PATH
echo QMAKESPEC is
qmake-qt5 -query QMAKE_SPEC
echo gcc version is
gcc --version
g++ --version
and here is the output (sorry; this is in debug mode)
>>>>>> now generating makefiles for Communication.pro <<<<<<
+ export QTDIR=/usr/lib64/qt5
+ QTDIR=/usr/lib64/qt5
+ echo /usr/lib64/qt5
/usr/lib64/qt5
+ echo QMAKESPEC is
QMAKESPEC is
+ qmake-qt5 -query QMAKE_SPEC
linux-g++
+ echo gcc version is
gcc version is
+ gcc --version
gcc (GCC) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ g++ --version
g++ (GCC) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ echo /root/builds/3188cf72/0/EGNOS_V3/AIV-P/AIV-P/Shared/Communication/.buildchain
/root/builds/3188cf72/0/EGNOS_V3/AIV-P/AIV-P/Shared/Communication/.buildchain
+ whoami
root
+ qmake-qt5 -v
QMake version 3.1
Using Qt version 5.9.2 in /usr/lib64
+ qmake-qt5 -makefile -o qMakefile ../src/Communication.pro
Project ERROR: Cannot run compiler 'g++'. Maybe you forgot to setup the environment?
+ echo PATH is /opt/gcc-7.3.0/bin:/usr/bin:/usr/sbin:/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/sbin:/usr/bin:/bin
PATH is /opt/gcc-7.3.0/bin:/usr/bin:/usr/sbin:/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/sbin:/usr/bin:/bin
+ echo QMAKESPEC is
QMAKESPEC is
+ qmake-qt5 -query QMAKE_SPEC
linux-g++
+ echo gcc version is
gcc version is
+ gcc --version
gcc (GCC) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ g++ --version
g++ (GCC) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ for target in '"${TARGETS[#]}"'
As you can see, g++ seems available un runner's root PATH
So why is qMake failing?
Thanks for your help
Zaluum

I had the same error sudo apt install build-essential worked for me.

Well, finally found it!
Turns out that the error message is not clear at all or at least subject to interpretation.
It was not an issue with gcc that could not be found. It was however a problem with my env.
Root user did not have /usr/local/lib in its LD_LIBRARY_PATH (when I had it).
The reason why is needed is unclear to me but I suspect this is something to do with libisl being necessary for GCC 7.3.0 which is my QMAKE_CC.
Hope this helps somebody
Zaluum

In most of the cases, this is a problem with environment settings - especially path to compiler/toolchain etc.
On Windows it concerns PATH environment variable's setting. For example - when you use minGW toolchain with g++ you should have PATH set e.g.
C:\Qt\Tools\mingw810_64\bin
However sometimes setting it in Windows Control Panel is insufficient, because other application (you have installed) could play with PATH and overrided it. So I recommend to everyone facing this issue and fired all found possible solution, first - to check if printing PATH in cmd (command line Windows tool) follows PATH you have set in Control Panel. If not you can try:
Find reason for PATH is different,
Check if it is not problem described here: https://stackoverflow.com/a/65163187/8389251
Add new Windows User (new account) - and run there Qt Creator and compilation. (Still ensure you have properly set PATH in Control Panel)

Related

Cannot configure CMake to look for Homebrew installed version of Bison

I'm running macOS 10.14 and I installed bison version 3.2 with brew, but it refuses to link:
$ brew link bison --force
Warning: Refusing to link macOS-provided software: bison
If you need to have bison first in your PATH run:
echo 'export PATH="/usr/local/opt/bison/bin:$PATH"' >> ~/.bash_profile
For compilers to find bison you may need to set:
export LDFLAGS="-L/usr/local/opt/bison/lib"
My CMakeLists.txt has the following lines:
find_package(BISON 3.2 REQUIRED)
...
message(STATUS "Found bison ${BISON_VERSION} at: ${BISON_EXECUTABLE}")
cmake fails with the following output:
Could NOT find BISON: Found unsuitable version "2.3", but required is at
least "3.2" (found /usr/bin/bison)
The system-installed bison is at version 2.3, and I know that the Homebrew-installed version is at version 3.2.
The FindBISON module apparently uses the find_program CMake directive, and I've tried adding /usr/local/opt/bison/bin to CMAKE_PROGRAM_PATH, but /usr/bin/bison is always selected first no matter what. How can I force CMake to favor the Homebrew installed version of the Bison executable?
Since some things in macos depend on the Apple-provided versions of flex and bison, homebrew installs them outside of the user's normal $PATH as a "keg". A manual solution is to make sure you (and your users) add the program's brew prefix to their path (can be found by running brew --prefix bison etc.).
An automatic solution is to put this logic in your CMake files. A couple open-source projects have worked around it like this. The earliest example of a fix for this that I could find is from this commit to STP (essential part copied below).
Be sure to clear your CMake cache when messing around with all this, as BISON_EXECUTABLE (etc.) is cached.
# On macOS, search Homebrew for keg-only versions of Bison and Flex. Xcode does
# not provide new enough versions for us to use.
if (CMAKE_HOST_SYSTEM_NAME MATCHES "Darwin")
execute_process(
COMMAND brew --prefix bison
RESULT_VARIABLE BREW_BISON
OUTPUT_VARIABLE BREW_BISON_PREFIX
OUTPUT_STRIP_TRAILING_WHITESPACE
)
if (BREW_BISON EQUAL 0 AND EXISTS "${BREW_BISON_PREFIX}")
message(STATUS "Found Bison keg installed by Homebrew at ${BREW_BISON_PREFIX}")
set(BISON_EXECUTABLE "${BREW_BISON_PREFIX}/bin/bison")
endif()
execute_process(
COMMAND brew --prefix flex
RESULT_VARIABLE BREW_FLEX
OUTPUT_VARIABLE BREW_FLEX_PREFIX
OUTPUT_STRIP_TRAILING_WHITESPACE
)
if (BREW_FLEX EQUAL 0 AND EXISTS "${BREW_FLEX_PREFIX}")
message(STATUS "Found Flex keg installed by Homebrew at ${BREW_FLEX_PREFIX}")
set(FLEX_EXECUTABLE "${BREW_FLEX_PREFIX}/bin/flex")
endif()
endif()
find_package(bison REQUIRED)
find_package(flex REQUIRED)

Linker only sees a portion of libraries in a directory

In my makefile I have:
g++ -o Out Out.o -I Headers_Directory -L Libraries_Directory -lFile1 -lFile2
In my Libraries_Directory I have two files libFile1.a and libFile2.so
ld finds libFile1.a but cannot find libFile2.so. How that is possible and how can I resolve the issue?
I am compiling in Cygwin and using GNU gcc-g++ compiler.
A minimalist that regenerates the error:
Download the Linux Version of Gurobi here. Then, install the software using this instruction. You need to activate the software by obtaining a license from here. Free academic license for research purpose is available. Finally navigate to the following folder
installation_directory/gurobi701/linux64/examples/build
and issue the command make. You have to compile on Cygwin with GNU gcc-g++ compiler.

cmake with git for windows, MinGW and make

Firstly, I have installed MinGW from https://sourceforge.net/projects/mingw/files/ and the mingw32-gcc-g++ and mingw32-gcc-objs with it. I have added C:\MinGW\bin to my path.
Secondly, I have installed Git for windows (not really important, the result is the same on cmd.exe).
Thirdly, I have installed the complete package "make" with http://gnuwin32.sourceforge.net/packages/make.htm
After that, I have installed cmake 3.5.1 with the .msi.
But when I run cmake ../src the result is :
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:5 (project):
No CMAKE_C_COMPILER could be found.
CMake Error at CMakeLists.txt:5 (project):
No CMAKE_CXX_COMPILER could be found.
-- Configuring incomplete, errors occurred!
See also "C:/Users/pauka/Dropbox/ETUDE/SRI/S8/STA_Stage/sources/tests/bin/CMakeFiles/CMakeOutput.log".
See also "C:/Users/pauka/Dropbox/ETUDE/SRI/S8/STA_Stage/sources/tests/bin/CMakeFiles/CMakeError.log".
So cmake can't find gcc or g++. But when I run gcc -version, the output is good... What should I configure for cmake ?
My CMakeLists.txt is :
# Ajustez en fonction de votre version de CMake
cmake_minimum_required (VERSION 2.8)
# Nom du projet
project (main)
find_package (OpenCV REQUIRED)
# Exécutable "main", compilé à partir du fichier main.cpp
add_executable (tracking_color tracking_color.cpp)
add_executable (feuille feuille.cpp)
add_executable (detect_circles detect_circles.cpp)
add_executable (segmentation segmentation.cpp)
add_executable (watershed_perso watershed_perso.cpp)
add_executable (main main.cpp utils.h)
add_executable (info_coins info_coins.cpp)
# main sera linké avec les bibliothèques d'OpenCV
target_link_libraries (tracking_color ${OpenCV_LIBS})
target_link_libraries (feuille ${OpenCV_LIBS})
target_link_libraries (detect_circles ${OpenCV_LIBS})
target_link_libraries (segmentation ${OpenCV_LIBS})
target_link_libraries (watershed_perso ${OpenCV_LIBS})
target_link_libraries (info_coins ${OpenCV_LIBS})
target_link_libraries (main ${OpenCV_LIBS})
Ok, shame on me,
I had to restart my computer and select "MinGW Makefiles" in the CMake GUI. Click Configure, and after that Generate.
Next, you must not use Git for windows because there is sh.exe and it's a cmake bug.
PS: to use OpenCV, you must compile it :
cd C:\opencv
mkdir my_build
cd my_build
cmake -G "MinGW Makefiles" ../sources
mingw32-make # took 2 hours on my computer
and next add, C:\opencv\my_build and C:\opencv\my_build\bin to the system path.
You can try setting manually the cxx path, see CMAKE_C_COMPILER from link which tells you more or less link this:
CXX=C:\path\to\g++ cmake ..
But, I would recommend you to see why cmake doesn't recognize your cxx compiler. I would double check your environment paths.
Maybe not the best answer but get things going. Install Bash On Ubuntu On Windows and install cmake and make using sudo apt-get install cmake and sudo apt-get install build-essential if you don't already have them installed. However, Bash On Ubuntu On Windows only comes with Windows 10 and for accessing a specific drive you should use /mnt/c instead of C:\
Follow this official tutorial to install Bash On Ubuntu On Windows.
mona#DESKTOP-0JQ770H:/mnt/c$ cmake -version
cmake version 2.8.12.2
mona#DESKTOP-0JQ770H:/mnt/c$ make -version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for x86_64-pc-linux-gnu
Additionally, of course you can install git in Bash On Ubuntu On Windows
sudo apt-get install git
mona#DESKTOP-0JQ770H:/mnt/c$ git --version
git version 1.9.1
though I don't suggest using a Linux-based git for pushing to github for a Windows specific SDK/code. I would still stick to Git Bash for dealing with git.
*I used to use CMAKE GUI for dealing with CMake in Windows 10 and then port my stuff to Visual Studio. That is also a neat solution depending on your codebase.

g++: unrecognized option '-static-libstdc++'

I'm trying to link DLL with the following command:
g++ -DFTCSPI_EXPORTS -shared -fpic -static-libgcc -static-libstdc++ tmp\*.o "%D2XX_Dir%\ftcspi.lib" "%TclLibFile%" -o tmp\ftcspiif.dll
I'm getting this error: g++: unrecognized option '-static-libstdc++'
I've checked I have libstdc++-6.dll in C:\MinGW\bin and my gcc version is 4.4.7.
Does anyone have any ideas what might be going on? Thanks in advance.
my gcc version is 4.4.7.
The -static-libstdc++ option was added in 2009 in this patch. The first released GCC version with this flag is 4.5.
As Employed Russian stated, the -static-libstdc++ flag was added to GCC as of version 4.5.
Based on your comment to his answer though, if you're having trouble with installing/reinstalling/upgrading MinGW, I Highly suggest checking out http://tdm-gcc.tdragon.net/ as they provide an up-to-date installer for the MinGW environment in both 32 & 64 bit flavors.
They also apply various patches to the environment but you can choose different versions of various packages to install if you have specific requirements or just want to stick with the vanilla MinGW environment.

What is the signature of the Clang compiler in the ELF?

I have several binaries compiled with gcc/g++ and others compiled with clang/clang++.
So far i have tried:
strings -a ./myBinary | grep -i clang
objdump -s --section .comment ./myBinary
readelf -p .comment ./myBinary
and each one of this command fails to recognize the binaries produced by clang, and each file produced by Clang is recognized as produced by gcc and basically all my binaries are produced by the same compiler according to this tools.
Does Clang puts the same signature as GCC ? How i can get informations about what compilers have generated that binaries ?
Thanks.
I guess it's a duplicate of stackoverflow.com/questions/43523698/clang-appears-to-use-gcc
It seems that if you link against a glibc built by GCC, the latter takes the credits.