I have a C++ project using QMake. I'm trying to set some compiler options based on a simple test of which Linux distro is running, but the test does not pass. My qmake file contains:
OSDISTRO = $$(cat /proc/version)
contains(OSDISTRO, "Ubuntu"): {
message(Found ubuntu)
}
I tested the regex from the command line and it works!
cat /proc/version | pcregrep "Ubuntu"
Linux version 4.18.0-20-generic (buildd#lcy01-amd64-020) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #21~18.04.1-Ubuntu SMP Wed May 8 08:43:37 UTC 2019
Is there something special about the regex syntax in qmake? Any reason why this isn't working?
For the RegEx:
This works for me:
OSDISTRO = $$system(cat /proc/version)
contains(OSDISTRO, .*Ubuntu.*){
message("Found Ubuntu")
}
Note:
The match is case sensitive.
You can use .*[uU]buntu.* for example to match ubuntu and Ubuntu.
Explanation why your solution does not work:
The QMake function contains works with lists of values.
So, the execution of you solution will be like this:
1) First instruction OSDISTRO = $$(cat /proc/version):
QMake will execute $$system(cat /proc/version).
Then the result is splitted (by space as separator) to list of values. OSDISTRO will contain this list.
Assuming that the result is as yours. The result of the first instruction is like this:
OSDISTRO = "Linux" "version" "4.18.0-20-generic"....
2) Second instruction contains(OSDISTRO, "Ubuntu") : message(Found ubuntu):
QMake will search if the variable OSDISTRO contains the value Ubuntu and display the message Found ubuntu if success.
Here in your case, QMake will never find Ubuntu, cause the value which contains it is like this (Ubuntu 7.3.0-16ubuntu3) and QMake search only the value Ubuntu.
Hope it helps you.
Related
I just switched to ubuntu and I wanted to setup notepad++ for CPP.
So I used the NppExec plugin to compile within notepad++,
My script was :
npp_save
g++ "$(FULL_CURRENT_PATH)" -o "$(CURRENT_DIRECTORY)\$(NAME_PART)obj"
./"$(NAME_PART)obj"
Here the "obj" I used is to just save the file with an "obj" keyword nothing else.
The last line ./"$(NAME_PART)obj" is to run the program.
But it looks not working in ubuntu, it produces this error:
NPP_SAVE: Z:\home\username\cpp\test.cpp
g++ "Z:\home\username\cpp\test.cpp" -o "Z:\home\username\cpp\testobj"
; about to start a child process: "g++ "Z:\home\username\cpp\test.cpp" -o "Z:\home\username\cpp\testobj"
CreatProcess() failed with error code 2:
File not found.
./"testobj"
; about to start a child process: "./"testobj""
CreatProcess() failed with error code 2:
File not found.
I have investigated some of what I think is the problem, so I think is the usage of / and \ in changing the directory.
I don't know how to fix that, so I can not be sure.
Any ideas? :) I am using vim btw in the same machine and it is working perfectly.
In theory it might be possible (see below), in practice it is rather convoluted and works only for simple compiles (like single file hello world type).
I would suggest you try a linux program, e.g.
an editor like
scite (same editing engine as notepad++) or
kate
or a real IDE like
kdeveloper or
qtcreator.
The problems with Notepad++ inside wine and g++ outside wine (from the linux install ) are this:
notepad++ inside wine under linux is still a windows program
NppExec can only do, what a cmd inside wine can do.
starting g++ directly inside cmd is an error due to g++ being a linux binary and not a windows binary
that is your CreatProcess() failed with error code 2, it means: you are trying to execute a linux program inside wine.
That does not work! (At least not so easy.)
Though you can start linux program inside cmd inside wine using start /unix ...
started this way, g++ wants linux paths and NppExec through its variables will provide only windows paths (whatever wine has set up as drives like Z:\home\username\src\hello.cpp)
though you can convert wine paths to linux paths via the winepath -u command.
g++ started through 'start /unix ... ' inside a cmd inside wine has no proper terminal to report errors to you
though you can start an xterm for g++ and have g++ reports its messages to the xterm
the downside is that g++ will report errors using the linux paths in the xterm, so you cannot double click on an error message an get to the corresponding filename and line.
You get the idea: its complicated not comfortable.
What worked for me for a helloword.cpp was this NppExec script:
NPP_SAVE
npp_run cmd /c start /unix /usr/bin/xterm -e "/usr/bin/winepath -u '$(FULL_CURRENT_PATH)' | xargs g++ -o /tmp/a.out && /tmp/a.out ; echo 'Press return'; read"
The second line
uses an xterm,
let winepath convert the Z:\home\... path to /home/... and
have that send to g++ for compilation using /tmp/a.out as binary
if compile is successfull, /tmp/a.out is executed
the echo and read are for keeping the xterm open so that you can read the output.
If you really want to use Notepad++ inside wine, one option might be using Gnu Make outside of wine and have NppExec run make all or make run similar to the g++ in my script example. That would work for more complicated compiles.
I am trying to Get gdb pretty-print working in eclipse, it seems to be working for all stl elements and containers baring std::string
basically if i have a vector like:
std::vector<std::string> m_vec = {"hello" , "world"};
each element of the vector shows a string and it shows the contents like "hello" and "world".
but if i have a code like
std::string m_string = "hello world";
m_string shows up empty, even though i can do string operations on the contents. Not sure why only strings alone is causing as issue with pretty print.
Any help/pointers would be much appreciated.
Edited:
Few more details regarding the setup:
IDE: Eclipse Luna 4.4.2
Compiler: Cygwin g++ 5.4.0
Debugger: Cygwin gdb 7.10.1
phython : Cygwin phython 3.6
Update: Don't know how exactly, but windows restart solved it, can see string now in preety-print.
For adding support for gdb pretty-printing in cygwin you need the following file available:
/usr/share/gdb/auto-load/usr/bin/cygstdc++-6.dll-gdb.py
It is available in gcc-debuginfo-5.4.0-1 package in cygwin package installer.
Note: This might break once packages get updated in Cygwin repository. So you will need to again locate this file in the Cygwin package search.
Update: Check the version of python interpreter supported by gdb by running the following commands in the gdb console:
(cygwin console) $ gdb
(gdb) python
>import sys
>print(sys.version)
>end
You should see output something like this(in my case it defaults to python2.7 interpreter):
2.7.13 (default, Mar 13 2017, 20:56:15)
[GCC 5.4.0]
When trying to compile Fortran using PGI on Mac OS X Sierra, I get the error
ld: file not found: /usr/lib/crt1.o
I found a workaround for older Mac OS X versions (http://www.pgroup.com/userforum/viewtopic.php?t=4578)
sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o /usr/lib/crt1.o
However, with Sierra, System Integrity Protection prevents writing in /usr/bin. How can I solve this problem?
I tried linking into /usr/local/bin/ (which is permitted), but then, how can I make sure the compiler searches for library in that path?
Installing just the Command Line Tools for Mac OS X solved the problem. Do this in your terminal:
xcode-select --install
Installing Lazarus on MacOS X :
worked for me
http://wiki.lazarus.freepascal.org/Installing_Lazarus_on_MacOS_X#Xcode_5.0.2B_compatibility_.28Mac_OS_X_10.8_and_10.9.29
Solution for command line programs:
The correct answer for me was as explained in this link:
https://medium.com/#kviat/free-pascal-3-0-2-linking-on-macos-sierra-c40706e86fda
After some googling I realized that most libraries were removed from
/usr/lib in macOS Sierra. However this case is handled in FPC, so we
just need to set internal compiler variable MacOSXVersionMin to 10.8
(or later). There is no standard compiler option for it, but after
some search in source code I found the solution: set the environment
variable MACOSX_DEPLOYMENT_TARGET:
You should give the deployment target of MacOS:
MACOSX_DEPLOYMENT_TARGET= XX.XX #for instance 10.15
Solution for generally:
Linking the necessary file to /usr/bin/crt* . As already stated, this linking will be prohibited by MacOs beginning from 10.10. But there is still a way to accomplish this linking procedure and it solves the problem.
1) Reboot the Mac and hold down Command + R keys simultaneously after you hear the startup chime, this will boot Mac OS X into Recovery Mode
2) When the “MacOS Utilities” / “OS X Utilities” screen appears, pull down the ‘Utilities’ menu at the top of the screen instead, and choose “Terminal”
3) Type the following command into the terminal then hit return:
csrutil disable; reboot
4) When you come back, run the command sudo mount -uw /
5) Just run the linking code you want to:
sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o /usr/lib/crt1.o
sources: http://osxdaily.com/2015/10/05/disable-rootless-system-integrity-protection-mac-os-x/
https://www.reddit.com/r/MacOS/comments/caiue5/macos_catalina_readonly_file_system_with_sip/
In my case the problem was actually an error on the PGI installation side. PGI seems to be well aware that newer versions of macOS do not have the /usr/lib/crt1.o and that you can't create files there anymore. But it is possible to setup correct environment variables for the PGI compilers and then the linker should use the correct path to the crt1.o.
This configuration should be done automatically during the installation of the PGI compiler suite by running the makelocalrc command and should generate the file /opt/pgi/osx86-64/$PGIVER/bin/localrc. But in my case this step failed silently.
Reasons for failure seem to be:
license agreement for XCode not (yet) accepted, although this error should leave you with a /opt/pgi/osx86-64/$PGIVER/bin/localrc.error, containing some details
XCode version not supported, which seems to leave you with nothing. This is what I got when I ran the makelocalrc script manually:
makelocalrc -x /opt/pgi/osx86-64/19.10
Error: Unsupported XCode version 11
In my case (PGI 19.10, macOS 10.15, XCode 11.2.1) I manually patched the /opt/pgi/osx86-64/19.10/bin/makelocalrc to not error out on XCode 11:
if test $xcodever -gt 11 ; then # <-- was "-gt 10"!
echo " Error: Unsupported XCode version " $xcodever
exit -1
fi
and then re-ran the script after which compilation with PGI compilers (both pgcc and pgfortran) worked:
sudo /opt/pgi/osx86-64/2019/bin/makelocalrc -x /opt/pgi/osx86-64/19.10
Your case may vary, but you might want to check for a /opt/pgi/osx86-64/$PGIVER/bin/localrc.error or the /opt/pgi/osx86-64/$PGIVER/bin/localrc itself and try to manually (re-) generate it if it is not there or if you upgraded XCode/macOS since the installation of the PGI compilers.
All of a sudden I seem to be struggling with compiling c++ programs (specifically TDM64 5.1.0) from the command-line on Windows (specifically 10) when using wildcard based filenames. It works fine when the names are given in full. I've done this countless times before with no problem Edit: But not normally on windows... my memories of this working before must be false. What am I missing?
C:\Users\Duncan Coulter\Code>dir *.cpp
Volume in drive C has no label.
Volume Serial Number is 9EE6-DBBD
Directory of C:\Users\Duncan Coulter\Code
2016/04/04 01:35 PM 7 869 LittleMan.cpp
2016/04/04 01:35 PM 1 912 main.cpp
2 File(s) 9 781 bytes
0 Dir(s) 90 288 394 240 bytes free
C:\Users\Duncan Coulter\Code>g++ *.cpp
g++: error: *.cpp: Invalid argument
C:\Users\Duncan Coulter\Code>g++ main.cpp LittleMan.cpp
Your problem is where you write:
g++ *.cpp
g++ is a linux style program, and expects the shell to expand wildcards for it. The windows command shell doesn't do that - it expects individual programs to expand wildcards for themselves.
The easiest solution is to download cygwin - which does expand wildcards for you. Otherwise the answers to this question may be useful:
https://superuser.com/questions/460598/is-there-any-way-to-get-the-windows-cmd-shell-to-expand-wildcard-paths
I note that TDM is based on the MINGW port of GCC. I've found that different versions of this compiler do in fact treat the wildcard differently. For example, it works perfectly fine for me as of version 3.4.2, compiling in Windows 7:
However, when I upgraded to GCC v.4.9.2, this batch file and others I was using broke (specifically, the *.cpp was not recognized). This was a version of MINGW GCC which came with the Dev-C++ IDE. Because I needed this feature rather badly (specifically, test-compiling large submissions of student code with unspecified random filenames), I actually had to downgrade and revert back to the old version for just this purpose.
When using gcc version 4.3.2, I see how to generate specs using:
$ /usr/local/gcc-4.3.2/bin/gcc -v
Using built-in specs
Now changing to the same directory as libgcc:
cd /usr/local/gcc-4.3.2/lib/gcc/x86_64-unknown-linux-gnu/4.3.2
/usr/local/gcc-4.3.2/bin/gcc -dumpspecs > specs
I have a populated specs file that I can modify. However, once that is done I still see that:
$ /usr/local/gcc-4.3.2/bin/gcc -v
Using built-in specs
How do I tell gcc to use that specs file by default rather than forcing me to pass a -specs parameter every compile? I would like it to match another system I have where I get the following:
$ /usr/local/gcc-4.3.2/bin/gcc -v
Reading specs from /usr/local/gcc-4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/specs</code>
As you can see, the major difference between the two systems is that the existing setup is 32-bit and I am now trying to match that on a 64-bit system. The version of Linux is otherwise the same and I am compiling the same version of gcc. (With both systems gcc 4.3.2 is the second gcc installation, with 4.1.2 being used to compile 4.3.2)
As hinted at by the strace suggestion by Johannes Schaub - litb, it was a problem with where the compiler was looking for the file. As it turns out, the non-working installation had an environment variable set in the .bashrc that was causing the confusion.
The correct location for the specs file is indeed the same directory that libgcc is in. Just be sure you're looking there.
I used this command line:
/usr/bin/set-gcc-default-3.sh i686-pc-mingw32
but you'll probably want:
/usr/bin/set-gcc-default-4.sh i686-pc-linux-gnu
(Note the -4 instead of -3)
This is built using the "alternatives" stuff, please see
/usr/sbin/alternatives.exe --help
And also see pages such as http://linux.about.com/library/cmd/blcmdl8_alternatives.htm
You rebuild gcc with your specs file as part of the build!
A simpler solution is to create an alias:
alias gcc_Gary gcc -specs /<folder With Specs File>/newSpecsFile