Hot answers tagged compiler
You can't just ./fork.c (it's not a program; it's the source for a program): this assumes that the file is a script (which it isn't) and treats it accordingly. (However, as noted in another answer, there are compilers (like Tiny C Compiler) that can execute C code without explicitly compiling it) Since it's a C program, you have to compile the program. Try ...
There isn't a universal way, but you can make an educated guess by looking for things only done by one compiler. GCC is the easiest; it writes a .comment section that contains the GCC version string (the same string you get if you run gcc --version). I don't know if there's a way to display it with readelf, but with objdump it's: objdump -s --section ...
AFAIK the only way to be completely sure of security would be to write a compiler in assembly language (or modifying the disk directly yourself). Only then can you ensure that your compiler isn't inserting a backdoor - this works because you're actually eliminating the compiler completely. From there, you may use your from-scratch compiler to bootstrap e.g. ...
That's not a program, that's the source code for a program. C is a compiled language, meaning it must be "compiled" into machine-readable instructions before you can run it. As you are using C, the "C Compiler" (cc) can do this. cc -o fork for.c # compile the code chmod +x fork # ensure it it executable ./fork # run the compiled program ...
One possible way, although it would take an exceedingly long time in practice, would be to go back to the roots. Development of GNU began in 1984, and the original version of Minix (which was used during early Linux development for bootstrapping purposes) was released in 1987. This entire answer is based on your premise that "[you] or others have the ...
How about: readelf -p .comment a.out
You can try using the strings command. It will create a lot of text output; by checking it you might guess the compiler. pubuntu@pubuntu:~$ strings -a a.out |grep -i gcc GCC: (Ubuntu 4.4.3-4ubuntu5) 4.4.3 Here I know it's compiled with gcc but you can always redirect strings output to a file and examine it. There is one very good utility called peid ...
In simple terms, you can think of make as having a (possibly large) number of steps, where each step takes a number of files as input and creates one file as output. A step might be "compile file.c to file.o" or "use ld to link main.o and file.o into program". If you interrupt make with CtrlC, then the currently executing step will be terminated which will ...
If you need a trusted compiler, you could get a look at academic work, like the compcert project. It's a compiler built by the INRIA (a French IT public laboratory) designed to be ''certified'', i.e. to produce an executable semantically perfectly equivalent to the code (and of course, it has been mathematically proven).
You would treat the ports clang as an alternative compiler, just like when GCC was the default. As per the FreeBSD wiki, add the following lines to /etc/make.conf (if you want to use clang for everything, even ports), or /etc/src.conf (if you want to use clang just for world and kernel): CC=/path/to/clang CXX=/path/to/clang++ CPP=/path/to/clang-cpp Check ...
Ctrl+C causes a SIGINT to be sent to the process running. This signal can be caught by the process. In the make source code you can find a trap for this signal in commands.c: /* If we got a signal that means the user wanted to kill make, remove pending targets. */ if (sig == SIGTERM || sig == SIGINT ... remove childrens ... /* Delete any ...
Sure, of course, since you can develop portable software that runs on both MacOS and Linux. Be sure to test it on Linux at regular intervals to make sure you haven't unintentionally added something unportable. If you want to use Linux-specific features then you will have more of a hard time. Depending on what it is you do, the program may compile on MacOS ...
On Debian, there are apt-cross and dpkg-cross from Emdebian, which let you set up cross-compilation for many architectures (you get cross-compilers and libraries). On Ubuntu, there's a crosschain for ARM, and a project to improve on this. You can also create toolchain using crosstool-ng which is not link to a distribution.
You can also use this clever script that counts the numbers of various CPU instructions used by the binary. It is based on parsing objdump output. Beware that it can take quite a long time to finish if you use it on a big binary.
sudo update-alternatives --config cc sudo update-alternatives --config c++ Choose gcc 4.8 version in both cases.
There are two methods . Both will give the same result objdump -s --section .comment path/to/binary Using readelf command, readelf -S binary will display the 40 section headers in the binary . Note the serial number of .comment section header. In my system , it showed as 27 (may be different for your case) readelf -x 30 path/to/binary -> which ...
readelf or objdump both can do this. ELF file compiled by gcc will add .note.ABI-tag and .note.gnu.build-id two sections. both could displayed by objdump -sj .note.ABI-tag ELFFILE objdump -sj .note.gnu-build-id ELFFILE option "s" means display full contents, "j" for indicate section name. This style get hex contents of that sections. readelf -n will ...
While manually creating your own compiler as a starting point would be the most secure, another option is to install a system from a 5 (or 10) year old install CD that you trust was created before these exploits existed. Then use that as a foundation to compile the new audited source from.
First, PIC is a compiler issue and not Linux distro issue. PIC should be allowed to set as a compiler flag instead of hardcoding globally. Not all machine architectures support PIC. If your builds are static (non-shared), you do not need PIC, and it can be inefficient. Some architectures/compilers might have a different equivalent flag, for example, IBM xl ...
The package you're backporting is assuming GCC 4.9+ by adding -fstack-protector-strong to the command line. Your version of GCC (4.7.2) does not support this flag. I'm not sure how configure is being called in this case, but the fix is to remove this flag from the script that calls it. (I assume you didn't actually type that huge command at the top of your ...
Shell scripts are very similar to the commands you'd type interactively in the shell. In this case, the -o option is telling g++ where to put the binary. So you just tell it you want it in the binary directory: g++ lesson01.cpp -o Binary/lesson01 You can run that interactively (by typing it into the shell), or you can put that in a shell script—both will ...
Of course nobody will leave any source code on embedded system, because this is unnecessary. Embedded systems like yours usually have little space even to store their firmware. You see that it contains glibc. It's seen by presence of shared objects in /lib version-named -2.8.so. You need glibc compatible toolchain which contains glibc 2.8 or earlier to ...
The files you say are missing, is because only Debian provides them, transmission sources doesn't have any init script to start. So as you noticed checkinstall can't figure this out. The best course of action is copying the debian/ directory of upstream and compiling using debuild -us -uc instead.
When something stops make (be it ctrl-C, shutdown, or even a command that fails), the work already done stays. When restated, make does as always: it figures out what still needs to be done (because a file changed or make never got to have it processed doesn't matter) and goes on with the job. The above description clearly presumes the relevant Makefiles ...
The possible solution would be to update Code::Blocks to the latest version. In Code::Blocks 13.12 clang is listed as one of the supported compilers.
You should first try one available from K-team. If that does not work, your distro may have an ARM cross-compiler package available; since the debian wiki makes mention of the PXA270, these presumably work. I notice looking around people using this chip and gcc with -march=armv5te and/or -mabi=iwmmxt; iwmmxt is also available as a -mcpu and -march, but a ...
How can I install C++ compiler for eclipse on Fedora 20? yum install gcc-c++
Since Apple has bundled it's own version of gcc/llvm, you need to enable homebrew/versions repo before you can install different version of GCC. brew tap homebrew/versions brew install gcc48 Replace gcc48 with the version of gcc you want. See also https://github.com/mxcl/homebrew/wiki/Custom-GCC-and-cross-compilers
Never do this, use a remote repository instead, i.e git. But if you insist, here's two working solution, Use scp protocol within VIM, i.e gvim scp://email@example.com//var/www/html/tips/add_tip.php Mount remote directory through SSH protocol, i.e sshfs, that way you can edit it locally, and you open another shell to execute make.
You can try various free Unix shell providers. SDF, Blinkenshell or Anapnea come to mind. They do offer build tools, and vim.
Only top voted, non community-wiki answers of a minimum length are eligible