1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
|
<!-- faq-programming.xml -->
<qandaentry id="faq.programming.packages">
<question><para>How do I contribute a package?</para></question>
<answer>
<para>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.
</para>
<para>The Cygwin Package Contributor's Guide at
<ulink url="http://cygwin.com/setup.html">http://cygwin.com/setup.html</ulink> details everything you need to know
about being a package maintainer. The quickest way to get started is to
read the <emphasis>Initial packaging procedure, script-based</emphasis> section on
that page. The <literal>generic-build-script</literal> found there works well for
most packages.
</para>
<para>For questions about package maintenance, use the cygwin-apps mailing
list (start at <ulink url="http://cygwin.com/lists.html">http://cygwin.com/lists.html</ulink>) <emphasis>after</emphasis>
searching and browsing the cygwin-apps list archives, of course. Be
sure to look at the <emphasis>Submitting a package</emphasis> checklist at
<ulink url="http://cygwin.com/setup.html">http://cygwin.com/setup.html</ulink> before sending an ITP (Intent To
Package) email to cygwin-apps.
</para>
<para>You should also announce your intentions to the general cygwin list, in
case others were thinking the same thing.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.contribute">
<question><para>How do I contribute to Cygwin?</para></question>
<answer>
<para>If you want to contribute to Cygwin itself, see
<ulink url="http://cygwin.com/contrib.html">http://cygwin.com/contrib.html</ulink>.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.huge-executables">
<question><para>Why are compiled executables so huge?!?</para></question>
<answer>
<para>By default, gcc compiles in all symbols. You'll also find that gcc
creates large executables on UNIX.
</para>
<para>If that bothers you, just use the 'strip' program, part of the binutils
package. Or compile with the <literal>-s</literal> option to gcc.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.glibc">
<question><para>Where is glibc?</para></question>
<answer>
<para>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.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.objective-c">
<question><para>Where is Objective C?</para></question>
<answer>
<para>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 minimal support for the Objective C front-end in the
main GCC distribution, anyway.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.make-execvp">
<question><para>Why does my make fail on Cygwin with an execvp error? </para></question>
<answer>
<para>First of all, if you are using <literal>make -j[N]</literal>, then stop. It doesn't
work well. Also beware of using non-portable shell features in your
Makefiles (see tips at <ulink
url="http://cygwin.com/faq/faq.using.html#faq.using.shell-scripts" />).
</para>
<para>Errors of <literal>make: execvp: /bin/sh: Illegal Argument</literal> or
<literal>make: execvp: /bin/sh: Argument list too long</literal> are often
caused by the command-line being to long for the Windows execution model.
To circumvent this, mount the path of the executable using the -X switch
to enable cygexec for all executables in that folder; you will also need
to exclude non-cygwin executables with the -x switch. Enabling cygexec
causes cygwin executables to talk directly to one another, which increases
the command-line limit. To enable cygexec for <literal>/bin</literal> and
<literal>/usr/bin</literal>, you can use these commands in a batch file:
</para>
<screen>
mount -X -b -f c:\cygwin\bin /bin
mount -X -b -f c:\cygwin\bin /usr/bin
mount -x -b -f c:\cygwin\bin\tclsh84.exe /usr/bin/tclsh84.exe
mount -x -b -f c:\cygwin\bin\tclsh84.exe /bin/tclsh84.exe
mount -x -b -f c:\cygwin\bin\wish84.exe /usr/bin/wish84.exe
mount -x -b -f c:\cygwin\bin\wish84.exe /bin/wish84.exe
</screen>
<para>Note that if you have Tcl/Tk installed, you must specifically exclude
<literal>tclsh84</literal> and <literal>wish84</literal>, which are linked
to the Cygwin DLL but are not actually Cygwin programs. If you have added
other non-Cygwin programs to a path you want to mount cygexec, you can find
them with a script like this:
</para>
<screen>
#!/bin/sh
cd /bin; for f in `find . -type f -name '*.exe'`; do
cygcheck $f | (fgrep -qi cygwin1.dll || echo $f)
done
</screen>
<para>
See <ulink url="http://www.cygwin.com/cygwin-ug-net/using-utils.html#mount" />
for more information on using mount.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.winmain">
<question><para>Why the undefined reference to <literal>WinMain@16</literal>?</para></question>
<answer>
<para>If you're using <literal>gcc</literal>, try adding an empty main() function to one
of your sources. Or, perhaps you have <literal>-lm</literal> too early in the
link command line. It should be at the end:
</para>
<screen>
bash$ gcc hello.c -lm
bash$ ./a.exe
Hello World!
</screen>
<para>works, but
</para>
<screen>
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
</screen>
<para>If you're using GCJ, you need to pass a "--main" flag:
</para>
<screen>
gcj --main=Hello Hello.java
</screen>
</answer></qandaentry>
<qandaentry id="faq.programming.win32-api">
<question><para>How do I use Win32 API calls?</para></question>
<answer>
<para><emphasis role='bold'>(Please note: This section has not yet been updated for the latest net release.)</emphasis>
</para>
<para>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).
</para>
<para>For example, to use graphics functions (GDI) you must link
with gdi32 like this:
</para>
<para>gcc -o foo.exe foo.o bar.o -lgdi32
</para>
<para>or (compiling and linking in one step):
</para>
<para>gcc -o foo.exe foo.c bar.c -lgdi32
</para>
<para>The following libraries are available for use in this way:
</para>
<para>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
</para>
<para>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.
</para>
<para>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.
</para>
<para>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.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.win32-no-cygwin">
<question><para>How do I compile a Win32 executable that doesn't use Cygwin?</para></question>
<answer>
<para>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.
</para>
<para>This is not to be confused with 'MinGW' (Minimalist GNU for Windows),
which is a completely separate effort. That project's home page is
<ulink url="http://www.mingw.org/index.shtml">http://www.mingw.org/index.shtml</ulink>.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.static-linking">
<question><para>Can I build a Cygwin program that does not require cygwin1.dll at runtime?</para></question>
<answer>
<para>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.
</para>
<para>If this is an issue because you intend to distribute your Cygwin
application, then you had better read and understand
<ulink url="http://cygwin.com/licensing.html">http://cygwin.com/licensing.html</ulink>, which explains the licensing
options. Unless you purchase a special commercial license from Red
Hat, then your Cygwin application must be Open Source.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.msvcrt-and-cygwin">
<question><para>Can I link with both MSVCRT*.DLL and cygwin1.dll?</para></question>
<answer>
<para>No, you must use one or the other, they are mutually exclusive.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.no-console-window">
<question><para>How do I make the console window go away?</para></question>
<answer>
<para>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 command line.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.make-spaces">
<question><para>Why does make complain about a "missing separator"?</para></question>
<answer>
<para>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.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.win32-headers">
<question><para>Why can't we redistribute Microsoft's Win32 headers?</para></question>
<answer>
<para>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 we can't agree to. Fortunately, we
have our own Win32 headers which are pretty complete.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.msvs-mingw">
<question><para>How do I use <literal>cygwin1.dll</literal> with Visual Studio or MinGW?</para></question>
<answer>
<para>Before you begin, note that Cygwin is licensed under the GNU GPL (as
indeed are all other Cygwin-based libraries). That means that if your
code links against the cygwin dll (and if your program is calling
functions from Cygwin, it must, as a matter of fact, be linked against
it), you must apply the GPL to your source as well. Of course, this
only matters if you plan to distribute your program in binary form. For
more information, see <ulink url="http://gnu.org/licenses/gpl-faq.html">http://gnu.org/licenses/gpl-faq.html</ulink>. If
that is not a problem, read on.
</para>
<para>If you want to load the DLL dynamically, read
<literal>winsup/cygwin/how-cygtls-works.txt</literal> and the sample code in
<literal>winsup/testsuite/cygload</literal> to understand how this works.
The short version is:
</para>
<orderedlist><listitem><para>Make sure you have 4K of scratch space at the bottom of your stack.
</para></listitem>
<listitem><para>Invoke <literal>cygwin_dll_init()</literal>:
<screen>
HMODULE h = LoadLibrary("cygwin1.dll");
void (*init)() = GetProcAddress(h, "cygwin_dll_init");
init();
</screen>
</para></listitem>
</orderedlist>
<para>If you want to link statically from Visual Studio, to my knowledge
none of the Cygwin developers have done this, but we have this report
from the mailing list that it can be done this way:
</para>
<orderedlist><listitem><para>Use the impdef program to generate a .def file for the cygwin1.dll
(if you build the cygwin dll from source, you will already have a def
file)
</para>
<screen>
impdef cygwin1.dll > cygwin1.def
</screen>
</listitem>
<listitem><para>Use the MS VS linker (lib) to generate an import library
</para>
<screen>
lib /def=cygwin1.def /out=cygwin1.lib
</screen>
</listitem>
<listitem><para>Create a file "my_crt0.c" with the following contents
</para>
<screen>
#include <sys/cygwin.h>
#include <stdlib.h>
typedef int (*MainFunc) (int argc, char *argv[], char **env);
void
my_crt0 (MainFunc f)
{
cygwin_crt0(f);
}
</screen>
</listitem>
<listitem><para>Use gcc in a Cygwin prompt to build my_crt0.c into a DLL
(e.g. my_crt0.dll). Follow steps 1 and 2 to generate .def and
.lib files for the DLL.
</para>
</listitem>
<listitem><para>Download crt0.c from the cygwin website and include it in
your sources. Modify it to call my_crt0() instead of
cygwin_crt0().
</para>
</listitem>
<listitem><para>Build your object files using the MS VC compiler cl.
</para>
</listitem>
<listitem><para>Link your object files, cygwin1.lib, and my_crt0.lib (or
whatever you called it) into the executable.
</para></listitem>
</orderedlist>
<para>Note that if you are using any other Cygwin based libraries
that you will probably need to build them as DLLs using gcc and
then generate import libraries for the MS VC linker.
</para>
<para>Thanks to Alastair Growcott (alastair dot growcott at bakbone dot co
dot uk) for this tip.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.linking-lib">
<question><para>How do I link against a <literal>.lib</literal> file?</para></question>
<answer>
<para>If your <literal>.lib</literal> file is a normal static or import library with
C-callable entry points, you can list <literal>foo.lib</literal> as an object file for
gcc/g++, just like any <literal>*.o</literal> file. Otherwise, here are some steps:
</para>
<orderedlist><listitem><para>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.
</para></listitem>
<listitem><para>Build a dummy 'LibMain'.
</para></listitem>
<listitem><para>Build a .def with all the exports you need.
</para></listitem>
<listitem><para>Link with your .lib using link.exe.
</para></listitem>
</orderedlist>
<para>or
</para>
<orderedlist><listitem><para>Extract all the object files from the .lib using LIB.EXE.
</para></listitem>
<listitem><para>Build a dummy C file referencing all the functions you need, either
with a direct call or through an initialized function pointer.
</para></listitem>
<listitem><para>Build a dummy LibMain.
</para></listitem>
<listitem><para>Link all the objects with this file+LibMain.
</para></listitem>
<listitem><para>Write a .def.
</para></listitem>
<listitem><para>Link.
</para></listitem>
</orderedlist>
<para>You can use these methods to use MSVC (and many other runtime libs)
with Cygwin development tools.
</para>
<para>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...
</para>
<para>Thanks to Jacob Navia (root at jacob dot remcomp dot fr) for this explanation.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.building-cygwin">
<question><para>How do I build Cygwin on my own?</para></question>
<answer>
<para>First, you need to make sure you have the necessary build tools
installed; you at least need <literal>gcc</literal>, <literal>make</literal>,
and <literal>perl</literal>. If you want to run the tests
<literal>cocom</literal> and <literal>dejagnu</literal> are also required,
and you need to have <literal>CYGWIN=server</literal> set as described at
<ulink url="http://www.cygwin.com/cygwin-ug-net/using-cygserver.html" />.
Next, get the Cygwin source. Ideally, you should check out
what you need from CVS (<ulink url="http://cygwin.com/cvs.html" />). This is the
<emphasis>preferred method</emphasis> for acquiring the sources. Otherwise, you can
install the cygwin source package from the distribution.
</para>
<para>If you are trying to duplicate a cygwin release then you should just
download the corresponding source package and use "tar xjf" to unpack
it. This will unpack the sources into a directory named cygwin-x.y.z-n,
where x.y.z-n correspond to the version numbering of the tar.bz2
package.
</para>
<screen>
tar xjf cygwin-1.5.12-1-src.tar.bz2
cd cygwin-1.5.12-1
</screen>
<para>You <emphasis>must</emphasis> build cygwin in a separate directory from the source,
so create something like a <literal>build/</literal> directory. You will also want
to install to a temporary location:
</para>
<screen>
mkdir build
mkdir /install
cd build
(../configure --prefix=/install -v; make) >& make.out
make install > install.log 2>&1
</screen>
<para>Normally, this procedure ignores errors in building the documentation.
which requires the <literal>docbook-xml42</literal>, <literal>docbook-xsl</literal>, and
<literal>xmlto</literal> packages. For more information on building the
documentation, see the README included in the <literal>cygwin-doc</literal> package.
</para>
<para>To check a cygwin1.dll, run "make check" in the winsup/testsuite
directory. If that works, install everything <emphasis>except</emphasis> 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 the correct
place. Then start up a bash window, or run a cygwin program from the
Windows command prompt, and see what happens.
</para>
<para>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. Remove all but one.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.debugging-cygwin">
<question><para>I may have found a bug in Cygwin, how can I debug it (the symbols in gdb look funny)?</para></question>
<answer>
<para>Debugging symbols are stripped from distibuted Cygwin binaries, so any
symbols that you see in gdb are basically meaningless. It is also a good
idea to use the latest code in case the bug has been fixed, so we
recommend trying the latest snapshot from
<ulink url="http://cygwin.com/snapshots/" /> or building the DLL from CVS.
</para>
<para>To build a debugging version of the Cygwin DLL, you will need to follow
the instructions at <ulink url="http://cygwin.com/faq/faq-nochunks.html#faq.programming.building-cygwin" />.
You can also contact the mailing list for pointers (a simple test case that
demonstrates the bug is always welcome).
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.compiling-unsupported">
<question><para>How can I compile Cygwin for an unsupported platform (PowerPC, Alpha, ARM, Itanium)?</para></question>
<answer>
<para>Unfortunately, this will be difficult. Exception handling and signals
support semantics and args have been designed for x86 so you would need
to write specific support for your platform. We don't know of any other
incompatibilities. Please send us patches if you do this work!
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.adjusting-heap">
<question><para>How can I adjust the heap/stack size of an application?</para></question>
<answer>
<para>If you need to change the maximum amount of memory available to Cygwin, see
<ulink url="http://cygwin.com/cygwin-ug-net/setup-maxmem.html">http://cygwin.com/cygwin-ug-net/setup-maxmem.html</ulink>. Otherwise,
just pass heap/stack linker arguments to gcc. To create foo.exe with
a heap size of 1024 and a stack size of 4096, you would invoke
gcc as:
</para>
<para><literal>gcc -Wl,--heap,1024,--stack,4096 -o foo foo.c</literal>
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.dll-cygcheck">
<question><para>How can I find out which DLLs are needed by an executable?</para></question>
<answer>
<para><literal>objdump -p</literal> provides this information, but is rather verbose.
</para>
<para><literal>cygcheck</literal> will do this much more concisely, and operates
recursively, provided the command is in your path.
</para>
<para>Note there is currently a bug in cygcheck in that it will not report
on a program in a Windows system dir (e.g., C:\Windows or C:\WINNT) even
if it's in your path. To work around this, supply the full Win32 path
to the executable, including the .exe extension:
</para>
<screen>
cygcheck c:\\winnt\\system32\\cmd.exe
</screen>
<para>(Note the windows path separator must be escaped if this is typed in
bash.)
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.dll-building">
<question><para>How do I build a DLL?</para></question>
<answer>
<para>There's documentation that explains the process in the Cygwin User's
Guide here: <ulink url="http://cygwin.com/cygwin-ug-net/dll.html">http://cygwin.com/cygwin-ug-net/dll.html</ulink>
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.breakpoint">
<question><para>How can I set a breakpoint at MainCRTStartup?</para></question>
<answer>
<para><emphasis role='bold'>(Please note: This section has not yet been updated for the latest net release.)</emphasis>
</para>
<para>Set a breakpoint at *0x401000 in gdb and then run the program in
question.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.dll-relocatable">
<question><para>How can I build a relocatable dll?</para></question>
<answer>
<para><emphasis role='bold'>(Please note: This section has not yet been updated for the latest net release. However, there was a discussion on the cygwin mailing list recently that addresses this issue. Read <ulink url="http://cygwin.com/ml/cygwin/2000-06/msg00688.html">http://cygwin.com/ml/cygwin/2000-06/msg00688.html</ulink> and related messages.)</emphasis>
</para>
<para>You must execute the following sequence of five commands, in this
order:
</para>
<screen>
$(LD) -s --base-file BASEFILE --dll -o DLLNAME OBJS LIBS -e ENTRY
$(DLLTOOL) --as=$(AS) --dllname DLLNAME --def DEFFILE \
--base-file BASEFILE --output-exp EXPFILE
$(LD) -s --base-file BASEFILE EXPFILE -dll -o DLLNAME OBJS LIBS -e ENTRY
$(DLLTOOL) --as=$(AS) --dllname DLLNAME --def DEFFILE \
--base-file BASEFILE --output-exp EXPFILE
$(LD) EXPFILE --dll -o DLLNAME OBJS LIBS -e ENTRY
</screen>
<para>In this example, $(LD) is the linker, ld.
</para>
<para>$(DLLTOOL) is dlltool.
</para>
<para>$(AS) is the assembler, as.
</para>
<para>DLLNAME is the name of the DLL you want to create, e.g., tcl80.dll.
</para>
<para>OBJS is the list of object files you want to put into the DLL.
</para>
<para>LIBS is the list of libraries you want to link the DLL against. For
example, you may or may not want -lcygwin. You may want -lkernel32.
Tcl links against -lcygwin -ladvapi32 -luser32 -lgdi32 -lcomdlg32
-lkernel32.
</para>
<para>DEFFILE is the name of your definitions file. A simple DEFFILE would
consist of ``EXPORTS'' followed by a list of all symbols which should
be exported from the DLL. Each symbol should be on a line by itself.
Other programs will only be able to access the listed symbols.
</para>
<para>BASEFILE is a temporary file that is used during this five stage
process, e.g., tcl.base.
</para>
<para>EXPFILE is another temporary file, e.g., tcl.exp.
</para>
<para>ENTRY is the name of the function which you want to use as the entry
point. This function should be defined using the WINAPI attribute,
and should take three arguments:
int WINAPI startup (HINSTANCE, DWORD, LPVOID)
</para>
<para>This means that the actual symbol name will have an appended @12, so if
your entry point really is named <literal>startup</literal>, the string you should
use for ENTRY in the above examples would be <literal>startup@12</literal>.
</para>
<para>If your DLL calls any Cygwin API functions, the entry function will need
to initialize the Cygwin impure pointer. You can do that by declaring
a global variable <literal>_impure_ptr</literal>, and then initializing it in the
entry function. Be careful not to export the global variable
<literal>_impure_ptr</literal> from your DLL; that is, do not put it in DEFFILE.
</para>
<screen>
/* This is a global variable. */
struct _reent *_impure_ptr;
extern struct _reent *__imp_reent_data;
int entry (HINSTANT hinst, DWORD reason, LPVOID reserved)
{
_impure_ptr = __imp_reent_data;
/* Whatever else you want to do. */
}
</screen>
<para>You may put an optional `--subsystem windows' on the $(LD) lines. The
Tcl build does this, but I admit that I no longer remember whether
this is important. Note that if you specify a --subsytem <x> flag to ld,
the -e entry must come after the subsystem flag, since the subsystem flag
sets a different default entry point.
</para>
<para>You may put an optional `--image-base BASEADDR' on the $(LD) lines.
This will set the default image base. Programs using this DLL will
start up a bit faster if each DLL occupies a different portion of the
address space. Each DLL starts at the image base, and continues for
whatever size it occupies.
</para>
<para>Now that you've built your DLL, you may want to build a library so
that other programs can link against it. This is not required: you
could always use the DLL via LoadLibrary. However, if you want to be
able to link directly against the DLL, you need to create a library.
Do that like this:
</para>
<para>$(DLLTOOL) --as=$(AS) --dllname DLLNAME --def DEFFILE --output-lib LIBFILE
</para>
<para>$(DLLTOOL), $(AS), DLLNAME, and DEFFILE are the same as above. Make
sure you use the same DLLNAME and DEFFILE, or things won't work right.
</para>
<para>LIBFILE is the name of the library you want to create, e.g.,
libtcl80.a. You can then link against that library using something
like -ltcl80 in your linker command.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.debug">
<question><para>How can I debug what's going on?</para></question>
<answer>
<para>You can debug your application using <literal>gdb</literal>. Make sure you
compile it with the -g flag! If your application calls functions in
MS DLLs, gdb will complain about not being able to load debug information
for them when you run your program. This is normal since these DLLs
don't contain debugging information (and even if they did, that debug
info would not be compatible with gdb).
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.system-trace">
<question><para>Can I use a system trace mechanism instead?</para></question>
<answer>
<para>Yes. You can use the <literal>strace.exe</literal> utility to run other cygwin
programs with various debug and trace messages enabled. For information
on using <literal>strace</literal>, see the Cygwin User's Guide or the file
<literal>winsup/utils/utils.sgml</literal>.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.gdb-signals">
<question><para>Why doesn't gdb handle signals?</para></question>
<answer>
<para>Unfortunately, there is only minimal signal handling support in gdb
currently. Signal handling only works with Windows-type signals.
SIGINT may work, SIGFPE may work, SIGSEGV definitely does. You cannot
'stop', 'print' or 'nopass' signals like SIGUSR1 or SIGHUP to the
process being debugged.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.linker">
<question><para>The linker complains that it can't find something.</para></question>
<answer>
<para>A common error is to put the library on the command line before
the thing that needs things from it.
</para>
<para>This is wrong <literal>gcc -lstdc++ hello.cc</literal>.
This is right <literal>gcc hello.cc -lstdc++</literal>.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.stat64">
<question><para>Why do I get an error using <literal>struct stat64</literal>?</para></question>
<answer>
<para><literal>struct stat64</literal> is not used in Cygwin, just
use <literal>struct stat</literal>.</para>
</answer></qandaentry>
<qandaentry id="faq.programming.undeclared-functions">
<question><para>I use a function I know is in the API, but I still get a link error.</para></question>
<answer>
<para>The function probably isn't declared in the header files, or
the UNICODE stuff for it isn't filled in.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.libc">
<question><para>Can you make DLLs that are linked against libc ?</para></question>
<answer>
<para>Yes.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.malloc-h">
<question><para>Where is malloc.h?</para></question>
<answer>
<para><emphasis role='bold'>(Please note: This section has not yet been updated for the latest net release.)</emphasis>
</para>
<para>Include stdlib.h instead of malloc.h.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.own-malloc">
<question><para>Can I use my own malloc?</para></question>
<answer>
<para>If you define a function called <literal>malloc</literal> in your own code, and link
with the DLL, the DLL <emphasis>will</emphasis> call your <literal>malloc</literal>. Needless to
say, you will run into serious problems if your malloc is buggy.
</para>
<para>If you run any programs from the DOS command prompt, rather than from in
bash, the DLL will try and expand the wildcards on the command line.
This process uses <literal>malloc</literal> <emphasis>before</emphasis> your main line is started.
If you have written your own <literal>malloc</literal> to need some initialization
to occur after <literal>main</literal> is called, then this will surely break.
</para>
<para>Moreover, there is an outstanding issue with <literal>_malloc_r</literal> in
<literal>newlib</literal>. This re-entrant version of <literal>malloc</literal> will be called
directly from within <literal>newlib</literal>, by-passing your custom version, and
is probably incompatible with it. But it may not be possible to replace
<literal>_malloc_r</literal> too, because <literal>cygwin1.dll</literal> does not export it and
Cygwin does not expect your program to replace it. This is really a
newlib issue, but we are open to suggestions on how to deal with it.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.msvc-gcc-objects">
<question><para>Can I mix objects compiled with msvc++ and gcc?</para></question>
<answer>
<para>Yes, but only if you are combining C object files. MSVC C++ uses a
different mangling scheme than GNU C++, so you will have difficulties
combining C++ objects.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.gdb-msvc">
<question><para>Can I use the gdb debugger to debug programs built by VC++?</para></question>
<answer>
<para>No, not for full (high level source language) debugging.
The Microsoft compilers generate a different type of debugging
symbol information, which gdb does not understand.
</para>
<para>However, the low-level (assembly-type) symbols generated by
Microsoft compilers are coff, which gdb DOES understand.
Therefore you should at least be able to see all of your
global symbols; you just won't have any information about
data types, line numbers, local variables etc.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.x86-assembly">
<question><para>Where can I find info on x86 assembly?</para></question>
<answer>
<para>CPU reference manuals for Intel's current chips are available in
downloadable PDF form on Intel's web site:
</para>
<para><ulink url="http://developer.intel.com/design/pro/manuals/">http://developer.intel.com/design/pro/manuals/</ulink>
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.make-scripts">
<question><para>Shell scripts aren't running properly from my makefiles?</para></question>
<answer>
<para>If your scripts are in the current directory, you must have <literal>.</literal>
(dot) in your $PATH. (It is not normally there by default.) Otherwise,
you would need to add /bin/sh in front of each and every shell script
invoked in your Makefiles.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.preprocessor">
<question><para>What preprocessor do I need to know about?</para></question>
<answer>
<para>We use _WIN32 to signify access to the Win32 API and __CYGWIN__ for
access to the Cygwin environment provided by the dll.
</para>
<para>We chose _WIN32 because this is what Microsoft defines in VC++ and
we thought it would be a good idea for compatibility with VC++ code
to follow their example. We use _MFC_VER to indicate code that should
be compiled with VC++.
</para>
<para>_WIN32 is only defined when you use either the -mno-cygwin or -mwin32
gcc command line options. This is because Cygwin is supposed to be a
Unix emulation environment and defining _WIN32 confuses some programs
which think that they have to make special concessions for a Windows
environment which Cygwin handles automatically.
</para>
<para>Note that using -mno-cygwin replaces __CYGWIN__ with __MINGW32__ as to
tell which compiler (or settings) you're running.
Check this out in detail by running, for example
</para>
<screen>
$ gcc -dM -E -xc /dev/null >gcc.txt
$ gcc -mno-cygwin -dM -E -xc /dev/null >gcc-mno-cygwin.txt
$ gcc -mwin32 -dM -E -xc /dev/null >gcc-mwin32.txt
</screen>
<para>Then use the diff and grep utilities to check
what the difference is.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.unix-gui">
<question><para>How should I port my Unix GUI to Windows?</para></question>
<answer>
<para>There are two basic strategies for porting Unix GUIs to Windows.
</para>
<para>The first is to use a portable graphics library such as tcl/tk, X11, or
V (and others?). Typically, you will end up with a GUI on Windows that
requires some runtime support. With tcl/tk, you'll want to include the
necessary library files and the tcl/tk DLLs. In the case of X11, you'll
need everyone using your program to have an X11 server installed.
</para>
<para>The second method is to rewrite your GUI using Win32 API calls (or MFC
with VC++). If your program is written in a fairly modular fashion, you
may still want to use Cygwin if your program contains a lot of shared
(non-GUI-related) code. That way you still gain some of the portability
advantages inherent in using Cygwin.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.djgpp">
<question><para>Why not use DJGPP ?</para></question>
<answer>
<para>DJGPP is a similar idea, but for DOS instead of Win32. DJGPP uses a
"DOS extender" to provide a more reasonable operating interface for its
applications. The Cygwin toolset doesn't have to do this since all of
the applications are native WIN32. Applications compiled with the
Cygwin tools can access the Win32 API functions, so you can write
programs which use the Windows GUI.
</para>
<para>You can get more info on DJGPP by following
<ulink url="http://www.delorie.com/">http://www.delorie.com/</ulink>.
</para></answer></qandaentry>
|