how-programming.texinfo

cygwin, 著名的在win32下模拟unix操作系统的东东

@section Programming Questions

@subsection How do I contribute a package?

If you are willing to be a package maintainer, great.  We urgently need
volunteers to prepare and maintain packages, because the priority of the
Cygwin Team is Cygwin itself.

There will be a separate web page where all the details are documented,
but this is not prepared yet.  Meanwhile, pore through the cygwin-apps
mailing archives (start at @file{http://cygwin.com/lists.html}), and
subscribe.  Charles Wilson posted a short recipe of what's involved,
using texinfo as an example,
at @file{http://cygwin.com/ml/cygwin-apps/2000-11/msg00055.html}.  This
should give you an idea of what is required.

You should announce your intentions to the general cygwin list, in case
others were thinking the same thing.

@subsection How do I contribute to Cygwin?

If you want to contribute to Cygwin itself, see
@file{http://cygwin.com/contrib.html}.

@subsection Why are compiled executables so huge?!?

By default, gcc compiles in all symbols.  You'll also find that gcc
creates large executables on UNIX.

If that bothers you, just use the 'strip' program, part of the binutils
package.  Or compile with the @samp{-s} option to gcc.

@subsection Where is glibc?

Cygwin does not provide glibc.  It uses newlib instead, which provides
much (but not all) of the same functionality.  Porting glibc to Cygwin
would be difficult.

@subsection Where is Objective C?

Objective C is not distributed with the Cygwin version of gcc, and there
are no plans to do so.  The gcc package maintainer had difficulty
building it, and once built there were problems using it.  It appears
that there is only minimual support for the Objective C front-end in the
main GCC distribution, anyway.

@subsection Why is make behaving badly?

First of all, if you are using @samp{make -j[N]}, then stop.  It doesn't
work well.

Otherwise, read on...

Make has two operating modes, UNIX and WIN32.  You need to make sure
that you are operating in the right mode.

In UNIX mode, make uses sh.exe as a subshell.  The path list separator
is ':', '\' is the escape character, POSIX paths are expected, and
Cygwin mounts will be understood.  Use this for Makefiles written for
UNIX.

In WIN32 mode, make uses the "native" command shell (cmd.exe or
command.com), with all the restrictions that implies.  The path list
separator is ';', the path separator is '\', "copy" and "del" work, but
the Cygwin mount table is not understood.  Use this for nmake-style
Makefiles.

The default mode for the Net Release of make (the one installed by
@code{setup.exe}) is UNIX.  The default mode for commercial releases to
Redhat (formerly Cygnus) customers is WIN32.

You can override the default by setting the environment variable
MAKE_MODE to "UNIX" (actually case is not significant) or "WIN32"
(actually anything other than "UNIX").  You can also specify the options
--unix or --win32 on the make command line.

@subsection Why the undefined reference to @samp{WinMain@@16}?

Try adding an empty main() function to one of your sources.

Or, perhaps you have @samp{-lm} too early in the link command line.  It
should be at the end:

@example
    bash$ gcc hello.c -lm
    bash$ ./a.exe
    Hello World!
@end example

works, but

@example
    bash$  gcc -lm hello.c
    /c/TEMP/ccjLEGlU.o(.text+0x10):hello.c: multiple definition of `main'
    /usr/lib/libm.a(libcmain.o)(.text+0x0):libcmain.c: first defined here
    /usr/lib/libm.a(libcmain.o)(.text+0x6a):libcmain.c: undefined reference to `WinMain@@16'
    collect2: ld returned 1 exit status
@end example

This is an artifact of libm.a being a symbolic link to libcygwin.a.

@subsection How do I use Win32 API calls?

@strong{(Please note: This section has not yet been updated for the latest
net release.)}

It's pretty simple actually.  Cygwin tools require that you explicitly
link the import libraries for whatever Win32 API functions that you
are going to use, with the exception of kernel32, which is linked
automatically (because the startup and/or built-in code uses it).

For example, to use graphics functions (GDI) you must link
with gdi32 like this:

gcc -o foo.exe foo.o bar.o -lgdi32

or (compiling and linking in one step):

gcc -o foo.exe foo.c bar.c -lgdi32

The following libraries are available for use in this way:

advapi32  largeint  ole32     scrnsave  vfw32
cap       lz32      oleaut32  shell32   win32spl
comctl32  mapi32    oledlg    snmp      winmm
comdlg32  mfcuia32  olepro32  svrapi    winserve
ctl3d32   mgmtapi   opengl32  tapi32    winspool
dlcapi    mpr       penwin32  th32      winstrm
gdi32     msacm32   pkpd32    thunk32   wow32
glaux     nddeapi   rasapi32  url       wsock32
glu32     netapi32  rpcdce4   user32    wst
icmp      odbc32    rpcndr    uuid
imm32     odbccp32  rpcns4    vdmdbg
kernel32  oldnames  rpcrt4    version

The regular setup allows you to use the option -mwindows on the
command line to include a set of the basic libraries (and also
make your program a GUI program instead of a console program),
including user32, gdi32 and, IIRC, comdlg32.

Note that you should never include -lkernel32 on your link line
unless you are invoking ld directly.  Do not include the same import
library twice on your link line.  Finally, it is a good idea to
put import libraries last on your link line, or at least after
all the object files and static libraries that reference them.

The first two are related to problems the linker has (as of b18 at least)
when import libraries are referenced twice.  Tables get messed up and
programs crash randomly.  The last point has to do with the fact that
gcc processes the files listed on the command line in sequence and
will only resolve references to libraries if they are given after
the file that makes the reference.

@subsection How do I compile a Win32 executable that doesn't use Cygwin?

The -mno-cygwin flag to gcc makes gcc link against standard Microsoft
DLLs instead of Cygwin.  This is desirable for native Windows programs
that don't need a UNIX emulation layer.

This is not to be confused with 'MinGW' (Minimalist GNU for Windows),
which is a completely separate effort.  That project's home page is
@file{http://www.mingw.org/index.shtml}.

@subsection Can I build a Cygwin program that does not require cygwin1.dll at runtime?

No.  If your program uses the Cygwin API, then your executable cannot
run without cygwin1.dll.  In particular, it is not possible to
statically link with a Cygwin library to obtain an independent,
self-contained executable.

If this is an issue because you intend to distribute your Cygwin
application, then you had better read and understand
@file{http://cygwin.com/licensing.html}, which explains the licensing
options.  Unless you purchase a special commercial license from Red
Hat, then your Cygwin application must be Open Source.

@subsection Can I link with both MSVCRT*.DLL and cygwin1.dll?

No, you must use one or the other, they are mutually exclusive.

@subsection How do I make the console window go away?

The default during compilation is to produce a console application.
It you are writing a GUI program, you should either compile with
-mwindows as explained above, or add the string
"-Wl,--subsystem,windows" to the GCC commandline.

@subsection Why does make complain about a "missing separator"?

This problem usually occurs as a result of someone editing a Makefile
with a text editor that replaces tab characters with spaces.  Command
lines must start with tabs.  This is not specific to Cygwin.

@subsection Why can't we redistribute Microsoft's Win32 headers?

Subsection 2.d.f of the `Microsoft Open Tools License agreement' looks
like it says that one may not "permit further redistribution of the
Redistributables to their end users".  We take this to mean that we can
give them to you, but you can't give them to anyone else, which is
something that Cygnus (err... Red Hat) can't agree to.  Fortunately, we
have our own Win32 headers which are pretty complete.

@subsection How do I link against .lib files?

@strong{(Please note: This section has not yet been updated for the latest
net release.)}

1. Build a C file with a function table.  Put all functions you intend
to use in that table.  This forces the linker to include all the object
files from the .lib.  Maybe there is an option to force LINK.EXE to
include an object file.
2. Build a dummy 'LibMain'.
3. Build a .def with all the exports you need.
4. Link with your .lib using link.exe.

or

1. Extract all the object files from the .lib using LIB.EXE.
2. Build a dummy C file referencing all the functions you need, either
with a direct call or through an initialized function pointer.
3. Build a dummy LibMain.
4. Link all the objects with this file+LibMain.
5. Write a .def.
6. Link.

You can use these methods to use MSVC (and many other runtime libs)
with Cygwin development tools.

Note that this is a lot of work (half a day or so), but much less than
rewriting the runtime library in question from specs...

(thanks to Jacob Navia (root@@jacob.remcomp.fr) for this explanation)

@subsection How do I rebuild the tools on my NT box?

Install all required components in one directory (we'll call it /src).
Ideally, you should check out what you need from CVS (@file{http://cygwin.com/cvs.html}) but
otherwise, you can install the appropriate source packages from the
cygwin distribution.

As of this writing, you need to install at least the cygwin source
package and the w32api source package.

It is possible that the cygwin source package may require a newer
version of the w32api package since the release of the packages is
not always in lock step (another reason to just use CVS).

You @emph{must} build cygwin in a separate directory from the source.
So, create something like a /obj directory.  You'll be performing
your build in that directory:

@example
bash
cd /obj
/src/configure --prefix=/install -v > configure.log 2>&1
make > make.log 2>&1
make install > install.log 2>&1
@end example

Normally, this procedure will also attempt to build the documentation,
which additionally requires db2html, and possibly other tools, which are
not included in the Cygwin distribution.  You can get db2html as part of
docbook, from @file{http://sources.redhat.com/docbook-tools/}.

To check a cygwin1.dll, run "make check" in the winsup/cygwin directory.
If that works, install everything @emph{except} the dll (if you can).
Then, close down all cygwin programs (including bash windows, inetd,
etc.), save your old dll, and copy the new dll to @emph{all} the
places where the old dll was (if there is more than one on your
machine).  Then start up a bash window and see what happens.  (Or better,
run a cygwin program from the Windows command prompt.)

If you get the error "shared region is corrupted" it means that two
different versions of cygwin1.dll are running on your machine at the
same time.

@subsection How can I compile a powerpc NT toolchain?

@strong{(Please note: This section has not yet been updated for the latest
net release.)}

Unfortunately, this will be difficult.  It hasn't been built for
some time (late 1996) since Microsoft has dropped development of
powerpc NT.  Exception handling/signals support semantics/args have been
changed for x86 and not updated for ppc so the ppc specific support would
have to be rewritten.  We don't know of any other incompatibilities.
Please send us patches if you do this work!

@subsection How can I compile an Alpha NT toolchain?

@strong{(Please note: This section has not yet been updated for the latest
net release.)}

We have not ported the tools to Alpha NT and do not have plans to
do so at the present time.  We would be happy to add support
for Alpha NT if someone contributes the changes to us.

@subsection How can I adjust the heap/stack size of an application?

@strong{(Please note: This section has not yet been updated for the latest