Free compilers software for linux

BlackRhino is a free Debian-based GNU/Linux software distribution for the Sony PlayStation 2.

BlackRhino is a free Debian-based GNU/Linux software distribution for the Sony PlayStation 2. It contains over 1,200 software packages to aid in using and creating programs for the Sony PlayStation 2 Linux kit.

The programs range in functionality from simple games, to text editors, compilers, web servers, windowing systems, database systems, graphics packages, mail servers and a variety of other tools and utilities.

The software distribution was created by xRhino for a commercial Sony PlayStation 2 title. It is released in the hopes that the distribution will help hobbyists create their own games and applications that utilize the advanced programmable hardware of the PS2.

distcc is a program to distribute builds of C, C++, Objective C or Objective C++ code across several machines on a network.

distcc should always generate the same results as a local build, is simple to install and use, and is usually much faster than a local compile.

distcc does not require all machines to share a filesystem, have synchronized clocks, or to have the same libraries or header files installed.

They can even have different processors or operating systems, if cross-compilers are installed.

PowerMail provides a redundant and distributed system for receiving and storing mail.
PowerMail is a redundant and distributed system for receiving mail via SMTP and storing it for users to access with POP. The way PowerMail works is quite unorthodox, and its design emphasizes speed and efficiency.
Modified Maildir mailboxes allow PowerMail to employ hardlinks to save diskspace and deliver messages with thousands of recipients instantly.
PowerMail can operate self-sufficiently or cooperate with a regular MTA to support mail forwarding.
Enhancements:
- fixes for older gcc compilers (Ruben dArco)
- pptool ignored SYSCONFDIR and only did /etc/powermail (Ruben dArco)
- added ldap-forwarding-attribute
- --help display was somewhat screwed (Ruben dArco)
- run-as-uid/run-as-gid broken (Ruben dArco)
- TOP cleaned up (Ruben dArco)

Stratego/XT is a development environment for creating stand-alone transformation systems.
It combines Stratego, a language for implementing transformations based on the paradigm of programmable rewriting strategies, with XT, a collection of reusable components and tools for the development of transformation systems.
In general, Stratego/XT is intended for the analysis, manipulation, and generation of programs, though its features make it useful for transforming any structured documents.
In practice, it has been used to build many types of transformation systems including compilers, interpreters, static analyzers, domain-specific optimizers, code generators, source code refactorers, documentation generators, and document transformers.
Enhancements:
- The compiler was restructured.
- Some old language features were removed.
- Man pages for all tools were completed.
- A new introductory tutorial with examples was co-released, and more.

Acovea implements a genetic algorithm for finding the "best" options for compiling programs with the GCC C and C++ compilers.
ACOVEA (Analysis of Compiler Options via Evolutionary Algorithm) implements a genetic algorithm to find the "best" options for compiling programs with the GNU Compiler Collection (GCC) C and C++ compilers.
"Best", in this context, is defined as those options that produce the fastest executable program from a given source code. Acovea is a C++ framework that can be extended to test other programming languages and non-GCC compilers.
I envision Acovea as an optimization tool, similar in purpose to profiling. Traditional function-level profiling identifies the algorithms most influential in a programs performance; Acovea is then applied to those algorithms to find the compiler flags and options that generate the fastest code.
Acovea is also useful for testing combinations of flags for pessimistic interactions, and for testing the reliability of the compiler.
Modern software is difficult to understand and verify by traditional means. Millions of lines of code produce applications containing intricate interactions, defying simple description or brute-force investigation.
A guided, deterministic approach to testing relies on human testers to envision every possible combination of actions -- an unrealistic proposition given software complexity. Yet, despite that complexity, we need answers to important questions about modern, large-scale software.
What sort of important questions? Consider the GNU Compiler Collection. I write articles that benchmark code generation, a task fraught with difficulties due to the myriad options provided by different compilers. For my benchmarks to have any meaning, I need to know which combination of options produces the fastest code for a given application.
Finding the "best" set of options sounds like a simple task, given the extent of GCC documentation and the conventional wisdom of the GCC developer community. Ah, if it were only so easy! The GCC documentation, while extensive, is also honestly imprecise.
I appreciate this style of documentation; unlike many commercial vendors, who make absolute statements about the "quality" of their products, GCCs documenters admit uncertainties in how various options alter code generation. Indeed, code generation is entirely dependent on the type of application being compiled and the target platform. An option that produces fast executable code for one source code may be detrimental to the performance of another program.
"Conventional wisdom" arrives in my inbox whenever I publish a new article. Ranging from the polite to the insistent to the rude, these e-mails contain contradictory suggestions for producing fast code.
In the vast majority of cases, such anecdotal assertions lack any formal proof of their validity, and, more often than not, the suggested "improvement" is ineffective or detrimental. It has become increasingly obvious that no one --myself included -- knows precisely how all these GCC options work together in generating program code.
I seek the Holy Grail of Optimization -- but exactly what is optimization? Understanding the problem is the first step in finding a solution.
Optimization attempts to produce the "best" machine code from source code. "Best" means different things to different applications; a database shovels chunks of information, while a scientific application is concerned with fast and accurate results; the first concern for an embedded system may be code size.
And it is quite possible that small code is fast, or fast code accurate. Optimization is far from being an exact science, given the diversity of hardware and software configurations.
An optimization algorithm may be as simple as removing a loop invariant, or as complex as examining an entire program to eliminate global common sub-expressions. Many optimizations change what the programmer wrote into a more efficient form, producing the same result while altering underlying details for efficiency; other "optimizations" produce code that uses specific characteristics of the underlying hardware, such as special instruction sets.
Memory architectures, pipelines, on- and off-chip caches -- all affect code performance in ways that are not obvious to programmers using a high-level language. An optimization that may seem to produce faster code may, in fact, create large code that causes more cache misses, thus degrading performance.
Even the best hand-tuned C code contains areas of interpretation; there is no absolute, one-to-one correspondence between C statements and machine instructions. Almost any sequence of source code can be compiled into different -- but functionally equivalent -- machine instruction streams with different sizes and performance characteristics.
Inlining functions is a classic example of this phenomena: replacing a call to a function with the function code itself may produce a faster program, but may also increase program size. Increased program size, may, in turn, prevent an algorithm from fitting inside high-speed cache memory, thus slowing a program due to cache misses.
Notice my use of the weasel word "may" -- inlining small functions sometimes allows other optimization algorithms a chance to further improve code for local conditions, producing faster and smaller code.
Optimization is not simple or obvious, and combinations of algorithms can lead to unexpected results. Which brings me back to the question: For any given application, what are the most effective optimization options?
Enhancements:
- Minor changes in the non-free license.
- Support has been added for the latest versions of libcoyotl and libevocosm.

Scriptol to Php Compiler is a scriptol program that may be interpreted by the Php interpreter and it may be also compiled either to C++ or directly as an executable.

The Php interpreter is required by solp (download it at www.php.net or get it on the Scriptol CD).

Installation:

It is better to install Scriptol at root of a disk, for example:
/home/user/scriptolp

Once the archive is extracted into the scriptolp directory, you have just to go to this directory from the console to run the compiler.

To use the compiler at command line from any directory, you have to put the compilers into the path, in the usr directory for exemple, or any directory assigned to the path variable (see .bashrc or equivalent). You may also add the scriptol directory to list of paths. Before to use the compiler, you have to read the licence, in the doc directory: licence.html.

Usage:

Type the source of your program in a text editor and save it as mysource.sol or any other name with the sol extension.

Then just type:

./solp mysource

To know the compilers options, type solp without argument, at command line.

Examples:

Type from the main scriptol directory:
./solp demos/helloyou

XMMS VQF Plugin is the native Plugin for XMMS. I felt it was important to get it out there when I was pretty sure there was no serious bugs. If you do find a bug, read the INSTALL and ChangeLog files for details of what to do.

Kindly dont send mails of the nature, It sucks or, its broke with no additional information. I am confident there wont be need for mails like that though.

Compiling is usually trivial, ./configure, make, make install. Under Debian, it depends on the libglib1.2-dev and libgtk1.2-dev packages so youll need to install them.

However, XMMS VQF Plugin also depends on a binary SDK, it will not work with newer compilers. Late 3.2 compilers and all 3.3 compilers are known to now work unless the std namespace is explicitly disabled for the g++ build.

If you use a recent compiler, download the binary version of the plugin instead. If you have your input plugins somewhere other than /usr/local/lib/xmms/Input, you will need to add a --prefix to the ./configure.

ccache is a compiler cache. It acts as a caching pre-processor to C/C++ compilers, using the -E compiler switch and a hash to detect when a compilation can be satisfied from cache. This often results in a 5 to 10 times speedup in common compilations.
The idea came from Erik Thiele wrote the original compilercache program as a bourne shell script. ccache is a re-implementation of Eriks idea in C with more features and better performance.
Why bother with a compiler cache? If you ever run "make clean; make" then you can probably benefit from ccache. It is very common for developers to do a clean build of a project for a whole host of reasons, and this throws away all the information from your previous compiles.
By using ccache you can get exactly the same effect as "make clean; make" but much faster. It also helps a lot when doing RPM builds, as RPM can make doing incremental builds tricky.
I put the effort into writing ccache for 2 reasons. The first is the Samba build farm (http://build.samba.org/) which constantly does clean builds of Samba on about 30 machines after each CVS commit. On some of those machines the build took over an hour. By using ccache we get the same effect as clean builds but about 6 times faster.
The second reason is the autobuild system I used to run for Quantum. That system builds our whole Linux based OS from scratch after every CVS commit to catch compilation problems quickly. Using ccache those builds are much faster.
Main features:
- keeps statistics on hits/misses
- automatic cache size management
- can cache compiles that generate warnings
- easy installation
- very low overhead
- uses hard links where possible to avoid copies
Enhancements:
- Added CCACHE_READONLY option
- Added CCACHE_TEMPDIR option
- fixed handling of hard-linked compilers on AIX
- added O_BINARY support, to try and support win32 compiles
- show cache directory in stats output
- fixed handling of HOME environment variable