-
Notifications
You must be signed in to change notification settings - Fork 4
/
Copy pathFAQ
1130 lines (923 loc) · 50.8 KB
/
FAQ
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
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
GCC Frequently Asked Questions
The latest version of this document is always available at
[1]http://www.gnu.org/software/gcc/faq.html.
This FAQ tries to answer specific questions concerning GCC. For
general information regarding C, C++, resp. Fortran please check the
[2]comp.lang.c FAQ, [3]comp.lang.c++ FAQ, [4]comp.std.c++ FAQ, and the
[5]Fortran Information page.
_________________________________________________________________
Questions
1. [6]General information
1. [7]What is the relationship between GCC and EGCS
2. [8]What is the relationship between GCC and Cygnus
3. [9]What is an open development model?
4. [10]How to report bugs
5. [11]How do I get a bug fixed or a feature added?
2. [12]Installation
1. [13]Problems building the Fortran compiler
2. [14]How to install multiple versions of GCC
3. [15]Dynamic linker is unable to find GCC libraries
4. [16]libstdc++/libio tests fail badly with --enable-shared
5. [17]GCC can not find GNU as/GNU ld
6. [18]cpp: Usage:... Error
3. [19]Testsuite problems
1. [20]Why is there no testsuite in GCC 2.95
2. [21]Unable to run the testsuite
3. [22]How do I pass flags like -fnew-abi to the testsuite?
4. [23]How can I run the test suite with multiple options?
4. [24]Platform-specific issues
1. [25]Problems with exception handling on x86 platforms
2. [26]Problems with Invalid `asm' statements
3. [27]Building Linux kernels
4. [28]How do I compile X11 headers with g++
5. [29]How to build a cross compiler
5. [30]Bugs and Non-Bugs
1. [31]FD_ZERO macro
2. [32]Octave 2.0.13 does not compile
3. [33]Why can't I initialize a static variable with stdin?
4. [34]Why can't I use #if here?
6. [35]Miscellaneous
1. [36]Virtual memory exhausted
2. [37]Snapshots, how, when, why
3. [38]Friend Templates
4. [39]Where to find libg++
5. [40]Why do I need autoconf, bison, xgettext, automake, etc
6. [41]Problems debugging GCC code
7. [42]Conflicts when using cvs update
8. [43]Using GCC with GNAT/Ada
9. [44]Using GCC with GNU Pascal
10. [45]Using CVS to download snapshots
11. [46]Why can't I build a shared library?
12. [47]Dealing with spam on the lists
13. [48]How to work around too long C++ symbol names?
(-fsquangle)
14. [49]When building from CVS sources, I see 'gperf: invalid
option -- F', even with the most current version of gperf.
15. [50]When building C++, the linker says my constructors,
destructors or virtual tables are undefined, but I defined
them
16. [51]What is libstdc++-v3 and how can I use it with g++?
_________________________________________________________________
General information
What is the relationship between GCC and EGCS
In 1990/1991 gcc version 1 had reached a point of stability. For the
targets it could support, it worked well. It had limitations inherent
in its design that would be difficult to resolve, so a major effort
was made to resolve those limitiations and gcc version 2 was the
result.
When we had gcc2 in a useful state, development efforts on gcc1
stopped and we all concentrated on making gcc2 better than gcc1 could
ever be. This is the kind of step forward we wanted to make with the
EGCS project when it was formed in 1997.
In April 1999 the Free Software Foundation officially halted
development on the gcc2 compiler and appointed the EGCS project as the
official GCC maintainers.
We are in the process of merging GCC and EGCS, which will take some
time. The net result will be a single project which will carry forward
GCC development under the ultimate control of the [52]GCC Steering
Committee.
_________________________________________________________________
What is the relationship between GCC and Cygnus
It is a common mis-conception that Cygnus controls either directly or
indirectly GCC.
While Cygnus does donate hardware, network connections, code and
developer time to GCC development, Cygnus does not control GCC.
Overall control of GCC is in the hands of the [53]GCC Steering
Committee which includes people from a variety of different
organizations and backgrounds. The purpose of the steering committee
is to make decisions in the best interest of GCC and to help ensure
that no individual or company has control over the project.
To summarize, Cygnus contributes to GCCproject, but does not exert a
controlling influence over GCC.
_________________________________________________________________
What is an open development model?
With GCC, we are going to try a bazaar style[54][1] approach to its
development: We make snapshots publicly available to anyone who wants
to try them; we're going to welcome anyone to join the development
mailing list. All of the discussions on the development mailing list
are available via the web. We're going to be making releases with a
much higher frequency than they have been made in the past.
In addition to weekly snapshots of the GCC development sources, we
have the sources readable from a CVS server by anyone. Furthermore we
are using remote CVS to allow remote maintainers write access to the
sources.
There have been many potential gcc developers who were not able to
participate in gcc development in the past. We want these people to
help in any way they can; we ultimately want GCC to be the best
compiler in the world.
A compiler is a complicated piece of software, there will still be
strong central maintainers who will reject patches, who will demand
documentation of implementations, and who will keep the level of
quality as high as it is today. Code that could use wider testing may
be integrated--code that is simply ill-conceived won't be.
GCC is not the first piece of software to use this open development
process; FreeBSD, the Emacs lisp repository, and the Linux kernel are
a few examples of the bazaar style of development.
With GCC, we will be adding new features and optimizations at a rate
that has not been done since the creation of gcc2; these additions
will inevitably have a temporarily destabilizing effect. With the help
of developers working together with this bazaar style development, the
resulting stability and quality levels will be better than we've had
before.
_[1]_ We've been discussing different development models a lot over
the past few months. The paper which started all of this introduced
two terms: A _cathedral_ development model versus a _bazaar_
development model. The paper is written by Eric S. Raymond, it is
called ``[55]The Cathedral and the Bazaar''. The paper is a useful
starting point for discussions.
_________________________________________________________________
How to report bugs
There are complete instructions in the [56]gcc info manual, section
Bugs. The manual can also be read using `_M-x info_' in Emacs, or if
the GNU info program is installed on your system by `info --node
"(gcc)Bugs"'. Or see the file [57]BUGS included with the GCC source
code.
Before you report a bug for the _C++ compiler_, please check the
[58]list of well-known bugs. If you want to report a bug with _egcs
1.0.x_ or _egcs 1.1.x_, we strongly recommend upgrading to the current
release first.
In short, if GCC says Internal compiler error (or any other error that
you'd like us to be able to reproduce, for that matter), please mail a
bug report to [59][email protected] or [60][email protected]
including:
* The GCC version
* The system type
* All options you passed to the compiler
* Preprocessed output of the source file that caused the compiler
error
All this can normally be accomplished by mailing the command line, the
output of the command, and the resulting `_your-file_.i' for C, or
`_your-file_.ii' for C++, corresponding to:
gcc -v --save-temps _all-your-options_ _your-file_.c
Typically the CPP output (extension .i for C or .ii for C++) will be
large, so please compress the resulting file with one of the popular
compression programs such as bzip2, gzip, zip, pkzip or compress (in
decreasing order of preference). Use maximum compression (-9) if
available. Please include the compressed CPP output in your bug
report.
Since we're supposed to be able to re-create the assembly output
(extension .s), you usually don't have to include it in the bug
report, although you may want to post parts of it to point out
assembly code you consider to be wrong.
Whether to use MIME attachments or uuencode is up to you. In any case,
make sure the compiler command line, version and error output are in
plain text, so that we don't have to decode the bug report in order to
tell who should take care of it. A meaningful subject indicating
language and platform also helps.
The gcc lists have message size limits (100 kbytes) and bug reports
over those limits will currently be bounced. We're trying to find a
way to allow larger bug reports to be posted, but this is currently
impossible (unless you use MIME partials, which most people are unable
to handle anyway, so you'd better avoid them for now). So, although we
prefer to have complete bug reports archived, if you cannot reduce the
bug report below the limit, please make it available for ftp or http
and post the URL. Another alternative is to break the preprocessed
output in multiple files (using split, for example) and post them in
separate messages, but we prefer to have self-contained bug reports in
single messages.
If you fail to supply enough information for a bug report to be
reproduced, someone will probably ask you to post additional
information (or just ignore your bug report, if they're in a bad day,
so try to get it right on the first posting :-). In this case, please
post the additional information to the bug reporting mailing list, not
just to the person who requested it, unless explicitly told so. If
possible, please include in this follow-up all the information you had
supplied in the incomplete bug report (including the preprocessor
output), so that the new bug report is self-contained.
_________________________________________________________________
How do I get a bug fixed or a feature added?
There are lots of ways to get something fixed. The list below may be
incomplete, but it covers many of the common cases. These are listed
roughly in order of increasing difficulty for the average GCC user,
meaning someone who is not skilled in the internals of GCC, and where
difficulty is measured in terms of the time required to fix the bug.
No alternative is better than any other; each has it's benefits and
disadvantages.
* Hire someone to fix it for you. There are various companies and
individuals providing support for GCC. This alternative costs
money, but is relatively likely to get results.
* Report the problem to gcc-bugs and hope that someone will be kind
enough to fix it for you. While this is certainly possible, and
often happens, there is no guarantee that it will. You should not
expect the same response from gcc-bugs that you would see from a
commercial support organization since the people who read
gcc-bugs, if they choose to help you, will be volunteering their
time. This alternative will work best if you follow the directions
on [61]submitting bugreports.
* Fix it yourself. This alternative will probably bring results, if
you work hard enough, but will probably take a lot of time, and,
depending on the quality of your work and the perceived benefits
of your changes, your code may or may not ever make it into an
official release of GCC.
_________________________________________________________________
Installation
Problems building the Fortran compiler
The Fortran front end can not be built with most vendor compilers; it
must be built with gcc. As a result, you may get an error if you do
not follow the install instructions carefully.
In particular, instead of using "make" to build GCC, you should use
"make bootstrap" if you are building a native compiler or "make cross"
if you are building a cross compiler.
It has also been reported that the Fortran compiler can not be built
on Red Hat 4.X GNU/Linux for the Alpha. Fixing this may require
upgrading binutils or to Red Hat 5.0; we'll provide more information
as it becomes available.
_________________________________________________________________
How to install multiple versions of gcc
It may be desirable to install multiple versions of the compiler on
the same system. This can be done by using different prefix paths at
configure time and a few symlinks.
Basically, configure the two compilers with different --prefix
options, then build and install each compiler. Assume you want "gcc"
to be the latest compiler and available in /usr/local/bin; also assume
that you want "gcc2" to be the older gcc2 compiler and also available
in /usr/local/bin.
The easiest way to do this is to configure the new GCC with
--prefix=/usr/local/gcc and the older gcc2 with
--prefix=/usr/local/gcc2. Build and install both compilers. Then make
a symlink from /usr/local/bin/gcc to /usr/local/gcc/bin/gcc and from
/usr/local/bin/gcc2 to /usr/local/gcc2/bin/gcc. Create similar links
for the "g++", "c++" and "g77" compiler drivers.
An alternative to using symlinks is to configure with a
--program-transform-name option. This option specifies a sed command
to process installed program names with. Using it you can, for
instance, have all the new GCC programs installed as "new-gcc" and the
like. You will still have to specify different --prefix options for
new GCC and old GCC, because it is only the executable program names
that are transformed. The difference is that you (as administrator) do
not have to set up symlinks, but must specify additional directories
in your (as a user) PATH. A complication with --program-transform-name
is that the sed command invariably contains characters significant to
the shell, and these have to be escaped correctly, also it is not
possible to use "^" or "$" in the command. Here is the option to
prefix "new-" to the new GCC installed programs
"--program-transform-name='s,\\\\(.*\\\\),new-\\\\1,'". With the above
--prefix option, that will install the new GCC programs into
/usr/local/gcc/bin with names prefixed by "new-". You can use
--program-transform-name if you have multiple versions of GCC, and
wish to be sure about which version you are invoking.
If you use --prefix, GCC may have difficulty locating a GNU assembler
or linker on your system, [62]GCC can not find GNU as/GNU ld explains
how to deal with this.
_________________________________________________________________
Dynamic linker is unable to find GCC libraries
This problem manifests itself by programs not finding shared libraries
they depend on when the programs are started. Note this problem often
manifests itself with failures in the libio/libstdc++ tests after
configuring with --enable-shared and building GCC.
GCC does not specify a runpath so that the dynamic linker can find
dynamic libraries at runtime.
The short explanation is that if you always pass a -R option to the
linker, then your programs become dependent on directories which may
be NFS mounted, and programs may hang unnecessarily when an NFS server
goes down.
The problem is not programs that do require the directories; those
programs are going to hang no matter what you do. The problem is
programs that do not require the directories.
SunOS effectively always passed a -R option for every -L option; this
was a bad idea, and so it was removed for Solaris. We should not
recreate it.
However, if you feel you really need such an option to be passed
automatically to the linker, you may add it to the gcc specs file.
This file can be found in the same directory that contains cc1 (run
gcc -print-prog-name=cc1 to find it). You may add linker flags such as
-R or -rpath, depending on platform and linker, to the *link or *lib
specs.
Another alterative is to install a wrapper script around gcc, g++ or
ld that adds the appropriate directory to the environment variable
LD_RUN_PATH or equivalent (again, it's platform-dependent).
Yet another option, that works on a few platforms, is to hard-code the
full pathname of the library into its soname. This can only be
accomplished by modifying the appropriate .ml file within
libstdc++/config (and also libg++/config, if you are building libg++),
so that $(libdir)/ appears just before the library name in -soname or
-h options.
_________________________________________________________________
GCC can not find GNU as/GNU ld
GCC searches the PATH for an assembler and a loader, but it only does
so after searching a directory list hard-coded in the gcc executables.
Since, on most platforms, the hard-coded list includes directories in
which the system asembler and loader can be found, you may have to
take one of the following actions to arrange that gcc uses the GNU
versions of those programs.
To ensure that GCC finds the GNU assembler (the GNU loader), which are
required by [63]some configurations, you should configure these with
the same --prefix option as you used for GCC. Then build & install GNU
as (GNU ld) and proceed with building GCC.
Another alternative is to create links to GNU as and ld in any of the
directories printed by the command `gcc -print-search-dirs | grep
'^programs:''. The link to `ld' should be named `real-ld' if `ld'
already exists. If such links do not exist while you're compiling GCC,
you may have to create them in the build directories too, within the
gcc directory _and_ in all the gcc/stage* subdirectories.
GCC 2.95 allows you to specify the full pathname of the assembler and
the linker to use. The configure flags are `--with-as=/path/to/as' and
`--with-ld=/path/to/ld'. GCC will try to use these pathnames before
looking for `as' or `(real-)ld' in the standard search dirs. If, at
configure-time, the specified programs are found to be GNU utilities,
`--with-gnu-as' and `--with-gnu-ld' need not be used; these flags will
be auto-detected. One drawback of this option is that it won't allow
you to override the search path for assembler and linker with
command-line options -B/path/ if the specified filenames exist.
_________________________________________________________________
cpp: Usage:... Error
If you get an error like this when building GCC (particularly when
building __mulsi3), then you likely have a problem with your
environment variables.
cpp: Usage: /usr/lib/gcc-lib/i586-unknown-linux-gnulibc1/2.7.2.3/cpp
[switches] input output
First look for an explicit '.' in either LIBRARY_PATH or
GCC_EXEC_PREFIX from your environment. If you do not find an explicit
'.', look for an empty pathname in those variables. Note that ':' at
either the start or end of these variables is an implicit '.' and will
cause problems.
Also note '::' in these paths will also cause similar problems.
_________________________________________________________________
Testsuite problems
Why is there no testsuite in GCC 2.95
The GCC testsuite is not included in the GCC 2.95 release due to the
uncertain copyright status of some tests.
The GCC team will be reviewing the entire testsuite to find and remove
any tests with uncertain copyright status. Once those tests are
removed from the testsuite, the testsuite as a whole will be
copyrighted under the terms of the GPL and included in future GCC
releases.
It is believed that only a few tests have uncertain copyright status
and thus only a few tests will need to be removed from the testsuite.
_________________________________________________________________
Unable to run the testsuite
If you get a message about unable to find "standard.exp" when trying
to run the GCC testsuites, then your dejagnu is too old to run the GCC
tests. You will need to get a newer version of dejagnu; we've made a
[64]dejagnu snapshot available until a new version of dejagnu can be
released.
_________________________________________________________________
How do I pass flags like -fnew-abi to the testsuite?
If you invoke runtest directly, you can use the --tool_opts option,
e.g:
runtest --tool_opts "-fnew-abi -fno-honor-std" <other options>
Or, if you use make check you can use the make variable RUNTESTFLAGS,
e.g:
make RUNTESTFLAGS='--tool_opts "-fnew-abi -fno-honor-std"' check-g++
_________________________________________________________________
How can I run the test suite with multiple options?
If you invoke runtest directly, you can use the --target_board option,
e.g:
runtest --target_board "unix{-fPIC,-fpic,}" <other options>
Or, if you use make check you can use the make variable RUNTESTFLAGS,
e.g:
make RUNTESTFLAGS='--target_board "unix{-fPIC,-fpic,}"' check-gcc
Either of these examples will run the tests three times. Once with
-fPIC, once with -fpic, and once with no additional flags.
This technique is particularly useful on multilibbed targets.
_________________________________________________________________
Platform-specific issues
Please read the [65]host/target specific installation notes, too.
Problems with exception handling on x86 platforms
If you are using the GNU assembler (aka gas) on an x86 platform and
exception handling is not working correctly, then odds are you're
using a buggy assembler. Releases of binutils prior to 2.9 are known
to assemble exception handling code incorrectly.
We recommend binutils-2.9.1 or newer. Some post-2.9.1 snapshots of
binutils fix some subtle bugs, particularly on x86 and alpha. They are
available at [66]ftp://tsx-11.mit.edu/pub/linux/packages/GCC/. The
2.9.1.0.15 snapshot is known to work fine on those platforms; other
than that, be aware that snapshots are in general untested and may not
work (or even build). Use them at your own risk.
_________________________________________________________________
Problems with invalid `asm' statements
Previous releases of GCC (for example, GCC 2.7.2 or EGCS 1.1.2) did
not detect as invalid a clobber specifier that clobbered an operand.
Instead, it could spuriously and silently generate incorrect code for
certain non-obvious cases of source code. Even more unfortunately, the
manual (Using and Porting GCC, section Extended Asm, see the [67]bug
report entry) did not explicitly say that it was invalid to specify
clobber registers that were destined to overlap operands; it could
arguably be interpreted that it was correct to clobber an input
operand to mark it as not holding a usable value after the asm.
For the general case, there is no way to tell whether a specified
clobber is _intended_ to overlap with a specific (input) operand or is
a program error, where the choice of actual register for operands
failed to _avoid_ the clobbered register. Such unavoidable overlap is
detected by versions GCC 2.95 and newer, and flagged as an error
rather than accepted. An error message is given, such as:
foo.c: In function `foo':
foo.c:7: Invalid `asm' statement:
foo.c:7: fixed or forbidden register 0 (ax) was spilled for class AREG.
Unfortunately, a lot of existing software, for example the [68]Linux
kernel version 2.0.35 for the Intel x86, has constructs where input
operands are marked as clobbered.
The manual now describes how to write constructs with operands that
are modified by the construct, but not actually used. To write an asm
which modifies an input operand but does not output anything usable,
specify that operand as an _output operand_ outputting to an _unused
dummy variable_.
In the following example for the x86 architecture (taken from the
Linux 2.0.35 kernel -- include/asm-i386/delay.h), the register-class
constraint "a" denotes a register class containing the single register
"ax" (aka. "eax"). It is therefore invalid to clobber "ax"; this
operand has to be specified as an output as well as an input. The
following code is therefore _invalid_:
extern __inline__ void
__delay (int loops)
{
__asm__ __volatile__
(".align 2,0x90\n1:\tdecl %0\n\tjns 1b"
: /* no outputs */
: "a" (loops)
: "ax");
}
It could be argued that since the register class for "a" contains only
a single register, this could be detected as an "obvious" intended
clobber of the input operand. While that is feasible, it opens up for
further "obvious" cases, where the level of obviousness changes from
person to person. As there is a correct way to write such asm
constructs, this obviousness-detection is not needed other than for
reasons of compatibility with an existing code-base, and that code
base can be corrected.
This corrected and clobber-less version, is _valid_ for GCC 2.95 as
well as for previous versions of GCC and EGCS:
extern __inline__ void
__delay (int loops)
{
int dummy;
__asm__ __volatile__
(".align 2,0x90\n1:\tdecl %0\n\tjns 1b"
: "=a" (dummy)
: "0" (loops));
}
Note that the asm construct now has an output operand, but it is
unused. Normally asm constructs with only unused output operands may
be removed by gcc, unless marked volatile as above.
_________________________________________________________________
Building Linux kernels
The linux kernel violates certain aliasing rules specified in the
ANSI/ISO standard. Starting with GCC 2.95, the gcc optimizer by
default relies on these rules to produce more efficient code and thus
will produce malfunctioning kernels. To work around this problem, the
flag -fno-strict-aliasing must be added to the CFLAGS variable in the
main kernel Makefile.
If you try to build a 2.0.x kernel for Intel machines with any
compiler other than GCC 2.7.2, then you are on your own. The 2.0.x
kernels are to be built only with gcc 2.7.2. They use certain asm
constructs which are incorrect, but (by accident) happen to work with
gcc 2.7.2. If you insist on building 2.0.x kernels with egcs, you may
be interested in this [69]patch which fixes some of the asm problems.
You will also want to change asm constructs to [70]avoid clobbering
their input operands.
If you installed a recent binutils/gas snapshot on your GNU/Linux
system, you may not be able to build the kernel because objdump does
not understand the "-k" switch. The solution for this problem is to
remove /usr/bin/encaps. (This is an obsolete program that was part of
older binutils distributions; the Linux kernel's Makefile looks for
this program to decide if you have an old or a new binutils. Problems
occur if you installed a new binutils but haven't removed encaps,
because the Makefile thinks you have the old one.)
Finally, you may get errors with the X driver of the form
_X11TransSocketUNIXConnect: Can't connect: errno = 111
This is a kernel bug. The function sys_iopl in
arch/i386/kernel/ioport.c does an illegal hack which used to work but
is now broken since GCC optimizes more aggressively . The newer 2.1.x
kernels already have a fix which should also work in 2.0.32.
_________________________________________________________________
How do I compile X11 headers with g++
When compiling X11 headers with a GCC 2.95 or newer, g++ will complain
that types are missing. These headers assume that omitting the type
means 'int'; this assumption is wrong for C++.
g++ accepts such (illegal) constructs with the option -fpermissive; it
will assume that missing type is 'int' (as defined by the C89
standard).
Since the upcoming C99 standard also obsoletes the implicit type
assumptions, the X11 headers have to get fixed eventually.
_________________________________________________________________
How to build a cross compiler
Building cross compilers is a rather complex undertaking because they
usually need additional software (cross assembler, cross linker,
target libraries, target include files, etc).
We recommend reading the [71]crossgcc FAQ for information about
building cross compilers.
If you have all the pieces available, then `make cross' should build a
cross compiler. `make LANGUAGES="c c++" install' will install the
cross compiler.
Note that if you're trying to build a cross compiler in a tree which
includes binutils-2.8 in addition to GCC, then you're going to need to
make a couple minor tweaks so that the cross assembler, linker and nm
utilities will be found.
binutils-2.8 builds those files as gas.new, ld.new and nm.new; GCC
looks for them using gas-new, ld-new and nm-new, so you may have to
arrange for any symlinks which point to <file>.new to be changed to
<file>-new.
_________________________________________________________________
Bugs and Non-Bugs
Unfortunately, improvements in tools that are widely used are sooner
or later bound to break _something_. Sometimes, the code that breaks
was wrong, and then that code should be fixed, even if it works for
earlier versions of gcc or other compilers. The following problems
with some releases of widely used packages have been identified:
There is a separate [72]list of well-known bugs describing known
deficiencies. Naturally we'd like that list to be of zero length.
To report a bug, see [73]How to report bugs.
_________________________________________________________________
FD_ZERO macro
The FD_ZERO macro in (e.g.) libc-5.4.46 is incorrect. It uses
[74]invalid asm clobbers. The following rewrite by Ulrich Drepper
<[email protected]> should fix this for glibc 2.0:
# define __FD_ZERO(fdsetp) \
do { \
int __d0, __d1; \
__asm__ __volatile__ ("cld; rep; stosl" \
: "=m" (((__fd_mask *) \
(fdsetp))[__FDELT (__FD_SETSIZE)]), \
"=&c" (__d0), "=&D" (__d1) \
: "a" (0), "1" (sizeof (__fd_set) \
/ sizeof (__fd_mask)), \
"2" ((__fd_mask *) (fdsetp)) \
: "memory"); \
} while (0)
_________________________________________________________________
Octave 2.0.13 does not compile
Apparently Octave 2.0.13 uses some C++ features which have been
obsoleted and thus fails to build with EGCS 1.1 and later. This
[75]patch to Octave should fix this.
Octave 2.0.13.96, a test release, has been compiled without patches by
egcs 1.1.2. It is available at
[76]ftp://ftp.che.wisc.edu/pub/octave/test-releases/.
_________________________________________________________________
Why can't I initialize a static variable with stdin?
This has nothing to do with gcc, but people ask us about it a lot.
Code like this:
#include <stdio.h>
FILE *yyin = stdin;
will not compile with GNU libc (Linux libc6), because stdin is not a
constant. This was done deliberately, in order for there to be no
limit on the number of open FILE objects. It is surprising for people
used to traditional Unix C libraries, but it is permitted by the C
standard.
This construct commonly occurs in code generated by old versions of
lex or yacc. We suggest you try regenerating the parser with a current
version of flex or bison, respectively. In your own code, the
appropriate fix is to move the initialization to the beginning of
main.
There is a common misconception that the GCC developers are
responsible for GNU libc. These are in fact two entirely separate
projects. The appropriate place to ask questions relating to GNU libc
is [77][email protected].
_________________________________________________________________
Why can't I use #if here?
Let me guess... you wrote code that looks something like this:
memcpy(dest, src,
#ifdef PLATFORM1
12
#else
24
#endif
);
and you got a whole pile of error messages:
test.c:11: warning: preprocessing directive not recognized within macro arg
test.c:11: warning: preprocessing directive not recognized within macro arg
test.c:11: warning: preprocessing directive not recognized within macro arg
test.c: In function `foo':
test.c:6: undefined or invalid # directive
test.c:8: undefined or invalid # directive
test.c:9: parse error before `24'
test.c:10: undefined or invalid # directive
test.c:11: parse error before `#'
The problem, simply put, is that GCC's preprocessor does not allow you
to put #ifdef (or any other directive) inside the arguments of a
macro. Your C library's string.h happens to define memcpy as a macro -
this is perfectly legitimate. The code therefore will not compile.
We have two good reasons for not allowing directives inside macro
arguments. First, it is not portable. It is "undefined behavior"
according to the C standard; that means different compilers will do
different things with it. Some will give you errors. Some will dump
core. Some will silently mangle your code - you could get the
equivalent of
memcpy(dest, src, 1224);
from the above example. A very few might do what you expected it to.
We therefore feel it is most useful for GCC to reject this construct
immediately so that it is found and fixed.
Second, it is extraordinarily difficult to implement the preprocessor
such that it does what you would expect for every possible directive
found inside a macro argument. The best example is perhaps
#define foo(arg) ... arg ...
foo(blah
#undef foo
blah)
which is impossible to implement in portable C without leaking memory.
Allowing only a subset of directives would be confusing.
It is always possible to rewrite code which uses conditionals inside
macros so that it doesn't. You could write the above example
#ifdef PLATFORM1
memcpy(dest, src, 12);
#else
memcpy(dest, src, 24);
#endif
This is a bit more typing, but I personally think it's better style in
addition to being more portable.
_________________________________________________________________
Miscellaneous
Virtual memory exhausted error
This error means your system ran out of memory; this can happen for
large files, particularly when optimizing. If you're getting this
error you should consider trying to simplify your files or reducing
the optimization level.
Note that using -pedantic or -Wreturn-type can cause an explosion in
the amount of memory needed for template-heavy C++ code, such as code
that uses STL. Also note that -Wall includes -Wreturn-type, so if you
use -Wall you will need to specify -Wno-return-type to turn it off.
_________________________________________________________________
Snapshots, how, when, why
We make snapshots of the GCC sources about once a week; there is no
predetermined schedule. These snapshots are intended to give everyone
access to work in progress. Any given snapshot may generate incorrect
code or even fail to build.
If you plan on downloading and using snapshots, we highly recommend
you subscribe to the GCC mailing lists. See [78]mailing lists on the
main GCC page for instructions on how to subscribe.
When using the diff files to update from older snapshots to newer
snapshots, make sure to use "-E" and "-p" arguments to patch so that
empty files are deleted and full pathnames are provided to patch. If
your version of patch does not support "-E", you'll need to get a
newer version. Also note that you may need autoconf, autoheader and
various other programs if you use diff files to update from one
snapshot to the next.
_________________________________________________________________
Friend Templates
In order to make a specialization of a template function a friend of a
(possibly template) class, you must explicitly state that the friend
function is a template, by appending angle brackets to its name, and
this template function must have been declared already. Here's an
example:
template <typename T> class foo {
friend void bar(foo<T>);
}
The above declaration declares a non-template function named bar, so
it must be explicitly defined for _each_ specialization of foo. A
template definition of bar won't do, because it is unrelated with the
non-template declaration above. So you'd have to end up writing:
void bar(foo<int>) { /* ... */ }
void bar(foo<void>) { /* ... */ }
If you meant bar to be a template function, you should have
forward-declared it as follows. Note that, since the template function
declaration refers to the template class, the template class must be
forward-declared too:
template <typename T>
class foo;
template <typename T>
void bar(foo<T>);
template <typename T>
class foo {
friend void bar<>(foo<T>);
};
template <typename T>
void bar(foo<T>) { /* ... */ }
In this case, the template argument list could be left empty, because
it can be implicitly deduced from the function arguments, but the
angle brackets must be present, otherwise the declaration will be
taken as a non-template function. Furthermore, in some cases, you may
have to explicitly specify the template arguments, to remove
ambiguity.
An error in the last public comment draft of the ANSI/ISO C++ Standard
and the fact that previous releases of gcc would accept such friend
declarations as template declarations has led people to believe that
the forward declaration was not necessary, but, according to the final
version of the Standard, it is.
_________________________________________________________________
Where to find libg++
Many folks have been asking where to find libg++ for GCC. First we
should point out that few programs actually need libg++; most only
need libstdc++/libio which are included in the GCC distribution.
If you do need libg++ you can get a libg++ release that works with GCC
from [79]ftp://egcs.cygnus.com/pub/egcs/infrastructure/. Note that the
2.8.2 snapshot pre-dates the 2.8.1.2 release.
_________________________________________________________________
autoconf, bison, xgettext, automake, etc
If you're using diffs up dated from one snapshot to the next, or if
you're using the CVS repository, you may need several additional
programs to build GCC.
These include, but are not necessarily limited to autoconf, automake,
bison, and xgettext.
This is necessary because neither diff nor cvs keep timestamps
correct. This causes problems for generated files as "make" may think
those generated files are out of date and try to regenerate them.
An easy way to work around this problem is to use the gcc_update
script in the contrib subdirectory of GCC, which handles this
transparently without requiring installation of any additional tools.
(Note: Up to and including GCC 2.95 this script was called egcs_update
.)
When building from diffs or CVS or if you modified some sources, you
may also need to obtain development versions of some GNU tools, as the
production versions do not necessarily handle all features needed to
rebuild GCC.
Autoconf is available from [80]http://sourceware.cygnus.com/autoconf/;
have a look at [81]ftp://egcs.cygnus.com/pub/egcs/infrastructure/ for
the other packages.
_________________________________________________________________
Conflicts when using cvs update
It is not uncommon to get CVS conflict messages for some generated
files when updating your local sources from the CVS repository.
Typically such conflicts occur with bison or autoconf generated files.
As long as you haven't been making modifications to the generated
files or the generator files, it is safe to delete the offending file,
then run cvs update again to get a new copy.
_________________________________________________________________
Problems debugging GCC code
On some systems GCC will produce dwarf debug records by default;
however the gdb-4.16 release may not be able to read such debug
records.
You can either use the argument "-gstabs" instead of "-g" or pick up a
copy of gdb-4.17 to work around the problem.
_________________________________________________________________
Using GCC with GNAT/Ada
The GNU Ada front-end is not currently supported by GCC; however, it
is possible to build the GNAT compiler with a little work.
First, retrieve the gnat-3.10p sources. The sources for the Ada front
end and runtime all live in the "ada" subdirectory. Move that
subdirectory to egcs/gcc/ada.
Second, apply the patch found in egcs/gcc/README.gnat.
Finally, rebuild per the GNAT build instructions.
_________________________________________________________________
Using GCC with GNU Pascal
The [82]GNU Pascal front-end does work with EGCS 1.1 It does not work
with EGCS 1.0.x and the main branch of the CVS repository. A tarball
can be found at
[83]ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/.
_________________________________________________________________
Using CVS to download snapshots
It is possible to checkout specific snapshots with CVS or to check out
the latest snapshot.
We use CVS tags to identify each snapshot we make. Snapshot tags have
the form "egcs_ss_YYYYMMDD". In addition, the latest official snapshot
always has the tag "gcc_latest_snapshot".
_________________________________________________________________
Why can't I build a shared library?
When building a shared library you may get an error message from the
linker like `assert pure-text failed:' or `DP relative code in file'.
This kind of error occurs when you've failed to provide proper flags
to gcc when linking the shared library.
You can get this error even if all the .o files for the shared library
were compiled with the proper PIC option. When building a shared
library, gcc will compile additional code to be included in the
library. That additional code must also be compiled with the proper
PIC option.
Adding the proper PIC option (-fpic or -fPIC) to the link line which
creates the shared library will fix this problem on targets that
support PIC in this manner. For example:
gcc -c -fPIC myfile.c
gcc -shared -o libmyfile.so -fPIC myfile.o
_________________________________________________________________
How to work around too long C++ symbol names? (-fsquangle)
If the standard assembler of your platform can't cope with the large
symbol names that the default g++ name mangling mechanism produces,
your best bet is to use GNU as, from the GNU binutils package.
Unfortunately, GNU as does not support all platforms supported by
egcs, so you may have to use an experimental work-around: the
-fsquangle option, that enables compression of symbol names.
Note that this option is still under development, and subject to
change. Since it modifies the name mangling mechanism, you'll need to
build libstdc++ and any other C++ libraries with this option enabled.
Furthermore, if this option changes its behavior in the future, you'll
have to rebuild them all again. :-(
This option can be enabled by default by initializing
`flag_do_squangling' with `1' in `gcc/cp/decl2.c' (it is not
initialized by default), then rebuilding egcs and any C++ libraries.
_________________________________________________________________
When building from CVS sources, I see 'gperf: invalid option -- F', even with
the most current version of gperf.
The current version of gperf (v2.7) does not support the -F flag which
is used when building egcs from CVS sources. You will need to obtain a
patch for gperf and rebuild the program; this patch is available at
[84]ftp://egcs.cygnus.com/pub/egcs/infrastructure/
Patches for other tools, particularly autoconf, may also be necessary
if you're building from CVS sources. Please see the [85]FAQ entry
regarding these tools to determine if anything else is needed.
These patched utilities should _only_ be required if you are building
from CVS sources. For example, gperf is used to generate C code for a
perfect hash function given an input file. Distributions of egcs
already contain the generated C code, while the CVS sources will
provide only the gperf input file. So gperf should only be necessary
if you are building anything obtained from CVS.
_________________________________________________________________
When building C++, the linker says my constructors, destructors or virtual
tables are undefined, but I defined them
The ISO C++ Standard specifies that all virtual methods of a class
that are not pure-virtual must be defined, but does not require any