What is a command line compiler?
Nowadays, you tend to have environments in which you develop code. In other words, you get an IDE (integrated development environment) which is comprised of an editor, compiler, linker, debugger and many other wonderous tools (code analysis, refactoring and so forth).
You never have to type in a command at all, preferring instead a key sequence like CTRLF5 which will build your entire project for you.
Not so in earlier days. We had to memorize all sorts of arcane commands to get our source code transformed into executables. Such beautiful constructs as:
cc -I/usr/include -c -o prog.o prog.c
cc -I/usr/include -c -o obj1.o obj1.c
as -o start.o start.s
ld -o prog -L/lib:/usr/lib prog.o obj1.o start.o -lm -lnet
Simple, no?
It was actually a great leap forward when we started using makefiles since we could hide all those arcane commands in a complex file and simply execute make from the command line. It would go away and perform all those commands for us, and only on files that needed it.
Of course, there's still a need for command-line compilers in today's world. The ability to run things like Eclipse in "headless" mode (no GUI) allow you to compile all your stuff in a batch way, without having to interact with the GUI itself.
In addition, both Borland (or whatever they're calling themselves this week) and Microsoft also provide command-line compilers for no cost (Microsoft also have their Express editions for free as well).
And gcc is also a command-line compiler. It does its one job very well and leaves it up to other applications to add a front end, if people need that sort of thing.
Don't get me wrong. I think the whole IDE thing is a wonderful idea for a quick code/debug cycle but I find that, once my applications have reached a certain level of maturity, I tend to prefer them in a form where I can edit the code with vim and just run make to produce the end product.
A command-line compiler is one that you run from the command line.
You type in gcc filename.c to compile a file (or something like that). Almost all compilers have a command-line version, and many have GUIs where you never see the command line, but the command line is still there. – Bill K Oct 5 at 16:27
(Bill K provided a nice answer in the comments... copied here and lightly edited by Mark Harrison, set to community wiki so as not to get rep.)
Related
what have to i install for compiling of file.c that use gtk2 e file glade(makes with glade 3.8)?
i have install libglade with Pacman -S and i tried to compile with
gcc -export-dynamic File.c -o browser $(pkg-config --cflags --libs gtk+-2.0)\ $( pkg-config --cflags --libs libglade-2.0)
after this MinGW doesn't work.. for each comand it put in output things like :
1367211018 [main] bash 9420 fork: child -1 - forked process 8876 died unexpected ly, retry 0, exit code 0xC0000005, errno 11
bash: fork: retry: No child processes
1368436447 [main] bash 9420 fork: child -1 - forked process 3968 died unexpected ly, retry 0, exit code 0xC0000005, errno 11
bash: fork: retry: No child processes
1370680659 [main] bash 9420 fork: child -1 - forked process 1404 died unexpected ly, retry 0, exit code 0xC0000005, errno 11
bash: fork: retry: No child processes
bash: fork: No child processes
How can i resolve this and compile project with gtk(C),file.glade?
Have you some guide?
This is not exactly an answer, since I can't figure out exactly what your problem from the information provided. So, I need more space compared to that permitted by the "comment" box above (.. if SO moderators are upset by this, let me know, and I'll take down my submission).
First, what do you mean when you say "MinGW"? Do you mean:
1) you have built a proper MinGW environment and compiled all your code from scratch (e.g. following the excellent instructions such as these (http://ingar.satgnu.net/devenv/mingw32/index.html) )
2) You have download some Windows binaries for Glade etc?
3) You are using MSys2?
If you are using Msys2, I would be surprised for your Glade to be Gtk+ (2), as AlexPu (the head honcho at MSys2) has told me personally that he will not create a Gtk+ (2) variant of Glade, since he feels that would cause too much conflict with the Gtk3 variant. This means, on Msys2, the only way to have a (MinGW) Gtk+ (2) compliant Glade is to use the MSys2/AlexPu "create from scratch mystery mechanism". We have not ever been able to get that to build, not even with MSys2's help (and that process throws a lot of bash errors).
Therefore, one possibility is that you are using a Gtk3 Glade variant with Gtk2 code, which will never work, but that can't be the only "issue", see below.
Also, your reference to libs looks a bit different from what we would expect if you had proper MinGW Gtk+ machinery. For example, all of our Win/Gtk+ (2) apps, usually, would have to have at least the following libs required:
$(#gtk)\bin\libgtk-win32-2.0-0.dll
$(#gtk)\bin\libgdk-win32-2.0-0.dll
$(#gtk)\bin\libgobject-2.0-0.dll
$(#gtk)\bin\libglib-2.0-0.dll
... and usually many more for Pango, Cairo, etc.
These should be the same whether your compiled from scratch, or if just "installed via MSys2/pacman".
Of course, almost surely, there will be other dependencies, and "search paths" required, and various things must be on your "Path".
Second, your error messages are quite odd, and cite "bash" issues. That sounds more like "scripting/instruction" problems within whatever MinGW/Unix-like shell/system you are working in.
They don't sound like "proper Gtk crashes". Typically, Windows, will actually issue a SIGSEGV and also in the debugger log it will actually use the words "segmentation fault" etc. If the SIGSEGV is really nasty, Windows may not "say anything" explicitly (blank console, etc), and your GDB might see only "some mention" of "some" problem.
Also, if you are using Glade, then it is just an xml file that attempts to make your Gtk life easier. Gtk has code for interpreting the Glade xml files into otherwise virtual "Gtk code". Frankly, we have found that Glade is more trouble than its worth in many cases, and just writing the GUI via code is more efficient, again, often, not always.
Third, it is possible (we have done it) to use Glade based on Windows binaries, and link to libs therein, but that would be for the Glade libs, you would still need to obtain the (correct) Gtk+ libs.
As you can see, it is difficult to provide a precise answer without knowing more about your set up.
I would strongly recommend also that you do not run from the command line. It can be done, but there is much too much in the way of fiddly things that need to be "connected" to have Gtk/Glade/GCC etc all talking to each other correctly. I would strongly recommend installing Code::Blocks (http://www.codeblocks.org/); it's free and excellent (or some decent IDE). Then, you can very easily set up your paths/dependencies (after you have confirmed the existence of the dll's/lib's, and their exact path, versions, tc.).
Also, the CodeBlock's community has considerable experience integrating external packages (like Glade/GCC/Gtk etc).
Some, not all, MinGW dll's will include version numbers, right click the dll, click properties and look for, depending on your OS, "version" or "details" etc where the dll's version number is kept. All the Gtk ones will. Often, the file name also incorporates version number "indicator", but sometimes it's best to be sure.
BTW, if your Glade has a ver num > 3.8.5, then almost surely it's Gtk3.
Incidentally, had you coded everything "correctly" and supplied all the libs, etc etc. but some of the libs were Gtk2 while others were Gtk3 (and there are no other major problems), then Gtk itself would disallow it, and tell you it wont accept "mixed 2 and 3".
... as before, our experience with MSys2 has been an unhappy one. We have found that investing about a day or so and following "Ingar's instructions" (http://ingar.satgnu.net/devenv/mingw32/index.html) will provide you a built from scratch fully functioning Windows MinGW infrastructure with GCC/Gtk etc, and that you have complete control over, and know where everything is, and what everything does etc.
I have installed the latest version of Eclipse on my Windows 7 64-bit machine and the mingw compiler. In setting up a Hello World project, all goes well until I am asked for the Cross Settings what the Prefix is and the Path. The Path is obvious, it's the path to the compiler. However, I haven't the slightest idea what the Prefix is and Googling for much of the day hasn't enlightened me other than finding that a lot of other people have asked the question. Unfortunately the answers I've found appear to be for specific hardware. All I want to do is to produce an executable that will run on a Windows 32 bit or 64 bit machine.
So, what is the Prefix and how do I find what it should be?
What is probably happening here is that CDT is not locating your MingW or GCC installations.
simple - but unlikely reason - covering bases
There can be many reasons, from the simple - but unlikely at this point:
You don't have mingw installed
You don't have GCC installed
This can be tested easily by starting a shell and running gcc --version.
CDT heuristic not working
To more complicated reasons relating to your installation not being detected because the heuristic in CDT did not work on your machine. To find the correct settings, CDT will do:
Check $MINGW_HOME/bin for existence
Check <Eclipse install location>/mingw/bin for existence
Look for mingw32-gcc.exe or x86_64-w64-mingw32-gcc.exe on the PATH
Check C:\MinGW for existence
If CDT cannot find any of the above, you may lead to the situation you are in.
So, how to fix it!
Option 1
Start Eclipse from within a mingw set up shell. i.e. the one you can successfully run gcc --version from. That way Eclipse will inherit an environment that can launch GCC successfully.
Option 2
Set your environment up so that MINGW_HOME is properly defined. You can do this at the system level or within the build settings in Eclipse CDT. For example, on my machine in the build settings for the project (Right-click on the project, choose Properties, then choose C/C++ -> Environment) I have set:
MINGW_HOME to C:\MinGW
MSYS_HOME to C:\MinGW\msys\1.0
PATH to ${MINGW_HOME}\bin;${MSYS_HOME}\bin;<my normal path>
and this allows Eclipse to launch gcc as part of the build process.
NOTE The above setting were done automatically on my machine because mingw was correctly located by the heuristic.
Here is a screenshot of the build settings if it helps:
Prefix: Under the hood
To try and answer part of your original question about what Prefix is, I provide the below information. It is unlikely to be particularly helpf
Prefix, in GCC parlance, refers to the directory under which all the related GCC files are placed. With different prefixes you can have multiple GCC installed on your machine.
From the GCC FAQ:
It may be desirable to install multiple versions of the compiler on
the same system. This can be done by using different prefix paths at
configure time and a few symlinks.
The concept comes from autotools in general. Autotools is the standard GNU make system (where you do ./configure && make - simplified). The prefix is the command line option to the configure stage (--prefix) to specify where to install the tool to. GCC above uses the --prefix to allow multiple GCCs on your system.
If you really want to know more about this, read the autobook. The section on configuring covers --prefix:
‘--prefix=prefix’
The –prefix option is one of the most frequently
used. If generated ‘Makefile’s choose to observe the argument you pass
with this option, it is possible to entirely relocate the
architecture-independent portion of a package when it is installed.
For example, when installing a package like Emacs, the following
command line will cause the Emacs Lisp files to be installed in
‘/opt/gnu/share’:
$ ./configure --prefix=/opt/gnu
It is important to stress that this behavior is dependent on the generated files making use of this
information. For developers writing these files, Automake simplifies
this process a great deal. Automake is introduced in Introducing GNU
Automake.
Additionally, Mingw takes advantage of all this prefix options. Read more about that on mingw's site. But the short of it is that the main prefix for mingw is /mingw.
(David James both wrote the question and an answer. I'll edit it to conform to Stackoverflow standards.)
Using SBCL you can compile Lisp code to machine code.
Like Java, .net, C++ and even C you will need the runtime. So there are two ways to compile Common Lisp code.
First is to make huge binaries which is explained in SBCL documentation. No SBCL needed on target machine.
The other way is a more flexible one, which is to create machine code in a fasl (FASt Load) format. The SBCL runtime is needed on the target machine.
How does the second way work under a Unix-like operating system?
(Answer by David James:)
We are going to make two commands in our system: one for batch compiling Lisp code and the other for easily running Lisp code:
Using your favorite editor, open a file called sbcl.compile. The content should be:
#!/bin/bash
sbcl --noinform --eval "(compile-file \"$1\")" --eval "(quit)" > /dev/null
Now to compile Lisp files use:
# sbcl.compile hello.lisp
This will create a hello.fasl file.
Now to easily run these files, we create a new command. Using your favorite editor open a file called sbcl.run. The content should be:
#!/bin/bash
sbcl --noinform --load "$1" --quit --end-toplevel-options "$#"
Now you may invoke sbcl.run hello.fasl to run the native code.
# sbcl.run hello.fasl
Details are described in the SBCL manual: Starting SBCL
Another option is to add to the runtime all packages/functions/frameworks that you commonly use, and then save this state as a new core file, and use this as your default core while continuing development. I usually find fasls more trouble than they are worth, especially since lisp has the ability to save state in a VM-style core file. I just incrementally update the core as development moves along. And rebuild/update the core using GNU Make.
I have an app that I pack into "binary" form using PerlApp for distribution. Since my clients want a simple install for their Win32 systems, this works very nicely.
Now a client has decided that they need to run all unit tests, like in a standard install. However, they still will not install a normal Perl.
So, I find myself in need of a way to package my unit tests for operation on my client's systems.
My first thought was that I could pack up prove in one file and pack each of my tests separately. Then ship a zip file with the appropriate structure.
A bit of research showed that Test::Harness::Straps invokes perl from the command line.
Is there an existing tool that helps with this process?
Perhaps I could use PAR::Packer's parl tool to handle invocation of my test scripts.
I'm interested in thoughts on how to apply either PAR or PerlApp, as well as any thoughts on how to approach overriding Test::Harness and friends.
Thanks.
Update: I don't have my heart set on PAR or PerlApp. Those are just the tools I am familiar with. If you have an idea or a solution that requires a different packager (such as Cava Packager), I would love to hear about it.
Update 2: tsee pointed out a great new feature in PAR that gets me close. Are there any TAP experts out there that can supply some ideas or pointers on where to look in the new Test::Harness distribution?
I'm probably not breaking big news if I tell you that PAR (and probably also perlapp) aren't meant to package the whole test suite and plethora of CPAN-module build byproducts. They're intended to package stand-alone applications or binary JAR-like module libraries.
This being said, you can add arbitrary files to a PAR archive (both to .par libraries and stand-alone .exe's) using pp's -a switch. In case of the stand-alone executable, the contents will be extracted to $ENV{PAR_TEMP}."/inc" at run-time.
That leaves you with the problem of reusing the PAR-packaged executable to run the test harness (and letting that run your executable as a "perl"). Now, I have no ready and done solution for that, but I've recently worked on making PAR-packaged executables re-useable as more-or-less general purpose perl interpreters. Two gotchas before I explain how you can use that:
Your application isn't going to magically be called "perl" and add itself to your $PATH.
The "reuse" of the application as a general purpose perl requires special options and does not currently support the normal perl options (those in perlrun). It can simply run an external perl script of your choice.
Unfortunately, the latter problem is what may kill this approach for you. Support for perl command line options is something I've been thinking about, but won't implement any time soon.
Here's the recipe how you get PAR with "reusable exe" support:
Install the newest version of PAR from CPAN.
Install the newest, developer version of PAR::Packer from CPAN (0.992_02 or 03).
Add the "--reusable" option to your pp command line.
Run your executable with the following options to run an external script "foo.pl":
./myapp --par-options --reuse foo.pl FOO-PL-OPTIONS-HERE
Unfortunately, how you're going to teach Test::Harness that "./myapp --par-options --reuse" is a perl interpreter is beyond me.
Cava Packager allows you to package test scripts with your packaged executables. This is primarily to allow you to run tests against the packaged code before distribution. However the option is there to also distribute the tests and test capability to your end users.
Note: As indicated by my name, I am affiliated with Cava Packager.
I'm trying to link an RPATH containing the special string $ORIGIN into an executable built using GCC with the Code::Blocks IDE. I've specified
-Wl,-R$ORIGIN
in the linker options for the project, but the command line output to GCC is wrong (stripped for clarity):
g++ -Wl,-R
What is the correct way to specify this argument for Code::Blocks?
Whoever decided to make the token $ORIGIN is an evil bastard who deserves a special place in programmer hell. Since '$' is a special character for bash and other scripting languages like make, it screws everything up unless carefully escaped. Even worse, depending on which build environment you're using, the specifics of how to escape properly will likely change.
In bash, you need to stick a backslash in front of the $:
-Wl,-R\$ORIGIN
Code::Blocks apparently also treats the $ as special. Then, whatever subprocess controller Code::Blocks sends the command to treats the backslash as special. So, both the backslash and the $ need to be doubled up to get escaped properly. Therefore, in Code::Blocks linker settings, you need to specify:
-Wl,-R\\$$ORIGIN
...which outputs:
-Wl,-R\\$ORIGIN
...to the build log, but the shell actually gets sent:
-Wl,-R\$ORIGIN
...which as mentioned above produces the desired result.
What a pain.
In addition to kblucks answer that addresses the question for Code:Blocks....
For those like me who stumbled across this page looking for how to do this with Make.
The trick is to use an extra $ sign as an escape character and to enclose it with quotes:
-Wl,-R,'$$ORIGIN/../lib'
Full explanation can be had here:
Using ORIGIN for a dynamic runtime library search path
If your executable is being built by a huge complex script environment not created by you, and you don't want to delve into with that, trying running with setenv LD_RUN_PATH='$ORIGIN/../lib'; if that doesn't work, a pragmatic approach is to create a wrapper for ld:
#!/bin/sh
exec /usr/bin/ld -R '$ORIGIN/../lib' "$#"
... then do the build with that stub on the path. In practice it may be called to build .so files, or other executables, so you may need to make this a more complex script that decides whether to insert the RPATH. OR, run build without this, and with, and cherry pick.
(here "/usr/bin/ld" is the ld that would normally have been run, which may be somewhere else. gcc may not pick up ld from the path, see gcc environment variables to override that. Mileage may vary. Single use only. Not warranted to be less awful than any other approach).