There are (in most cases, discounting interpreted code) two stages in getting from source code (what you write) to executable code (what you run).
The first is compilation which turns source code into object modules.
The second, linking, is what combines object modules together to form an executable.
The distinction is made for, among other things, allowing third party libraries to be included in your executable without you seeing their source code (such as libraries for database access, network communications and graphical user interfaces), or for compiling code in different languages (C and assembly code for example) and then linking them all together.
When you statically link a file into an executable, the contents of that file are included at link time. In other words, the contents of the file are physically inserted into the executable that you will run.
When you link dynamically, a pointer to the file being linked in (the file name of the file, for example) is included in the executable and the contents of said file are not included at link time. It's only when you later run the executable that these dynamically linked files are bought in and they're only bought into the in-memory copy of the executable, not the one on disk.
It's basically a method of deferred linking. There's an even more deferred method (called late binding on some systems) that won't bring in the dynamically linked file until you actually try to call a function within it.
Statically-linked files are 'locked' to the executable at link time so they never change. A dynamically linked file referenced by an executable can change just by replacing the file on the disk.
This allows updates to functionality without having to re-link the code; the loader re-links every time you run it.
This is both good and bad - on one hand, it allows easier updates and bug fixes, on the other it can lead to programs ceasing to work if the updates are incompatible - this is sometimes responsible for the dreaded "DLL hell" that some people mention in that applications can be broken if you replace a dynamically linked library with one that's not compatible (developers who do this should expect to be hunted down and punished severely, by the way).
As an example, let's look at the case of a user compiling their main.c
file for static and dynamic linking.
Phase Static Dynamic
-------- ---------------------- ------------------------
+---------+ +---------+
| main.c | | main.c |
+---------+ +---------+
Compile........|.........................|...................
+---------+ +---------+ +---------+ +--------+
| main.o | | crtlib | | main.o | | crtimp |
+---------+ +---------+ +---------+ +--------+
Link...........|..........|..............|...........|.......
| | +-----------+
| | |
+---------+ | +---------+ +--------+
| main |-----+ | main | | crtdll |
+---------+ +---------+ +--------+
Load/Run.......|.........................|..........|........
+---------+ +---------+ |
| main in | | main in |-----+
| memory | | memory |
+---------+ +---------+
You can see in the static case that the main program and C runtime library are linked together at link time (by the developers). Since the user typically cannot re-link the executable, they're stuck with the behaviour of the library.
In the dynamic case, the main program is linked with the C runtime import library (something which declares what's in the dynamic library but doesn't actually define it). This allows the linker to link even though the actual code is missing.
Then, at runtime, the operating system loader does a late linking of the main program with the C runtime DLL (dynamic link library or shared library or other nomenclature).
The owner of the C runtime can drop in a new DLL at any time to provide updates or bug fixes. As stated earlier, this has both advantages and disadvantages.
Windows can only show a limited number of Overlay Icons (15 total, 11 after what Windows uses). Programs like Office Groove, Dropbox, Mozy, Carbonite, etc, will hijack a bunch of the 11 possible overlay icons (boy would it be nice if Microsoft upped the number of these as the number of applications that use them seem to increase and increase)...
You can see what overlays are set up, and change them (at your own risk) in the registry here:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\explorer\ShellIconOverlayIdentifiers
If you are using TortoiseCVS (and have nothing else using overlay icons), you will get a couple of TortoiseSVN Icons, and all of your TortoiseCVS icons. This is because the overlay icons are used in alphabetical order. Again, at your own risk (editing the registry may blow up your computer, yada, yada, yada -- and if you are reading Stack Overflow and using Windows and haven't edited the registry, you are a rare beast indeed), feel free to rename them (I suggest putting numbers in front of the ones you want to use and "z_"'s prefixed to the ones you don't need). The TortoiseSVN Shell extensions are nicely named so you know what they do, the TortoiseCVS extensions are not. After looking through the source code, I found the pertinent information:
- TortoiseCVS0 - In CVS
- TortoiseCVS1 - Not in CVS
- TortoiseCVS3 - Conflicted
- TortoiseCVS4 - In CVS readonly
- TortoiseCVS5 - Ignored
- TortoiseCVS6 - Added
- TortoiseCVS7 - Deleted
- TortoiseCVS8 - Locked
Best Answer
After similar frustrations, I have just now compiled both a 32bit and 64bit version of libreadline 6.2 using MinGW-w64. Here's my how I did it:
Layout of my dev directory:
Set some environment variables for the 32 bit build:
termcap 1.3.1.
Run the configure script:
Edit termcap.c and fix up a few lines at the top. Mine looks like this:
and tparam.c
Modify the Makefile:
After that call make install and it should compile without warnings or errors.
readline 6.2
Set the same CPPFLAGS and LDFLAGS variables as with termcap before calling:
Edit the Makefile:
make install should now compile and install readline!
If you want a 64bit library, replace i686-w64-mingw32 with x86_64-w64-mingw32 and local32 with local64.