DLLs used by the cygwin built executables

For Windows executable that are built in cygwin to run, the executable depends on some DLLs of cygwin. Hence the executable cannot run on a PC with Windows that sans those DLLs of cygwin.

For such executable to run on PCs with Windows, the dependent DLLs should also be used along with the executable.

Ok, how to find out on what DLLs a executable that built on cygwin depends? Simple, to list out the DLLs use

• objdump -p executable.exe | grep "DLL Name"

For example, I listed the DLLs used by executable 'cc1.exe'. 'cc1.exe' is generated in cygwin. 'cc1.exe' is a compiler generated using GCC.

D:\GCC>objdump -p cc1.exe | grep "DLL Name"
        DLL Name: cygwin1.dll
        DLL Name: cygiconv-2.dll
        DLL Name: cygintl-8.dll
        DLL Name: KERNEL32.dll

Enumeration constant in Macro definition

We use symbolic constants to get rid off magic numbers - hard coded values in programs. There three ways to define symbolic constants. They are

1. Macros
2. enumeration constants
3. const objects

Among the above three, the standard coding practice suggests to use the enumeration constant for programming.

Refer symbolic constants for the details on the above three methods.

The above is just a pre-requisite for further reading.

For porting GCC (GNU Compiler Collection - a compiler generation framework) to a new architecture, we require to feed in the information of the new architecture into the GCC. This information on new architecture is feed into GCC in the form of machine description. The machine descriptions include macros and LISP like languages for defining the new architecture.

There are macros that would define the information on new architecture registers. Each such macro is defined with the corresponding register number.

For example,

#define FIRST_PSEUDO_REGISTER 32

The macro FIRST_PSEUDO_REGISTER defines the register number that can be given to the first pseudo (scratch) register. The register numbers for the pseudo registers should start from the number next to the last actual register (as in architecture) number. Consider there are 32 actual registers in the architecture. Then the actual registers are with numbers from 0 to 31. So, from the number (32) next to the last actual register (31), shall be assigned to the pseudo registers.

Hence the macro FIRST_PSEUDO_REGISTER is defined with the total number of registers.

Then there is another macro,

#define STACK_POINTER_REGNUM 30

The macro STACK_POINTER_REGNUM defines the register number that would be used as stack pointer.

Similarly there are other macros. Here we are to use such numbers of registers for defining the macros. What we thought of is, instead of magic numbers of registers why can't we have a enumeration that defines the constants for the registers in an architecture. If that is so, we can just use the enumeration constant names in place of the numbers.

And we did as follows:

#define FIRST_PSEUDO_REGISTER eTOTAL_REGISTERS_KNOWN_TO_COMPILER

#define STACK_POINTER_REGNUM eR7


And do you think this is safe? Could you see there could be some problems in doing so?

Yes, it is true we didn't see anything while doing so. But we ended-up in failure while building the compiler.

One thing we didn't think about the macros. That is, preprocessor plays some part with the numbers defined by the macros. The macros are used in the preprocessor statements. In such case, the numbers should be visible at the time of preprocessing. If we use the enumeration constant names as shown above, the preprocessor cannot see that as a number.

For example consider the below code with preprocessor statements:

#if FIRST_PSEUDO_REGISTER
// do something
#endif

for defining the macro 'FIRST_PSEUDO_REGISTER' with enum constant 'eTOTAL_REGISTERS_KNOWN_TO_COMPILER', the preprocessor would check as follows:

#if eTOTAL_REGISTERS_KNOWN_TO_COMPILER
// do something
#endif

#IF ... #ENDIF preprocessor directive conditionally includes source code at compile-time. The preprocessor expects for a numeric expression whereas here it gets a string 'eTOTAL_REGISTERS_KNOWN_TO_COMPILER'. And hence the source code inside #IF ... #ENDIF is not included for compilation. This is the cause for the problem during build.

OSS - explained

I was on the board of flight "Madurai to Mumbai" (within India). I got into conversation with a person sitting next to me. We introduced ourselves and discussed about eachother's profession. On hearing I am working on open source software (GCC) he asked what is a open source software and if it is for free how you people are making business out of it.

Not him, but many would be having these questions in their mind unanswered. How business is made out of open source softwares (here-in-after referred as OSS)?

OSS are softwares that should be freely distributed along with it's source code. Anyone must be allowed to modify the source code which can be redistributed further. Also it's license should not exclude the OSS to interfere with the operation of other softwares.

Some examples of OSS.

1. GNU/Linux operating system
   
2. GNU Compiler Collection(GCC)
   
3. Apache HTTP Server
   
4. Mozilla Firefox internet browser
   
5. OpenOffice
   
6. Perl language
   
7. PHP language
   
8. Python language
   

OSS is gaining popularity because OSS is free. I.e. OSS can be used, bought, sold, given, received, and modified. In fact, anything can be done with OSS except take ownership of it or restrict anyone else from having the same rights to it that one have.

OSS is freely available to provide the freedom for the following:

1. to run the program for any purpose
   
2. to study how the program works and adapt the same for own use
   
3. to redistribute copies
   
4. to improve the program and release your improvements to the public, so that the whole community benefits.
   

A common concern for end-users who wish to use open source software is the lack of a warranty and technical support. Companies gains by providing support to OSS users. I.e. They can act as consultants. They have access to source code, and hence they can provide better support.

For example, Red Hat created the "Official Red Hat Linux" and is able to sell this normally "free" software. The main value that Red Hat adds to the package is a warranty and technical support. For most businesses, the assurance of technical support has been a key factor in the decision to buy Linux instead of simply downloading it for free. In addition to Red Hat, there are several other companies that have packaged Linux, usually with additional software, for resale.