The Definitive Guide To Gcc

GCC%20-%20The%20definitive%20guide

Hagen-The%20Definitive%20Guide%20to%20GCC-Apress%20(2006)

Hagen-The%20Definitive%20Guide%20to%20GCC-Apress%20(2006)

User Manual:

Open the PDF directly: View PDF PDF.
Page Count: 581 [warning: Documents this large are best viewed by clicking the View PDF Link!]

this print for content only—size & color not accurate spine = 1.102" 584 page count
BOOKS FOR PROFESSIONALS BY PROFESSIONALS®
The Definitive Guide to GCC,
SECOND EDITION
Dear Reader,
I’ve used GCC regularly since the 1980s and each new release brings additional
power and complexity. If youre looking at this book, youre probably interested
in also becoming a proficient GCC user, making the most of this amazingly
powerful collection of compilers for C, C++, Objective C, Java, and Fortran.
Trying to identify and use the latest and greatest features of GCC is one thing,
but mastering tasks such as optimization, code profiling, and test coverage, as
well as building cross-compilers and using other C libraries can be far more
daunting. I’ve done the research and experiments for you, and provide clear
explanations of how to apply the GCC compilers and tools such as gprof, gcov,
libtool, autoconf, automake, crosstool, and buildroot to help you get your work
done as quickly and efficiently as possible. I also discuss how to use related
GNU tools for code profiling and code analysis, and how to automate build
processes. The numerous code samples and clear instruction will help you
master this powerful toolset in a quick and painless manner.
Along with thoroughly updated chapters in line with the latest 4.x series of
GCC compilers, The Definitive Guide to GCC, Second Edition includes new
chapters that cover the following:
Using the GCC Java compiler (gcj) and Interpreter (gij)
Using the new GCC Fortran compiler (gfortran)
Building GCC cross-compilers that run on one system but produce code
for another
Compiling and utilizing alternative C libraries, including dietlibc, klibc,
Newlib, and uClibc
Happy compiling!
Bill
Author of
The Definitive Guide to GCC,
First Edition
Hacking the TiVo,
First and Second Editions
Linux Filesystems
SGML for Dummies
Coauthor of
Linux Server Hacks,
Volume Two
SUSE 10 Linux Bible
SUSE 9 Linux Bible
Mac OS X Power
User’s Guide
US $49.99
Shelve in
Programming/Tools
User level:
Beginner–Intermediate
von Hagen
SECOND
EDITION
GCC
THE EXPERT’S VOICE®IN OPEN SOURCE
William von Hagen
The Definitive Guide to
GCC
SECOND EDITION
CYAN
MAGENTA
YELLOW
BLACK
PANTONE 123 CV
ISBN 1-59059-585-8
9 781590 595855
54999
689253 59585 5
Companion
eBook Available
Everything you need to know about using
the GNU Compiler Collection and related tools
Companion eBook
See last page for details
on $10 eBook version
The
Definitive
Guide to
Completely
updated to cover
GCC 4.x
Completely
updated to cover
GCC 4.x
RELATED TITLES
Beginning C: From Novice to
Professional, Fourth Edition
Ivor Horton’s Beginning
ANSI C++: The Complete
Language, Third Edition
www.apress.com
SOURCE CODE ONLINE forums.apress.com
FOR PROFESSIONALS BY PROFESSIONALS
Join online discussions:
The Definitive Guide
to GCC
Second Edition
■■■
William von Hagen
VonHagen_5858 FRONT.fm Page i Wednesday, July 19, 2006 9:30 AM
The Definitive Guide to GCC, Second Edition
Copyright © 2006 by William von Hagen
All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means,
electronic or mechanical, including photocopying, recording, or by any information storage or retrieval
system, without the prior written permission of the copyright owner and the publisher.
ISBN-13 (pbk): 978-1-59059-585-5
ISBN-10 (pbk): 1-59059-585-8
Printed and bound in the United States of America 9 8 7 6 5 4 3 2 1
Trademarked names may appear in this book. Rather than use a trademark symbol with every occurrence
of a trademarked name, we use the names only in an editorial fashion and to the benefit of the trademark
owner, with no intention of infringement of the trademark.
Lead Editors: Jason Gilmore, Keir Thomas
Technical Reviewer: Gene Sally
Editorial Board: Steve Anglin, Ewan Buckingham, Gary Cornell, Jason Gilmore, Jonathan Gennick,
Jonathan Hassell, James Huddleston, Chris Mills, Matthew Moodie, Dominic Shakeshaft, Jim Sumser,
Keir Thomas, Matt Wade
Project Manager: Richard Dal Porto
Copy Edit Manager: Nicole LeClerc
Copy Editor: Jennifer Whipple
Assistant Production Director: Kari Brooks-Copony
Production Editor: Katie Stence
Compositor: Susan Glinert
Proofreader: Elizabeth Berry
Indexer: Toma Mulligan
Artist: April Milne
Cover Designer: Kurt Krames
Manufacturing Director: Tom Debolski
Distributed to the book trade worldwide by Springer-Verlag New York, Inc., 233 Spring Street, 6th Floor,
New York, NY 10013. Phone 1-800-SPRINGER, fax 201-348-4505, e-mail orders-ny@springer-sbm.com, or
visit http://www.springeronline.com.
For information on translations, please contact Apress directly at 2560 Ninth Street, Suite 219, Berkeley, CA
94710. Phone 510-549-5930, fax 510-549-5939, e-mail info@apress.com, or visit http://www.apress.com.
The information in this book is distributed on an “as is” basis, without warranty. Although every precaution
has been taken in the preparation of this work, neither the author(s) nor Apress shall have any liability to
any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly
by the information contained in this work.
The source code for this book is available to readers at http://www.apress.com in the Source Code section.
VonHagen_5858 FRONT.fm Page ii Wednesday, July 19, 2006 9:30 AM
To Dorothy Fisher, for all your love, support, and encouragement.
And for Becky Gable—what would we do without the schematics?
—Bill von Hagen
VonHagen_5858 FRONT.fm Page iii Wednesday, July 19, 2006 9:30 AM
VonHagen_5858 FRONT.fm Page iv Wednesday, July 19, 2006 9:30 AM
v
Contents at a Glance
About the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
About the Technical Reviewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xix
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xxi
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii
CHAPTER 1 Using GCC’s C Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
CHAPTER 2 Using GCC’s C++ Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
CHAPTER 3 Using GCC’s Fortran Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
CHAPTER 4 Using GCC’s Java Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
CHAPTER 5 Optimizing Code with GCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
CHAPTER 6 Analyzing Code Produced with GCC Compilers . . . . . . . . . . . . . . . . . . . . 119
CHAPTER 7 Using Autoconf and Automake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
CHAPTER 8 Using Libtool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
CHAPTER 9 Troubleshooting GCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
CHAPTER 10 Additional GCC and Related Topic Resources . . . . . . . . . . . . . . . . . . . . . . 215
CHAPTER 11 Compiling GCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
CHAPTER 12 Building and Installing Glibc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
CHAPTER 13 Using Alternate C Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
CHAPTER 14 Building and Using C Cross-Compilers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
APPENDIX A Using GCC Compilers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
APPENDIX B Machine- and Processor-Specific Options for GCC . . . . . . . . . . . . . . . . . 403
APPENDIX C Using GCC’s Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
VonHagen_5858 FRONT.fm Page v Wednesday, July 19, 2006 9:30 AM
VonHagen_5858 FRONT.fm Page vi Wednesday, July 19, 2006 9:30 AM
vii
Contents
About the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
About the Technical Reviewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xix
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xxi
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii
CHAPTER 1 Using GCC’s C Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
GCC Option Refresher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Compiling C Dialects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Exploring C Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
GCC’s C and Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Locally Declared Labels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Labels As Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Nested Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Constructing Function Calls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Referring to a Type with typeof. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Zero-Length Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Arrays of Variable Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Macros with a Variable Number of Arguments . . . . . . . . . . . . . . . . . . . . . . 18
Subscripting Non-lvalue Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Arithmetic on Void and Function Pointers . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Nonconstant Initializers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Designated Initializers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Case Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Mixed Declarations and Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Declaring Function Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Specifying Variable Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Inline Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Function Names As Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
#pragmas Accepted by GCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Objective-C Support in GCC’s C Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Compiling Objective-C Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
GCC Options for Compiling Objective-C Applications . . . . . . . . . . . . . . . . . 33
Exploring the GCC Objective-C Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
VonHagen_5858 FRONT.fm Page vii Wednesday, July 19, 2006 9:30 AM
viii CONTENTS
CHAPTER 2 Using GCC’s C++ Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
GCC Option Refresher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Filename Extensions for C++ Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Command-Line Options for GCC’s C++ Compiler . . . . . . . . . . . . . . . . . . . . . . . . 43
ABI Differences in g++ Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
GNU C++ Implementation Details and Extensions . . . . . . . . . . . . . . . . . . . . . . . 47
Attribute Definitions Specific to g++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
C++ Template Instantiation in g++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Function Name Identifiers in C++ and C . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Minimum and Maximum Value Operators . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Using Java Exception Handling in C++ Applications . . . . . . . . . . . . . . . . . 50
Visibility Attributes and Pragmas for GCC C++ Libraries. . . . . . . . . . . . . . 51
CHAPTER 3 Using GCC’s Fortran Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
Fortran History and GCC Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Compiling Fortran Applications with gfortran . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Common Compilation Options with Other GCC Compilers. . . . . . . . . . . . . 55
Sample Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Compiling Fortran Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Modernizing the Sample Fortran Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Command-Line Options for gfortran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Code Generation Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Debugging Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Directory Search Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Fortran Dialect Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Warning Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
gfortran Intrinsics and Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Classic GNU Fortran: The g77 Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Why Use g77?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Differences Between g77 and gfortran Conventions . . . . . . . . . . . . . . . . . 74
Alternatives to gfortran and g77 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
The f2c Fortran-to-C Conversion Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
The g95 Fortran Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Intel’s Fortran Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Additional Sources of Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
VonHagen_5858 FRONT.fm Page viii Wednesday, July 19, 2006 9:30 AM
CONTENTS ix
CHAPTER 4 Using GCC’s Java Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Java and GCC’s Java Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Basic gcj Compiler Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Demonstrating gcj, javac, and JVM Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 83
Filename Extensions for Java Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Command-Line Options for GCC’s Java Compiler . . . . . . . . . . . . . . . . . . . . . . . . 86
Constructing the Java Classpath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Creating and Using Jar Files and Shared Libraries . . . . . . . . . . . . . . . . . . . . . . . 90
GCC Java Support and Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Java Language Standard ABI Conformance . . . . . . . . . . . . . . . . . . . . . . . . 93
Runtime Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Getting Information About Java Source and Bytecode Files . . . . . . . . . . . 94
Using the GNU Interpreter for Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Java and C++ Integration Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
CHAPTER 5 Optimizing Code with GCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101
A Whirlwind Tour of Compiler Optimization Theory . . . . . . . . . . . . . . . . . . . . . . 102
Code Motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Common Subexpression Elimination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Constant Folding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Copy Propagation Transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Dead Code Elimination. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
If-Conversion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Inlining. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
GCC Optimization Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
What’s New in GCC 4.x Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Architecture-Independent Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Level 1 GCC Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Level 2 GCC Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
GCC Optimizations for Code Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Level 3 GCC Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Manual GCC Optimization Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Processor-Specific Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Automating Optimization with Acovea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Building Acovea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Configuring and Running Acovea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
VonHagen_5858 FRONT.fm Page ix Wednesday, July 19, 2006 9:30 AM
xCONTENTS
CHAPTER 6 Analyzing Code Produced with GCC Compilers . . . . . . . . . . . . . . 119
Test Coverage Using GCC and gcov . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Overview of Test Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Compiling Code for Test Coverage Analysis . . . . . . . . . . . . . . . . . . . . . . . 123
Using the gcov Test Coverage Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
A Sample gcov Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Files Used and Produced During Coverage Analysis . . . . . . . . . . . . . . . . 133
Code Profiling Using GCC and gprof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Obtaining and Compiling gprof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Compiling Code for Profile Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Using the gprof Code Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Symbol Specifications in gprof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
A Sample gprof Session. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Displaying Annotated Source Code for Your Applications . . . . . . . . . . . . 144
Adding Your Own Profiling Code Using GCC’s C Compiler. . . . . . . . . . . . 148
Mapping Addresses to Function Names. . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Common Profiling Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
CHAPTER 7 Using Autoconf and Automake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151
Introducing Unix Software Configuration, Autoconf, and Automake . . . . . . . . 151
Installing and Configuring autoconf and automake . . . . . . . . . . . . . . . . . . . . . . 154
Deciding Whether to Upgrade or Replace autoconf and automake . . . . 154
Building and Installing autoconf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Obtaining and Installing Automake. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Configuring Software with autoconf and automake . . . . . . . . . . . . . . . . . . . . . 161
Creating Configure.ac Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Creating Makefile.am Files and Other Files Required by automake . . . . 166
Running Autoconf and Automake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Running Configure Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
CHAPTER 8 Using Libtool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177
Introduction to Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Static Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Shared Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Dynamically Loaded Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
What Is Libtool? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Downloading and Installing Libtool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Installing Libtool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Files Installed by Libtool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
VonHagen_5858 FRONT.fm Page x Wednesday, July 19, 2006 9:30 AM
CONTENTS xi
Using Libtool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Using Libtool from the Command Line. . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Command-Line Options for Libtool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Command-Line Modes for Libtool Operation. . . . . . . . . . . . . . . . . . . . . . . 186
Using Libtool with Autoconf and Automake. . . . . . . . . . . . . . . . . . . . . . . . 191
Troubleshooting Libtool Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Getting More Information About Libtool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
CHAPTER 9 Troubleshooting GCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .197
Coping with Known Bugs and Misfeatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Using -### to See What’s Going On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Resolving Common Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Problems Executing GCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Using Multiple Versions of GCC on a Single System. . . . . . . . . . . . . . . . . 200
Problems Loading Libraries When Executing Programs. . . . . . . . . . . . . . 201
‘No Such File or Directory’ Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Problems Executing Files Compiled with GCC Compilers . . . . . . . . . . . . 203
Running Out of Memory When Using GCC. . . . . . . . . . . . . . . . . . . . . . . . . 203
Moving GCC After Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
General Issues in Mixing GNU and Other Toolchains . . . . . . . . . . . . . . . . 204
Specific Compatibility Problems in Mixing GCC with Other Tools . . . . . . 206
Problems When Using Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Problems with Include Files or Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Mysterious Warning and Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . 209
Incompatibilities Between GNU C and K&R C . . . . . . . . . . . . . . . . . . . . . . 210
Abuse of the __STDC__ Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Resolving Build and Installation Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
CHAPTER 10 Additional GCC and Related Topic Resources . . . . . . . . . . . . . . .215
Usenet Resources for GCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Selecting Software for Reading Usenet News. . . . . . . . . . . . . . . . . . . . . . 216
Summary of GCC Newsgroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Mailing Lists for GCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
GCC Mailing Lists at gcc.gnu.org . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Netiquette for the GCC Mailing Lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Other GCC-Related Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
World Wide Web Resources for GCC and Related Topics . . . . . . . . . . . . . . . . . 223
Information About GCC and Cross-Compilation . . . . . . . . . . . . . . . . . . . . 224
Information About Alternate C Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Publications About GCC and Related Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
VonHagen_5858 FRONT.fm Page xi Wednesday, July 19, 2006 9:30 AM
xii CONTENTS
CHAPTER 11 Compiling GCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .227
Why Build GCC from Source? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Starting the Build Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Verifying Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Preparing the Installation System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Downloading the Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Installing the Source Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Configuring the Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
What Is in a (System) Name? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Additional Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
NLS-Related Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Building Specific Compilers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Compiling the Compilers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Compilation Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Other Make Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Testing the Build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Installing GCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
CHAPTER 12 Building and Installing Glibc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .247
What Is in Glibc? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Why Build Glibc from Source? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Potential Problems in Upgrading Glibc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Identifying Which Glibc a System Is Using . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Getting More Details About Glibc Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Glibc Add-Ons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Previewing the Build Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Recommended Tools for Building Glibc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Updating GNU Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Downloading and Installing Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Downloading the Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Installing Source Code Archives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Integrating Add-Ons into the Glibc Source Code Directory . . . . . . . . . . . 260
Configuring the Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Compiling Glibc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Testing the Build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Installing Glibc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Installing Glibc As the Primary C Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Installing an Alternate Glibc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Using a Rescue Disk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
VonHagen_5858 FRONT.fm Page xii Wednesday, July 19, 2006 9:30 AM
CONTENTS xiii
Troubleshooting Glibc Installation Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Resolving Upgrade Problems Using BusyBox . . . . . . . . . . . . . . . . . . . . . . 271
Resolving Upgrade Problems Using a Rescue Disk . . . . . . . . . . . . . . . . . 273
Backing Out of an Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Problems Using Multiple Versions of Glibc . . . . . . . . . . . . . . . . . . . . . . . . 276
Getting More Information About Glibc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Glibc Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Other Glibc Web Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Glibc Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Reporting Problems with Glibc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Moving to Glibc 2.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
CHAPTER 13 Using Alternate C Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .281
Why Use a Different C Library? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Overview of Alternate C Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Overview of Using Alternate C Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Building and Using dietlibc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Getting dietlibc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Building dietlibc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Using dietlibc with gcc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Building and Using klibc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Getting klibc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Building klibc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Using klibc with gcc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Building and Using Newlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Getting Newlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Building and Using Newlib. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Building and Using uClibc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Getting uClibc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Building uClibc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Using uClibc with gcc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
CHAPTER 14 Building and Using C Cross-Compilers . . . . . . . . . . . . . . . . . . . . . . . . 299
What Is Cross-Compilation? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Using crosstool to Build Cross-Compilers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Retrieving the crosstool Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Building a Default Cross-Compiler Using crosstool . . . . . . . . . . . . . . . . . 304
Building a Custom Cross-Compiler Using crosstool . . . . . . . . . . . . . . . . . 305
Using buildroot to Build uClibc Cross-Compilers . . . . . . . . . . . . . . . . . . . . . . . . 307
Retrieving the buildroot Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Building a Cross-Compiler Using buildroot . . . . . . . . . . . . . . . . . . . . . . . . 309
Debugging and Resolving Toolchain Build Problems in buildroot . . . . . . . 317
Building Cross-Compilers Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
VonHagen_5858 FRONT.fm Page xiii Wednesday, July 19, 2006 9:30 AM
xiv CONTENTS
APPENDIX A Using GCC Compilers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .321
Using Options with GCC Compilers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
General Information Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Controlling GCC Compiler Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Controlling the Preprocessor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Modifying Directory Search Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Passing Options to the Assembler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Controlling the Linker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Enabling and Disabling Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Adding Debugging Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Customizing GCC Compilers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Customizing GCC Compilers Using Environment Variables . . . . . . . . . . . 347
Customizing GCC Compilers with Spec Files and Spec Strings . . . . . . . 349
Alphabetical GCC Option Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
APPENDIX B Machine- and Processor-Specific Options for GCC . . . . . . . . . 403
Alpha Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Alpha/VMS Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
AMD x86-64 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
AMD 29K Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
ARC Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
ARM Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
AVR Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Blackfin Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Clipper Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Convex Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
CRIS Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
CRX Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
D30V Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Darwin Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
FR-V Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
H8/300 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
HP/PA (PA/RISC) Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
i386 and AMD x86-64 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
IA-64 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Intel 960 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
M32C Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
M32R Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
M680x0 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
M68HC1x Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
M88K Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
MCore Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
MIPS Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
MMIX Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
MN10200 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
VonHagen_5858 FRONT.fm Page xiv Wednesday, July 19, 2006 9:30 AM
CONTENTS xv
MN10300 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
MT Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
NS32K Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
PDP-11 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
PowerPC (PPC) Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
RS/6000 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
RT Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
S/390 and zSeries Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
SH Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
SPARC Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
System V Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
TMS320C3x/C4x Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
V850 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
VAX Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Xstormy16 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Xtensa Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
APPENDIX C Using GCC’s Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .491
What Is GNU Info? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Getting Started, or Instructions for the Impatient . . . . . . . . . . . . . . . . . . . . . . . . 492
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
The Beginner’s Guide to Using GNU Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
Anatomy of a GNU Info Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
Moving Around in GNU Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Performing Searches in GNU Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
Following Cross-References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Printing GNU Info Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
Invoking GNU Info. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
Stupid Info Tricks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
Using Command Multipliers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
Working with Multiple Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .505
VonHagen_5858 FRONT.fm Page xv Wednesday, July 19, 2006 9:30 AM
VonHagen_5858 FRONT.fm Page xvi Wednesday, July 19, 2006 9:30 AM
xvii
About the Author
BILL VON HAGEN holds degrees in computer science, English writing, and
art history. Bill has worked with Unix systems since 1982, during which
time he has been a system administrator, writer, systems programmer,
development manager, drummer, operations manager, content manager,
and product manager. Bill has written a number of books including
The Ubuntu Bible, Hacking the TiVo, Linux Filesystems, Installing Red Hat
Linux, and SGML for Dummies; coauthored Linux Server Hacks, Volume 2
and Mac OS X Power User’s Guide; and contributed to several other books.
Bill has written articles and software reviews for publications including
Linux Journal, Linux Magazine, Mac Tech, Linux Format (UK), Mac Format (UK), and Mac Directory.
He has also written extensive online content for CMP Media, Linux Planet, and Linux Today. An avid
computer collector specializing in workstations, he owns more than 200 computer systems. You can
contact Bill at wvh@vonhagen.org.
VonHagen_5858 FRONT.fm Page xvii Wednesday, July 19, 2006 9:30 AM
VonHagen_5858 FRONT.fm Page xviii Wednesday, July 19, 2006 9:30 AM
xix
About the Technical Reviewer
GENE SALLY has been a Linux enthusiast for the past ten years, and for the past six he has channeled
his enthusiasm through his employer, TimeSys, creating tools for embedded Linux engineers and
helping them become more productive. Embedded development pushes the envelope of most tech-
nologies, Linux and GCC included, so Gene has had the opportunity to push these tools to their limits
as he creates development tools and technologies for TimeSys’ customers.
VonHagen_5858 FRONT.fm Page xix Wednesday, July 19, 2006 9:30 AM
VonHagen_5858 FRONT.fm Page xx Wednesday, July 19, 2006 9:30 AM
xxi
Acknowledgments
I’d like to thank Kurt Wall for his friendship and the opportunity to work with him on the first edition
of this book, and Marta Justak, of Justak Literary Services, for her support and help with this book. I’d
also like to thank Gene Sally for making this book far better than it could have been without him, and
Richard Dal Porto, Keir Thomas, Jason Gilmore, Jennifer Whipple, Katie Stence, and others at Apress
for their patience (!) and support for this second edition. In general, I’d like to thank GCC, emacs
(the one true editor), Richard Stallman and the FSF, 50 million BSD fans (who can’t be wrong), and
Linux Torvalds and a cast of thousands for their contributions to computing as we know it today.
Without their foresight, philosophy, and hard work, this book wouldn’t even exist. I’d especially
like to thank rms for some way cool LMI hacks long ago.
VonHagen_5858 FRONT.fm Page xxi Wednesday, July 19, 2006 9:30 AM
VonHagen_5858 FRONT.fm Page xxii Wednesday, July 19, 2006 9:30 AM
xxiii
Introduction
This book, The Definitive Guide to GCC, is about how to build, install, customize, use, and trouble-
shoot GCC version 4.x. GCC has long been available for most major hardware and operating system
platforms and is often the preferred family of compilers.
As a general-purpose set of compilers, GCC produces high-quality, fast code. Due to its design,
GCC is easy to port to different architectures, which contributes to its popularity. GCC, along with
GNU Emacs, the Linux operating system, the Apache Web server, the Sendmail mail server, and the
BIND DNS server, are showpieces of the free software world and proof that sometimes you can get a
free lunch.
Why a Book About GCC?
I wrote this book, and you should read it, for a variety of reasons: it covers version 4.x; it is the only
book that covers general GCC usage; and I would argue that it is better than GCC’s own documenta-
tion. You will not find more complete coverage of GCC’s features, quirks, and usage anywhere else in
a single volume. There are no other up-to-date sources of information on GCC, excluding GCC’s own
documentation. GCC usually gets one or two chapters in programming books and only a few para-
graphs in other more general titles.
GCC’s existing documentation, although thorough and comprehensive, targets a programming-
savvy reader. There’s certainly nothing wrong with this approach, which is certainly the proper
approach for advanced users, but GCC’s own documentation leaves the great majority of its users
out in the cold. Much of The Definitive Guide to GCC is tutorial and practical in nature, explaining
why you use one option or why you should not use another one. In addition, explaining auxiliary
tools and techniques that are relevant to GCC but not explicitly part of the package helps make this
book a complete and usable guide and reference. Showing you how to use the compilers in the GCC
family and related tools, and helping you get your work done are this book’s primary goals.
Most people, including many long-time programmers, use GCC the way they learned or were
taught to use it. That is, many GCC users treat the compiler as a black box, which means that they
invoke it by using a small and familiar set of options and arguments they have memorized, shoving
source files in one end, and then receiving a compiled, functioning program from the other end.
With a powerful set of compilers such as GCC, there are indeed stranger (and more useful) things
than were dreamed of in Computer Science 101. Therefore, another goal when writing The Definitive
Guide to GCC was to reveal cool but potentially obscure options and techniques that you may find
useful when building or using GCC and related tools and libraries.
Inveterate tweakers, incorrigible tinkerers, and the just plain adventurous among you will also
enjoy the chance to play with the latest and greatest version of GCC and the challenge of bending a
complex piece of software to your will, especially if you have instructions that show you how to do so
with no negative impact on your existing system.
VonHagen_5858 FRONT.fm Page xxiii Wednesday, July 19, 2006 9:30 AM
xxiv INTRODUCTION
Why the New Edition?
I’ve written a new edition of this book for two main reasons: much has changed in GCC since the first
edition of this book came out, and I wanted to talk about the other GCC compilers and related tech-
nologies such as cross-compilers and alternate C libraries. The GCC 4.x family of compilers is now
available, providing a new optimization framework, many associated improvements to optimization
in general, a new Fortran compiler, significant performance improvements for the C++ compiler,
huge updates to the Java compiler, just-in-time compilation for Java, support for many new platforms,
and enough new options in general to keep you updating Makefiles for quite a while. The first edition
of this book focused on the C and C++ compilers in GCC, but enquiring minds want to know much
more. This edition substantially expands the C++ coverage and adds information about using the
Fortran, Java, and Objective-C compilers. No one has ever asked me about the Ada compiler, so I’ve
still skipped that one. In addition, I’ve added information on using alternate C libraries and building
cross-compilers that should make this book more valuable to its existing audience and (hopefully)
attractive to an even larger one.
What You Will Learn
The Definitive Guide to GCC now provides a chapter dedicated to explaining how to use each of the
C, C++, Fortran, and Java compilers. Information that is common to all of the compilers has been
moved to Appendix A, so as not to repeat it everywhere and keep you from getting started with your
favorite compiler. Similarly, information about building GCC has been moved to much later in the
book, since most readers simply want to use the compilers that they find on their Linux and *BSD
systems, not necessarily build them from scratch. However, if you want the latest and greatest version
of GCC, you will learn how to download, compile, and install GCC from scratch, a poorly understood
procedure that, until now, only the most capable and confident users have been willing to undertake.
The chapter on troubleshooting compilation problems has been expanded to make it easier
than ever to discover problems in your code or the configuration or installation of your GCC compilers.
If you’re a traditional Makefile fan, the chapters on Libtool, Autoconf, and Automake will help you
produce your Makefiles automatically, making it easier to package, archive, and distribute the source
code for your projects. The chapters on code optimization, test coverage, and profiling have been
expanded and updated to discuss the latest techniques and tools, helping you debug, improve, and
test your code more extensively than ever. Finally, the book veers back to its focus for a more general
audience by providing a complete summary of the GCC’s command-line interface, a chapter on
troubleshooting GCC usage and installation, and another chapter explaining how to use GCC’s
online documentation.
What You Need to Know
This is an end user’s book intended for anyone using almost all of the GCC compilers (sorry, Ada fans).
Whether you are a casual end user who only occasionally compiles programs, an intermediate user
using GCC frequently but lacking much understanding of how it works, or a programmer seeking to exer-
cise GCC to the full extent of its capabilities, you will find information in this book that you can use
immediately. Because Linux and Intel x86 CPUs are so popular, I’ve assumed that most of you are
using one version or another of the Linux operating system running on Intel x86 or compatible systems.
This isn’t critical—most of the material is GCC-specific, rather than being Linux- or Intel-specific,
because GCC is largely independent of operating systems and CPU features in terms of its usage.
What do you need to know to benefit from this book? Well, knowing how to type is a good start
because the GCC compilers are command-line compilers. (Though GCC compilers are integrated
VonHagen_5858 FRONT.fm Page xxiv Wednesday, July 19, 2006 9:30 AM
INTRODUCTION xxv
into many graphical integrated development environments, that is somewhat outside the scope of
this book.) You should therefore be comfortable with working in a command-line environment, such
as a terminal window or a Unix or Linux console. You need to be computer literate, and the more
experience you have with Unix or Unix-like systems, such as Linux, the better. If you have downloaded
and compiled programs from source code before, you will be familiar with the terminology and
processes discussed in the text. If, on the other hand, this is your first foray into working with source
code, the chapters on building GCC and C libraries will get you up and running quickly. You do not
need to be a programming wizard or know how to do your taxes in hexadecimal. Any experience that
you have using a compiled programming language is gravy.
You should also know how to use a text editor, such as vi, pico, or Emacs, if you intend to type
the listings and examples yourself in order to experiment with them. Because the source and binary
versions of the GCC are usually available in some sort of compressed format, you will also need to
know how to work with compressed file formats, usually gzipped tarballs, although the text will
explain how to do so.
What The Definitive Guide to GCC Does Not Cover
As an end user’s book on GCC, a number of topics are outside this book’s scope. In particular, it is not
a primer on C, C++, Fortran, or Java, although each chapter provides a consistent set of programming
examples that I’ve used throughout the book. As discussed throughout this book, GCC is a collection
of front-end, language-specific interfaces to a common back-end compilation engine. The list of
compilers includes C, C++, Objective C, Fortran, Ada, and Java, among others. Compiler theory gets
short shrift in this book, because I believe that most people are primarily interested in getting work
done with GCC, not writing it. The Free Software Foundation has some excellent documents on GCC
internals on its Web site, and it doesn’t get much more definitive than that. That said, it is difficult to
talk about using a compiler without skimming the surface of compiler theory and operation, so this
book defines key terms and concepts as necessary while describing GCC’s architecture and overall
compilation workflow.
History and Overview of GCC
This section takes a more thorough look at what GCC is and does and includes the obligatory history
of GCC. Because GCC is one of the GNU Project’s premier projects, GCC’s development model bears
a closer look, so I will also show you GCC’s development model, which should help you understand
why GCC has some features and lacks other features, and how you can participate in its development.
What exactly is GCC? The tautological answer is that GCC is an acronym for the GNU Compiler
Collection, formerly known as the GNU Compiler Suite, and also known as GNU CC and the GNU C
Compiler. As remarked earlier, GCC is a collection of compiler front ends to a common back-end
compilation engine. The list of compilers includes C, C++, Objective C, Fortran (now 95, formerly 77),
and Java. GCC also has front ends for Pascal, Modula-3, and Ada 9X. The C compiler itself speaks
several different dialects of C, including traditional and ANSI C. The C++ compiler is a true native
C++ compiler. That is, it does not first convert C++ code into an intermediate C representation before
compiling it, as did the early C++ compilers such as the Cfront “compiler” Bjarne Stroustrup first
used to create C++. Rather, GCC’s C++ compiler, g++, creates native executable code directly from
the C++ source code.
GCC is an optimizing and cross-platform compiler. It supports general optimizations that can
be applied regardless of the language in use or the target CPU and options specific to particular CPU
families and even specific to a particular CPU model within a family of related processors. Moreover,
the range of hardware platforms to which GCC has been ported is remarkably long. GCC supports
platform and target submodels, so that it can generate executable code that will run on all members
VonHagen_5858 FRONT.fm Page xxv Wednesday, July 19, 2006 9:30 AM
xxvi INTRODUCTION
of a particular CPU family or only on a specific model of that family. Table 1 provides a partial list
of GCC’s supported architectures, many of which you might never have heard of, much less used.
Frankly, I haven’t used (or even seen) all of them. For a more definitive list, see Appendix B, which
summarizes architectures and processor-specific options for your convenience.
Considering the variety of CPUs and architectures to which GCC has been ported, it should be
no surprise that you can configure it as a cross-compiler and use GCC to compile code on one plat-
form that is intended to run on an entirely different platform. In fact, you can have multiple GCC
configurations for various platforms installed on the same system and, moreover, run multiple GCC
versions (older and newer) for the same CPU family on the same system.
Table 1. Some of the Most Popular Processor Architectures Supported by GCC
Architecture Description
AMD29K AMD Am29000 architectures
AMD64 64-bit AMD processors that are compatible with the Intel-32
architecture
ARM Advanced RISC Machines architectures
ARC Argonaut ARC processors
AVR Atmel AVR microcontrollers
ColdFire Motorola’s latest generation of 68000 descendents
DEC Alpha Compaq (neé Digital Equipment Corporation) Alpha processors
H8/300 Hitachi H8/300 CPUs
HP/PA Hewlett-Packard PA-RISC architectures
Intel i386 Intel i386 (x86) family of CPUs
Intel i960 Intel i960 family of CPUs
M32R/D Mitsubishi M32R/D architectures
M68K The Motorola 68000 series of CPUs
M88K Motorola 88K architectures
MCore Motorola M*Core processors
MIPS MIPS architectures
MN10200 Matsushita MN10200 architectures
MN10300 Matsushita MN10300 architectures
NS32K National Semiconductor NS3200 CPUs
RS/6000 and PowerPC IBM RS/6000 and PowerPC architectures
S390 IBM processors used in zSeries and System z mainframe
SPARC Sun Microsystems family of SPARC CPUs
SH3/4/5 Super Hitachi 3, 4, and 5 family of processors
TMS320C3x/C4x Texas Instruments TMS320C3x and TMS320C4x DSPs
VonHagen_5858 FRONT.fm Page xxvi Wednesday, July 19, 2006 9:30 AM
INTRODUCTION xxvii
GCC’s History
GCC, or rather, the idea for it, actually predates the GNU Project. In late 1983, just before he started
the GNU Project, Richard M. Stallman, president of the Free Software Foundation and originator of the
GNU Project, heard about a compiler named the Free University Compiler Kit (known as VUCK) that
was designed to compile multiple languages, including C, and to support multiple target CPUs. Stallman
realized that he needed to be able to bootstrap the GNU system and that a compiler was the first
strap he needed to boot. So he wrote to VUCK’s author asking if GNU could use it. Evidently, VUCK’s
developer was uncooperative, responding that the university was free but that the compiler was not.
As a result, Stallman concluded that his first program for the GNU Project would be a multilanguage,
cross-platform compiler. Undeterred and in true hacker fashion, desiring to avoid writing the entire
compiler himself, Stallman eventually obtained the source code for Pastel, a multiplatform compiler
developed at Lawrence Livermore National Laboratory. He added a C front end to Pastel and began
porting it to the Motorola 68000 platform, only to encounter a significant technical obstacle: the
compiler’s design required many more megabytes of stack space than the 68000-based Unix system
supported. This situation forced him to conclude that he would have to write a new compiler, starting
from ground zero. That new compiler eventually became GCC.
Although it contains none of the Pastel source code that originally inspired it, Stallman did adapt
and use the C front end he wrote for Pastel. As a starting point for GCC’s optimizer, Stallman also
used PO, a portable peephole optimizer that performed optimizations generally done by high-level
optimizers, in addition to low-level peephole optimizers. GCC (and PO’s successor, vpo) still uses
RTL (register transfer language) as an intermediate format for the optimizer. Development of this
primordial GCC proceeded slowly through the 1980s, because, as Stallman writes in his description of the
GNU Project (http://www.gnu.org/gnu/the-gnu-project.html), “first, [he] worked on GNU Emacs.”
During the 1990s, GCC development split into two, perhaps three, branches. While the primary
GCC branch continued to be maintained by the GNU Project, a number of other developers, prima-
rily associated with Cygnus Solutions, began releasing a version of GCC known as EGCS (Experimental
[or Enhanced] GNU Compiler Suite). EGCS was intended to be a more actively developed and more
efficient compiler than GCC, but was otherwise effectively the same compiler because it closely
tracked the GCC code base and EGCS enhancements were fed back into the GCC code base maintained
by the GNU Project. Nonetheless, the two code bases were separately maintained. In April 1999, GCC’s
maintainers, the GNU Project, and the EGCS steering committee formally merged. At the same time,
GCC’s name was changed to the GNU Compiler Collection and the separately maintained (but, as
noted, closely synchronized) code trees were formally combined, ending a long fork and incorpo-
rating the many bug fixes and enhancements made in EGCS into GCC. This is why EGCS is often
mentioned, though it is officially defunct.
Other historical variants of GCC include the Pentium Compiler Group (PCG) project’s own version
of GCC, PGCC. PGCC was a Pentium-specific version that was intended to provide the best possible
support for features found in Intel’s Pentium-class CPUs. During the period of time that EGCS was
separately maintained, PGCC closely tracked the EGCS releases. The reunification of EGCS and GCC
seems to have halted PGCC development because, at the time of this writing, the PCG project’s last
release was 2.95.2.1, dated December 27, 2000. For additional information, visit the PGCC project’s
Web site at http://www.goof.com/pcg/.
At the time that this book was written, GCC 4.2 was about to become available. The latest officially
released version of the GCC 3.x line of compilers is 3.4.5. Other significant milestone compilers are
the 2.95.x compilers, which were widely hacked to produce code for a variety of embedded systems and
which are still widely available.
Who Maintains GCC?
Formally, GCC is a GNU Project, which is directed by the FSF. The FSF holds the copyright on the
compilers, and licenses the compilers under the terms of the GPL. Either individuals or the FSF hold
VonHagen_5858 FRONT.fm Page xxvii Wednesday, July 19, 2006 9:30 AM
xxviii INTRODUCTION
the copyrights on other components, such as the runtime libraries and test suites, and these other
components are licensed under a variety of licenses for free software. For information on the licensing of
any FSF package see the file LICENSE that is provided with its source code distribution. The FSF also
handles the legal concerns of the GCC project. So much for the administrivia.
On the practical side, a cast of dozens maintains GCC. GCC’s maintainers consist of a formally
organized steering committee and a larger, more loosely organized group of hackers scattered all
over the Internet. The GCC steering committee, as of August 2001, is made up of 14 people repre-
senting various communities in GCC’s user base who have a significant stake in GCC’s continuing
and long-term survival, including kernel hackers, Fortran users, and embedded systems developers.
The steering committee’s purpose is, to quote its mission statement, “to make major decisions in the
best interests of the GCC project and to ensure that the project adheres to its fundamental principles
found in the project’s mission statement.” These “fundamental principles” include the following:
Supporting the goals of the GNU Project
Adding new languages, optimizations, and targets to GCC
More frequent releases
Greater responsiveness to consumers, the large user base that relies on the GCC compiler
An open development model that accepts input and contributions based on technical merit
The group of developers that work on GCC includes members of the steering committee and,
according to the contributors list on the GCC project home page, more than 100 other individuals
across the world. Still, others not specifically identified as contributors have contributed to GCC
development by sending in patches, answering questions on the various GCC mailing lists, submitting
bug reports, writing documentation, and testing new releases.
Who Uses GCC?
GCC’s user base is large and varied. Given the nature of GCC and the loosely knit structure of the free
software community, though, no direct estimate of the total number of GCC users is possible. A direct
estimate, based on standard metrics, such as sales figures, unit shipments, or license purchases, is
virtually impossible to derive because such numbers simply do not exist. Even indirect estimates,
based, for example, on the number of downloads from the GNU Web and FTP sites, would be question-
able because the GNU software repository is mirrored all over the world.
More to the point, I submit that quantifying the number of GCC users is considerably less
important and says less about GCC users than examining the scope of GCC’s usage and the number
of processor architectures to which it has been ported. For example, GCC is the standard compiler
shipped in every major and most minor Linux distributions. GCC is also the compiler of choice for
the various BSD operating systems (FreeBSD, NetBSD, OpenBSD, and so on). Thanks initially to the
work of DJ Delorie, GCC works on most modern DOS versions, including MS-DOS from Microsoft,
PC-DOS from IBM, and DR-DOS. Indeed, Delorie’s work resulted in ports of most of the GNU tools
for DOS-like environments. Cygnus Solutions, now owned by Red Hat, Inc., created a GCC port for
Microsoft Windows users. Both the DOS and Windows ports offer complete and free development
environments for DOS and Windows users.
The academic computing community represents another large part of GCC’s user base. Vendors
of hardware and proprietary operating systems typically provide compiler suites for their products
as a so-called value-added service, that is, for an additional, often substantial, charge. As free soft-
ware, GCC represents a compelling, attractive alternative to computer science departments faced
with tight budgets. GCC also appeals to the academic world because it is available in source code
form, giving students a chance to study compiler theory, design, and implementation. GCC is also
widely used by nonacademic customers of hardware and operating system vendors who want to
VonHagen_5858 FRONT.fm Page xxviii Wednesday, July 19, 2006 9:30 AM
INTRODUCTION xxix
reduce support costs by using a free, high-quality compiler. Indeed, if you consider the broad range
of hardware to which GCC has been ported, it becomes quite clear that GCC’s user base is composed
of the broadest imaginable range of computer users.
In general, my favorite response from any reader of this book to the question of who uses GCC
is “I do.”
Are There Alternatives?
What alternatives to GCC exist? As framed, this question is somewhat difficult to answer. Remember
that GCC is the GNU Compiler Collection, a group of language-specific compiler front ends using a
common back-end compilation engine, and that GCC is free software. So if you rephrase the question
to “what free compiler suites exist as alternatives to GCC?” the answer is “very few.”
As mentioned earlier, the Pentium Compiler Group created PGCC, a version of GCC, that was
intended to extend GCC’s ability to optimize code for Intel’s Pentium-class CPUs. Although PGCC
development seems to have stalled since the EGCS/GCC schism ended, the PGCC Web site still exists
(although it, too, has not been modified recently).
If you remove the requirement that the alternative be free, you have many more options. Many
hardware vendors and most operating system vendors will be happy to sell you compiler suites for
their respective hardware platforms or operating systems, but the cost can be prohibitive. Some
third-party vendors exist that provide stand-alone compiler suites. One such vendor is The Portland
Group (http://www.pgroup.com/), which markets a set of high-performance, parallelizing compiler
suites supporting Fortran, C, and C++. Absoft Corporation also offers a well-regarded compiler suite
supporting Fortran 77, Fortran 95, C, and C++. Visit its Web site at http://www.absoft.com/ for addi-
tional information. Similarly, Borland has a free C/C++ compiler available. Information on Borland’s
tools can be found on its Web site at http://www.borland.com/. Intel and Microsoft also sell very good
compilers. And they are not that expensive.
Conversely, if you dispense with the requirement that alternatives be collections or suites, you
can select from a rich array of options. A simple search for the word compilers at Yahoo! generates
more than 120 Web sites showcasing a variety of single-language compilers, including Ada, Basic, C
and C++, COBOL, Forth, Java, Logo, Modula-2 and Modula-3, Pascal, Prolog, and Smalltalk. If you are
looking for alternatives to GCC, a good place to start your search is the compilers.net Web page at
http://www.compilers.net/.
So much for a look at alternatives to GCC. This is a book about GCC, after all, so I hope that you’ll
forgive me for largely leaving you on your own when it comes to finding information about other
compilers. Some chapters of this book, such as the chapter on the new GCC Fortran compiler, gfortran,
discuss alternatives because of the huge number of Fortran variants out there, but by and large, GCC
is the right solution to your compilation problems.
VonHagen_5858 FRONT.fm Page xxix Wednesday, July 19, 2006 9:30 AM
VonHagen_5858 FRONT.fm Page xxx Wednesday, July 19, 2006 9:30 AM
1
■ ■ ■
CHAPTER 1
Using GCC’s C Compiler
This chapter’s goal is to get you comfortable with typical usage of the GNU Compiler Collection’s
C compiler, gcc. This chapter focuses on those command-line options and constructs that are specific
to GCC’s C compiler. Options that can generally be used with any GCC compiler are discussed in
Appendix A. Throughout this chapter, as throughout this book, I’ll differentiate between GCC (the
GNU Compiler Collection) and gcc, the C compiler that is provided as part of GCC.
This chapter explains how to tell gcc which dialect of C it should expect to encounter in your
source files, from strict ANSI/ISO C to classic Kernighan and Ritchie (K&R) C. It also explains the
variety of special-purpose constructs that are supported by gcc and how to invoke and use them. It
concludes by discussing using gcc to compile Objective C applications and discusses specific details
of the GNU Objective C runtime environment.
GCC Option Refresher
Appendix A discusses the options that are common to all of the GCC compilers and how to customize
various portions of the compilation process. However, I’m not a big fan of making people jump
around in a book for information. For that reason, this section provides a quick refresher of basic
GCC compiler usage as it applies to the gcc C compiler. For detailed information, see Appendix A.
If you are new to gcc and just want to get started quickly, you’re in the right place.
The gcc compiler accepts both single-letter options, such as -o, and multiletter options, such as
-ansi. Because it accepts both types of options you cannot group multiple single-letter options together
as you may be used to doing in many GNU and Unix/Linux programs. For example, the multiletter
option -pg is not the same as the two single-letter options -p -g. The -pg option creates extra code in
the final binary that outputs profile information for the GNU code profiler, gprof. On the other hand,
the -p -g options generate extra code in the resulting binary that produces profiling information for
use by the prof code profiler (-p) and causes gcc to generate debugging information using the oper-
ating system’s normal format (-g).
Despite its sensitivity to the grouping of multiple single-letter options, you are generally free to
mix the order of options and compiler arguments on the gcc command line. That is, invoking gcc as
gcc -pg -fno-strength-reduce -g myprog.c -o myprog
has the same result as
gcc myprog.c -o myprog -g -fno-strength-reduce -pg
VonHagen_5858 C01.fm Page 1 Wednesday, July 19, 2006 9:25 AM
2CHAPTER 1 USING GCC’S C COMPILER
I say that you are generally free to mix the order of options and compiler arguments because, in
most cases, the order of options and their arguments does not matter. In some situations, order does
matter if you use several options of the same kind. For example, the -I option specifies the directory
or directories to search for include files. So if you specify -I several times, gcc searches the listed
directories in the order specified.
Compiling a single source file, myprog.c, using gcc is easy—just invoke gcc, passing the name of
the source file as the argument.
$ gcc myprog.c
$ ls -l
-rwxr-xr-x 1 wvh users 13644 Oct 5 16:17 a.out
-rw-r--r-- 1 wvh users 220 Oct 5 16:17 myprog.c
By default, the result on Linux and Unix systems is an executable file named a.out in the current
directory, which you execute by typing ./a.out. On Cygwin systems, you will wind up with a file
named a.exe that you can execute by typing either ./a or ./a.exe.
To define the name of the output file that gcc produces, use the -o option, as illustrated in the
following example:
$ gcc myprog.c -o runme
$ ls -l
-rw-r--r-- 1 wvh users 220 Oct 5 16:17 myprog.c
-rwxr-xr-x 1 wvh users 13644 Oct 5 16:28 runme
If you are compiling multiple source files using gcc, you can simply specify them all on the gcc
command line, as in the following example, which leaves the compiled and linked executable in the
file named showdate:
$ gcc showdate.c helper.c –o showdate
If you want to compile these files incrementally and eventually link them into a binary, you can
use the –c option to halt compilation after producing an object file, as in the following example:
$ gcc -c showdate.c
$ gcc -c helper.c
$ gcc showdate.o helper.o –o showdate
$ ls -l
total 124
-rw-r--r-- 1 wvh users 210 Oct 5 12:42 helper.c
-rw-r--r-- 1 wvh users 45 Oct 5 12:29 helper.h
-rw-r--r-- 1 wvh users 1104 Oct 5 13:50 helper.o
-rwxr-xr-x 1 wvh users 13891 Oct 5 13:51 showdate
-rw-r--r-- 1 wvh users 208 Oct 5 12:44 showdate.c
-rw-r--r-- 1 wvh users 1008 Oct 5 13:50 showdate.o
VonHagen_5858 C01.fm Page 2 Wednesday, July 19, 2006 9:25 AM
CHAPTER 1 USING GCC’S C COMPILER 3
Note All of the GCC compilers “do the right thing” based on the extensions of the files provided on any GCC
command line. Mapping file extensions to actions (for example, understanding that files with .o extensions only
need to be linked) is done via the GCC specs file. Prior to GCC version 4, the specs file was a stand-alone text file
that could be modified using a text editor; with GCC 4 and later, the specs file is built-in and must be extracted
before it can be modified. For more information about working with the specs file, see the section “Customizing GCC
Using Spec Strings” in Appendix A.
It should be easy to see that a project consisting of more than a few source code files would
quickly become exceedingly tedious to compile from the command line, especially after you start
adding search directories, optimizations, and other gcc options. The solution to this command-line
tedium is the make utility, which is not discussed in this book due to space constraints (although it
is touched upon in Chapter 8).
Compiling C Dialects
The gcc compiler supports a variety of dialects of C via a range of command-line options that enable
both single features and ranges of features that are specific to particular variations of C. Why bother,
you ask? The most common reason to compile code for a specific dialect of C is for portability. If you
write code that might be compiled with several different tools, you can check for that code’s adher-
ence to a given standard using GCC support for various dialects and standards. Verifying adherence
to various standards is one method developers use to reduce the risk of running into compile-time
and runtime problems when code is moved from one platform to another, especially when the new
platform was not considered when the program was originally written.
What then is wrong with vanilla ISO/ANSI C? Nothing that has not been corrected by officially
ordained corrections. The original ANSI C standard, prosaically referred to as C89, is officially known
as ANSI X3.159-1989. It was ratified by ANSI in 1989 and became an ISO standard, ISO/IEC9989:1990
to be precise, in 1990. Errors and slight modifications were made to C89 in technical corrigenda
published in 1994 and 1996. A new standard, published in 1999, is known colloquially as C99 and
officially as ISO/IEC9989:1999. The freshly minted C99 standard was amended by a corrigendum
issued in 2001. This foray into the alphabet soup of standards explains why options are available for
supporting multiple dialects of C. I’ll explain how to use them a little later in this section.
In addition to the subtle variations that exist in standard C, some of the gcc C dialect options
enable you to select the degree to which gcc complies with the standard. Other options enable you
to select which C features you want. There is even a switch that enables limited support for traditional
(pre-ISO, pre-ANSI) C. But enough discussion. Table 1-1 lists and briefly describes the options that
control the C dialect to which gcc adheres during compilation.
Table 1-1. C Dialect Command-Line Options
Option Description
-ansi Supports all ISO C89 features and disables GNU extensions that
conflict with the C89 standard.
-aux-info file Saves prototypes and other identifying information about functions
declared in a translation unit to the file identified by file.
-fallow-single-precision Prevents promotion of single-precision operations to
double-precision.
VonHagen_5858 C01.fm Page 3 Wednesday, July 19, 2006 9:25 AM
4CHAPTER 1 USING GCC’S C COMPILER
-fbuiltin Recognizes built-in functions that lack the __builtin_ prefix.
-fcond-mismatch Allows mismatched types in the second and third arguments of
conditional statements.
-ffreestanding Claims that compilation takes place in a freestanding (unhosted)
environment. Freestanding means that the environment includes
all of the library functions required to operate without loading or
referencing external code. Currently, freestanding implementations
provide all of the functions identified in <float.h>, <limits.h>,
<stdarg.h>, and <stddef.h>. Freestanding 64-bit code also requires
the functions identified in <iso646.h>. Freestanding C99-compliant
code also requires anything referenced in <stdbool.h> and
<stdint.h>. The Linux kernel is a good example of a freestanding
environment.
-fhosted Claims that compilation takes place in a hosted environment,
which means that external functions can be loaded from libraries
such as the standard C library. This is the default value for GCC
compilation. Programs that use external libraries (such as most
applications) are good examples of applications that compile and
execute in a hosted environment.
-fno-asm Disables use of asm, inline, and typeof as keywords, allowing their
use as identifiers.
-fno-builtin Ignores built-in functions that lack the __builtin_ prefix.
-fno-signed-bitfields Indicates that bit fields of undeclared type are to be
considered unsigned.
-fno-signed-char Keeps the char type from being signed, as in the type signed char.
-fno-unsigned-bitfields Indicates that bit fields of undeclared type are to be
considered signed.
-fno-unsigned-char Keeps the char type from being unsigned, as in the type
unsigned char.
-fshort-wchar Forces the type wchar_t to be short unsigned int.
-fsigned-bitfields Indicates that bit fields of undeclared type are to be
considered signed.
-fsigned-char Permits the char type to be signed, as in the type signed char.
-funsigned-bitfields Indicates that bit fields of undeclared type are to be
considered unsigned.
-funsigned-char Permits the char type to be unsigned, as in the type unsigned char.
-fwritable-strings Permits strong constants to be written and stores them in the
writable data segment.
-no-integrated-cpp Invokes an external C preprocessor instead of the
integrated preprocessor.
-std=value Sets the language standard to value (c89, iso9899:1990,
iso9989:199409, c99, c9x, iso9899:1999, iso9989:199x, gnu89, gnu99).
Table 1-1. C Dialect Command-Line Options (Continued)
Option Description
VonHagen_5858 C01.fm Page 4 Wednesday, July 19, 2006 9:25 AM
CHAPTER 1 USING GCC’S C COMPILER 5
Sufficiently confused? Believe it or not, it breaks down more simply than it seems. To begin
with, throw out -aux-info and -trigraphs, because you are unlikely to ever need them. Similarly,
you are advised to not use -no-integrated-cpp because its semantics are subject to change and may,
in fact, be removed from future versions of GCC. If you want to use an external preprocessor, use the
CPP environment variable discussed in Appendix A or the corresponding make variable. Likewise,
unless you are working with old code that assumes it can be scribbled into constant strings, do not
use -fwritable-strings. After all, constant strings should be constant—if you are scribbling on them,
they are variables, so just create a variable. To be fair, however, early C implementations allowed
writable strings (primarily to limit stack space consumption), so this option exists to enable you to
compile legacy code.
The various flags for signed or unsigned types exist to help you work with code that makes
assumptions of the signedness of chars and bit fields. In the case of the char flags (-fsigned-char,
-funsigned-char, and their corresponding negative forms), each machine has a default char type,
which is either signed or unsigned. That is, given the statement
char c;
you might wind up with a char type that behaves like a signed char or an unsigned char on a given
machine. If you pass gcc the -fsigned-char option, it will assume that all such unspecified declara-
tions are equivalent to the statement
signed char c;
The converse applies if you pass gcc the -funsigned-char option. The purpose of these flags
(and their negative forms) is to allow code that assumes the default machine char type is, say, like an
unsigned char (that is, it performs operations on char types that assume an unsigned char), to work
properly on a machine whose default char type is like a signed char. In this case, you would pass gcc
the -funsigned-char option. A similar situation applies to the bit field–related options. In the case of
bit fields, however, if the code does not specifically use the signed or unsigned keyword, gcc assumes
the bit field is signed.
Note Truly portable code should not make such assumptions—that is, if you know you need a specific type
of variable, say an unsigned char, you should declare it as such rather than using the generic type and making
assumptions about its signedness that might be valid on one architecture but not on another.
You will rarely ever need to worry about the -fhosted and -ffreestanding options, but for
completeness’ sake, I’ll explain what they mean and why they are important. In the world of C stan-
dards, an environment is either hosted or freestanding. A hosted environment refers to one in which
the complete standard library is present and in which the program startup and termination occur via
-traditional Supports a limited number of traditional (K&R) C constructs
and features.
-traditional-cpp Supports a limited number of traditional (K&R) C preprocessor
constructs and features.
-trigraphs Enables support for C89 trigraphs.
Table 1-1. C Dialect Command-Line Options (Continued)
Option Description
VonHagen_5858 C01.fm Page 5 Wednesday, July 19, 2006 9:25 AM
6CHAPTER 1 USING GCC’S C COMPILER
a main() function that returns int. In a freestanding environment, on the other hand, the standard
library may not exist and program startup and termination are implementation-defined. The implica-
tion of the difference is just this: in a freestanding implementation (when invoked with -ffreestanding),
the gcc compiler makes very few assumptions about the meaning of function names that exist in the
standard library. So, for example, the ctime() function is meaningless to gcc in freestanding mode.
In hosted mode, which is the default, on the other hand, you can rely on the fact that the ctime()
function behaves as defined in the C89 (or C99) standard.
Note This discussion simplifies the distinction between freestanding and hosted environments and ignores the
distinction the ISO standard draws between conforming language implementations and program environments.
Now, about those options that control to which standards GCC adheres. Taking into account the
command-line options I’ve already discussed, you are left with -ansi, -std, -traditional, -traditional
-cpp, -fno-asm, -fbuiltin, and -fno-builtin. Here again, we can simplify matters somewhat. The
–traditional option enables you to use features of pre-ISO C, and implies -traditional-cpp. These
traditional C features include writable string constants (as with -fwritable-strings), the use of
certain C89 keywords as identifiers (inline, typeof, const, volatile, and signed), and global extern
declarations. You can see by looking at Table 1-1 that -traditional also implies -fno-asm, because
-fno-asm disables the use of the inline and typeof keywords, such as -traditional, and also the
asm keyword. In K&R C, these keywords could be used as identifiers.
The -fno-builtin flag disables recognition of built-in functions that do not begin with the
__builtin_ prefix. What exactly is a built-in function? Built-in functions are versions of functions in
the standard C library that are implemented internally by gcc. Some built-ins are used internally by
gcc, and only by gcc. These functions are subject to change, so they should not be used by non-GCC
developers. Most of gcc’s built-ins, though, are optimized versions of functions in the standard
libraries, intended as faster and more efficient replacements of their externally defined cousins. You
normally get these benefits for free because gcc uses its own versions of, say, alloca() or memcpy()
instead of those defined in the standard C libraries. Invoking the -fno-builtin option disables this
behavior. The GCC info pages document the complete list of gcc’s built-in functions.
The -ansi and -std options, which force varying degrees of stricter adherence to published
C standards documents, imply -fno-builtin. As Table 1-1 indicates, -ansi causes gcc to support all
features of ISO C89 and turns off GNU extensions that conflict with this standard. To be clear, if you
specify -ansi, you are selecting adherence to the C89 standard, not the C99 standard. The options
-std=c89 or -std=iso9899:1990 have the same effect as -ansi. However, using any of these three
options does not mean that gcc starts behaving as a strict ANSI compiler because GCC will not emit
all of the diagnostic messages required by the standard. To obtain all of the diagnostic messages,
you must also specify the options -pedantic or -pedantic-errors. If you want the diagnostics to be
considered warnings, use -pedantic. If you want the diagnostics to be considered errors and thus to
terminate compilation, use -pedantic-errors.
To select the C99 standard, use the option -std=c99 or -std-iso9989:1999. Again, to see all of
the diagnostic messages required by the C99 standard, use -pedantic or -pedantic-errors as previ-
ously described. To completely confuse things, the GNU folks provide arguments to the -std option
that specify an intermediate level of standards compliance. Lacking explicit definition of a C dialect,
gcc defaults to C89 mode with some additional GNU extensions to the C language. You can explicitly
request this dialect by specifying -std=gnu89. If you want C99 mode with GNU extensions, you
should specify, you guessed it, -std=gnu99. The default compiler dialect will change to -std=gnu99
after gcc’s C99 support has been completed.
What does turning on standards compliance do? Depending on whether you select C89 or C99
mode, the effects of -ansi or -std=value include
VonHagen_5858 C01.fm Page 6 Wednesday, July 19, 2006 9:25 AM
CHAPTER 1 USING GCC’S C COMPILER 7
•Disabling the asm and typeof keywords
Enabling trigraphs and digraphs
Disabling predefined macros, such as unix or linux, that identify the type of system in use
Disabling the use of // single-line comments in C code in C89 mode (C99 permits // single-line
comments)
Defining the macro __STRICT_ANSI__ used by header files and functions to enable or disable
certain features that are or are not C89-compliant
Disabling built-in functions that conflict with those defined by the ISO standard
Disabling all GNU extensions that conflict with the standard (GNU extensions to C are discussed
in detail later in this chapter.)
Exploring C Warning Messages
A warning is a diagnostic message that identifies a code construct that might potentially be an error.
GCC’s C compiler also emits diagnostic messages when it encounters code or usage that looks ques-
tionable or ambiguous. Appendix A provides a discussion of the most commonly used options related to
warning messages. This section explores some of the most common warning messages and related
options as they apply to C programs compiled using the GCC C compiler, gcc. See Table A-7 in
Appendix A for a complete list of the warning-related options available in GCC compilers. This section
highlights the use of various warning options as they relate to compiling programs written in the
C language.
When you compile C applications using the –pedantic option, you can also specify -std=version to
indicate against which version of the standard the code should be evaluated. It is a mistake, however
to use -pedantic (and, by extension, -pedantic-errors), even in combination with -ansi, to see if
your programs are strictly conforming ISO C programs. This is the case because these options only
emit diagnostic messages in situations for which the standard requires a diagnostic—the effort to
implement a strict ISO parser would be enormous. In general, the purpose of -pedantic is to detect
gratuitously noncompliant code, disable GNU extensions, and reject C++ and traditional C features
not present in the standard.
Another reason that you cannot use -pedantic to check for strict ISO compliance is that -pedantic
disregards the alternate keywords whose names begin and end with __ and expressions following
__extension__. As a rule, these two exceptions do not apply to user programs because the alternate
keywords and the __extension__ usage is limited (or should be) to system header files, which appli-
cation programs should never directly include.
Note Alternate keywords are discussed later in this chapter in the section titled “Declaring Function Attributes.”
A typical source of trouble in C code emerges from the use of functions in the printf(), scanf(),
strftime(), and strfmon() families. These calls use format strings to manipulate their arguments.
Common problems with these function groups include type mismatches between the format strings
and their associated arguments, too many or too few arguments for the supplied format strings, and
potential security issues with format strings (known generically as format string exploits). The -Wformat
warnings help you to identify and solve these problems.
Specifying the -Wformat option causes gcc to check all calls to printf(), scanf(), and other func-
tions that rely on format strings, making sure that the arguments supplied have types appropriate
to the format string and that the requested conversions, as specified in the format string, are sensible.
VonHagen_5858 C01.fm Page 7 Wednesday, July 19, 2006 9:25 AM
8CHAPTER 1 USING GCC’S C COMPILER
Moreover, if you use -pedantic with -Wformat, you can identify format features not consistent with the
selected standard.
Consider the program shown in Listing 1-1 that uses printf() to print some text to the screen.
Listing 1-1. Source Code for the Sample printme.c Application
#include <stdio.h>
#include <limits.h>
int main (void)
{
unsigned long ul = LONG_MAX;
short int si = SHRT_MIN;
printf ("%d\n", ul);
printf ("%s\n", si);
return 0;
}
There are a couple of problems here. The first printf() statement prints the value of the unsigned
long variable ul using an int format string (%d). The second printf() statement prints the short int
variable si using the %s format string (that is, as a string). Despite these problems, gcc compiles the
program without complaint. It even sort of runs.
$ gcc printme.c -o printme
$ ./printme
2147483647
Segmentation fault
Note Depending on your system, this program may not generate a segmentation fault.
Well, that was ugly. On my test system, the program even crashed because the %s formatting
option tried to use the short int si as a pointer to the beginning of a character string, which it is not.
Now, add the -Wformat option and see what happens:
$ gcc printme.c -o printme -Wformat
printme.c: In function 'main':
printme.c:9: warning: int format, long int arg (arg 2)
printme.c:10: warning: format argument is not a pointer (arg 2)
$ ./printme
2147483647
Segmentation fault
Note Depending on the compiler version, your warning output might be slightly different.
VonHagen_5858 C01.fm Page 8 Wednesday, July 19, 2006 9:25 AM
CHAPTER 1 USING GCC’S C COMPILER 9
This time, the compiler complains about the mismatched types and helpfully tells us where I
can find the problems. The program still compiles, but I can use the -Werror option to convert the
warning to a hard error that terminates compilation:
$ gcc printme.c -o printme -Wformat -Werror
cc1: warnings being treated as errors
printme.c: In function 'main':
printme.c:9: warning: int format, long int arg (arg 2)
printme.c:10: warning: format argument is not a pointer (arg 2)
This time, compilation stops after the errors are detected. Once I fix the mismatches, the program
compiles and runs properly. Listing 1-2 shows the corrected program.
Listing 1-2. Printme.c After Corrections
#include <stdio.h>
#include <limits.h>
int main (void)
{
unsigned long ul = LONG_MAX;
short int si = SHRT_MIN;
printf ("%ld\n", ul);
printf ("%d\n", si);
return 0;
}
$ gcc printme.c -o printme -Wformat -Werror
$ ./printme
2147483647
-32768
$
Much better, yes?
For more control over GCC’s format checking, you can use the options -Wno-format-y2k,
-Wno-format-extra-args, and -Wformat-security (only -Wformat is included in the -Wall roll-up
option). By default, if you supply more arguments than are supported by the available format strings,
the C standard says that the extra arguments are ignored. GCC accordingly ignores the extra argu-
ments unless you specify -Wformat. If you want to use -Wformat and ignore extra arguments, specify
-Wno-format-extra-args.
The -Wformat-security option is quite interesting. Format string exploits have become popular
in the world of blackhats in the past few years. Specifying -Wformat and -Wformat-security displays
warnings about format functions that represent potential security breaches. The current implemen-
tation covers printf() and scanf() calls in which the format string is not a string literal and in which
there are no format arguments, such as printf (var);. Such code is problematic if the format string
comes from untrusted input and contains %n, which causes printf() to write to system memory.
Recall that the conversion specifier %n causes the number of characters written to be stored in the
int pointer (int * or a variant thereof)—it is this memory write that creates the security issue.
The options that fall under the -Wunused category (see Table A-7 in Appendix A for a complete
list) are particularly helpful. In optimization passes, gcc does a good job of optimizing away unused
objects, but if you disable optimization, the unused cruft bloats the code. More generally, unused
VonHagen_5858 C01.fm Page 9 Wednesday, July 19, 2006 9:25 AM
10 CHAPTER 1 USING GCC’S C COMPILER
objects and unreachable code (detected with -Wunreachable-code) are often signs of sloppy coding
or faulty design. My own preference is to use the plain -Wunused option, which catches all unused
objects. If you prefer otherwise, you can use any combination of the five specific -Wunused-* options.
Listing 1-3 is a short example of a program with an unused variable.
Listing 1-3. Source Code for the Sample unused.c Application
int main (void)
{
int i = 10;
return 0;
}
As you can see, the program defines the int variable i, but never does anything with it. Here is
GCC’s output when compiling unused.c with no options:
$ gcc unused.c
Well, perhaps I really should have written, “Here is the lack of GCC’s output when compiling
unused.c with no options,” because adding -ansi -pedantic does not change the compiler’s output.
However, here is GCC’s complaint when I use -Wunused:
$ gcc -Wunused unused.c
unused.c: In function 'main':
unused.c:3: warning: unused variable 'i'
Each of the warning options discussed in this section results in similar output that identifies the
translation unit and line number in which a problem is detected, and a brief message describing the
problem. (In the context of program compilation, a translation unit is a separately processed portion
of your code, which usually means the code contained in a single file. It means something completely
different when translating natural languages.) I encourage you to experiment with the warning
options. Given the rich set of choices, you can debug and improve the overall quality and readability
of your code just by compiling with a judiciously chosen set of warning options.
GCC’s C and Extensions
As I remarked at the beginning of this chapter, GCCs C compiler or, rather, GNU C, provides language
features that are not available in ANSI/ISO standard C. The following is an up-to-date summary of
the most interesting of these features:
Local labels: Write expressions containing labels with local scope
Labels as values: Obtain pointers to labels and treat labels as computed gotos
Nested functions: Define functions within functions
Constructing calls: Dispatch a call to another function
Typeof: Determine an expression’s type at runtime using typeof
Zero- and variable-length arrays: Declare zero-length arrays
Variable-length arrays: Declare arrays whose length is computed at runtime
Variadic macros: Define macros with a variable number of arguments
Subscripting: Subscripts any array, even if not an lvalue
Pointer arithmetic: Performs arithmetic on void pointers and on function pointers
Initializers: Assign initializers using variable values
VonHagen_5858 C01.fm Page 10 Wednesday, July 19, 2006 9:25 AM
CHAPTER 1 USING GCC’S C COMPILER 11
Designated initializers: Label elements of initializers
Case ranges: Represent syntactic sugar in switch statements
Mixed declarations: Mix declarations and code
Function attributes: Declare that a function has no side effects or never returns
Variable attributes: Specify attributes of variables
Type attributes: Specify attributes of types
Inline: Defines inline functions (as fast as macros)
Function names: Display the name of the current function
Return addresses: Obtain a function’s return address or frame address
Pragmas: Use GCC-specific pragmas
Unnamed fields: Embed unnamed struct and union fields within named structs and unions
Locally Declared Labels
Each statement expression is a scope in which local labels can be declared. A local label is simply an
identifier; you can jump to it with an ordinary goto statement, but only from within the statement
expression it belongs to. A local label declaration looks like this:
__label__ alabel;
or
__label__ alabel, blabel, ...;
The first statement declares a local label named alabel, and the second one declares two labels
named alabel and blabel. Local label declarations must appear at the beginning of the statement
expression, immediately following the opening brace ({) and before any ordinary declarations.
A label declaration defines a label name, but does not define the label itself. You do this using
name within the statement’s expression to define the contents of the label named name. For example,
consider the following code:
int main(void)
{
__label__ something;
int foo;
foo=0;
goto something;
{
__label__ something;
goto something;
something:
foo++;
}
something:
return foo;
}
This code declares two labels named something. The label in the outer block must be distinguished
from the label in the local block. Local label declaration means that the label must still be unique
with respect to the largest enclosing block. So if you put a label in a macro, you need to give it a
VonHagen_5858 C01.fm Page 11 Wednesday, July 19, 2006 9:25 AM
12 CHAPTER 1 USING GCC’S C COMPILER
mangled name to avoid clashing with a name the user has defined. The local label feature is useful
because statement expressions are often used in macros. If the macro contains nested loops, a goto
can be useful for breaking out of them. However, an ordinary label whose scope is the whole function
cannot be used; if the macro can be expanded several times in one function, the label will be multiply-
defined in that function.
Local labels avoid this problem:
#define SEARCH(array, target) \
({ \
__label__ found; \
typeof (target) _SEARCH_target = (target); \
typeof (*(array)) *_SEARCH_array = (array); \
int i, j; \
int value; \
for (i = 0; i < max; i++) \
for (j = 0; j < max; j++) \
if (_SEARCH_array[i][j] == _SEARCH_target) \
{ value = i; goto found; } \
value = -1; \
found: \
value; \
})
Labels As Values
You can get the address of a label defined in a current function using the operator && (a unary operator,
for you language lawyers). The value has type void *. The label address is a constant value—it can be
used wherever a constant of that type is valid:
void *ptr;
ptr = &&foo;
To use this value, you need to be able to jump to it. With a normal label, you might say goto
ptr;. However, with a label used as a value, you use a computed goto statement:
goto *ptr;
Any expression that evaluates to the type void * is allowed. One way to use these computed
gotos is to initialize static arrays that will serve as a jump table:
static void *jump[] = { &&f, &&g, &&h };
In this case, f, g, and h are labels to which code jumps at runtime. To use one, you index into the
array and select the label. The code to do this might resemble the following:
goto *array[i];
You cannot use computed gotos to jump to code in a different function, primarily because
attempting to do so subverts (or, perhaps, abuses) the local label feature described in the previous
section. Store the label addresses in automatic variables and never pass such an address as an argu-
ment to another function.
VonHagen_5858 C01.fm Page 12 Wednesday, July 19, 2006 9:25 AM
CHAPTER 1 USING GCC’S C COMPILER 13
Nested Functions
A nested function is a function defined inside another function. As you might anticipate, a nested
function’s name is local to the block in which it is defined. To illustrate, consider a nested function
named swap() that is called twice:
f(int i, int j)
{
void swap(int *a, int *b)
{
int tmp = *a;
*a = *b;
*b = tmp;
}
/* more code here */
swap(&i, &j);
}
The nested swap() can access all the variables of the surrounding function that are visible at the
point when it is defined (known as lexical scoping).
Note GNU C++ does not support nested functions.
Nested function definitions are permitted in the same places in which variable definitions are
allowed within functions: in any block and before the first statement in the block.
It is possible to call the nested function from outside the scope of its name by storing its address
or passing the address to another function:
inc(int *array, int size)
{
void swap(int *a, int *b)
{
int tmp = *a;
*a = *b;
*b = tmp;
}
save(swap, size);
}
In this snippet, the address of swap() is passed as an argument to the function save(). This trick
only works if the surrounding function, inc(), does not exit.
If you try to call a nested function through its address after the surrounding function exits, well,
as GCC authors put it, “all hell will break loose.” The most common disaster is that variables that
have gone out of scope will no longer exist and you will end up referencing garbage or overwriting
something else, either of which can be a difficult bug to track down. You might get lucky, but the
path of true wisdom is not to take the risk.
Note GCC uses a technique called trampolines to implement taking addresses of nested functions. You can read
more about this technique at http://gcc.gnu.org/onlinedocs/gccint/Trampolines.html.
VonHagen_5858 C01.fm Page 13 Wednesday, July 19, 2006 9:25 AM
14 CHAPTER 1 USING GCC’S C COMPILER
Nested functions can jump to a label inherited from a containing function, that is, a local label,
if the label is explicitly declared in the containing function, as described in the section “Locally
Declared Labels.”
A nested function always has internal linkage, so declaring a nested function with extern is
an error.
Constructing Function Calls
Using GCC’s built-in functions, you can perform some interesting tricks, such as recording the
arguments a function receives and calling another function with the same arguments, but without
knowing in advance how many arguments were passed or the types of the arguments.
void * __builtin_apply_args();
__builtin_apply_args() returns a pointer to data describing how to perform a call with the
same arguments as were passed to the current function.
void * __builtin_apply(void (*function)(), void *args, size_t size);
__builtin_apply() calls function with a copy of the parameters described by args and size.
args should be the value returned by __builtin_apply_args(). The argument size specifies the size
of the stack argument data in bytes. As you can probably imagine, computing the proper value for
size can be nontrivial, but can usually be done by simply calculating the sum of the sizeof() each of
the parameters. For more complex data structures, it is often easiest to simply specify a sufficiently
large number for size, but this will waste space and is somewhat inelegant.
Similarly, and again without advance knowledge of a function’s return type, you can record that
function’s return value and return it yourself. Naturally, though, the calling function must be prepared to
receive that datatype. The built-in function that accomplishes this feat is __builtin_return().
void __builtin_return(void *retval);
__builtin_return() returns the value described by retval from the containing function. retval
must be a value returned by __builtin_apply().
#include <stdio.h>
int function1(char * string, int number) {
printf("funtion1: %s\n", string);
return number + 1;
}
int function2(char * string, int number) {
void* arg_list;
void* return_value;
arg_list = __builtin_apply_args();
return_value = __builtin_apply( (void*) function1, arg_list, ~CCC
sizeof(char *) + sizeof(int));
__builtin_return(return_value);
}
VonHagen_5858 C01.fm Page 14 Wednesday, July 19, 2006 9:25 AM
CHAPTER 1 USING GCC’S C COMPILER 15
int main(int argc, char ** argv) {
printf("returned value: %d\n", function2("hello there", 42));
return 0;
}
Referring to a Type with typeof
Another way to refer to or obtain the type of an expression is to use the typeof keyword, which shares
its syntax with the ISO C keyword sizeof but uses the semantics of a type name defined with typedef.
Syntactically, typeof’s usage is what you would expect: you can use typeof with an expression or
with a type. With an expression, the usage might resemble the following:
typeof (array[0](1));
As you can see in this example, array is an array of pointers to functions. The resulting type will
be the values of the functions. typeof’s usage with a type name is more straightforward.
typeof (char *);
Obviously, the resulting type will be pointers to char.
Tip If you are writing a header file that must work when included in ISO C programs, write __typeof__ instead
of typeof.
Semantically, typeof can be used anywhere a typedef name would be, which includes declara-
tions, casts, sizeof statements, or even, if you want to be perverse, within another typeof statement.
A typical use of typeof is to create type-safe expressions, such as a max macro that can safely operate
on any arithmetic type and evaluate each of its arguments exactly once:
#define max(a,b) \
({ typeof (a) _a = (a); \
typeof (b) _b = (b); \
_a > _b ? _a : _b; })
The names _a and _b start with underscores to avoid the local variables conflicting with variables
having the same name at the scope in which the macro is called. Additional typeof uses might
include the following, or variations thereof:
typeof (*x) y;: Declares y to be of the type to which x points.
typeof (*x) y[4];: Declares y to be an array of the values to which x points.
typeof (typeof (char *)[4]) y;: Declares y as an array of pointers to characters. Clearly, this
code is more elaborate than the standard C declaration char *y[4];, to which it is equivalent.
Zero-Length Arrays
Zero-length arrays are allowed in GNU C. They are very useful as the last element of a structure that
is really a header for a variable-length object. Consider the following:
VonHagen_5858 C01.fm Page 15 Wednesday, July 19, 2006 9:25 AM
16 CHAPTER 1 USING GCC’S C COMPILER
struct data {
int i;
int j;
}
struct entry {
int size;
struct data[0];
};
int e_sz;
struct entry *e = (struct entry *) malloc(sizeof (struct entry) + e_sz);
e->size = e_sz;
In ISO C89, you must define data[1], giving data a length of 1. This requirement forces you to
waste space (a trivial concern in this example) or, more likely, complicate the malloc() call. ISO C99
allows you to use flexible array members, which have slightly different characteristics:
Flexible array members would be defined as contents[], not contents[0].
C99 considers flexible array members to have incomplete type specifications. You cannot use
sizeof with incomplete types. With GNU C’s zero-length arrays, however, sizeof evaluates
to 0. It is up to you to decide if that is a feature or not.
Most significantly, flexible array members may only appear as the last member of nonempty
structs.
To support flexible array members, GCC extends them to permit static initialization of flexible
array members. This is equivalent to defining two structures where the second structure contains
the first one, followed by an array of sufficient size to contain the data. If that seems confusing,
consider the two structures s1 and s2 defined as follows:
struct f1 {
int x;
int y[];
} f1 = { 1, { 2, 3, 4 } };
struct f2 {
struct f1 f1;
int data[3];
} f2 = { { 1 }, { 2, 3, 4 } };
struct s1 {
int i;
int j[];
} s1 = {1, {2, 3, 4} };
struct s2 {
struct s1 s1;
int array[3];
} s2 = { {1}, {2, 3, 4} };
In effect, s1 is defined as if it were declared as s2.The convenience of this extension is that f1 has
the desired type, eliminating the need to consistently refer to the awkward construction f2.f1. This
extension is also symmetric with declarations of normal static arrays, in that an array of unknown
size is also written with []. For example, consider the following code:
VonHagen_5858 C01.fm Page 16 Wednesday, July 19, 2006 9:25 AM
CHAPTER 1 USING GCC’S C COMPILER 17
struct foo {
int x;
int y[];
};
struct bar {
struct foo z;
};
struct foo a = {1, {2, 3, 4 } }; /* valid */
struct bar b = { { 1, {2, 3, 4 } } }; /* invalid */
struct bar c = { { 1, {} } }; /* valid */
struct foo d[1] = { { 1 {2, 3, 4} } }; /* invalid */
Note This code will not compile unless you are using GCC 3.2 or newer.
Arrays of Variable Length
ISO C99 allows variable-length automatic arrays, which enable you to have a nonconstant expression
for the array size but also have arrays that are preallocated at a fixed size (unlike variable arrays in
Java). Not wanting to limit this very handy feature to C99, GCC accepts variable-length arrays in C89
mode and in C++ (using -std=gcc89). Nevertheless, what ISO C99 giveth, GCC taketh away: GCC’s
implementation of variable-length arrays does not yet conform in all details to the ISO C99 standard.
Variable-length arrays are declared like other automatic arrays, but the length is not a constant
expression. The storage is allocated at the point of declaration and deallocated when the brace level
is exited. For example
FILE *myfopen(char *s1, char *s2, char *mode)
{
char str[strlen (s1) + strlen (s2) + 1];
strcpy(str, s1);
strcat(str, s2);
return fopen(str, mode);
}
Jumping or breaking out of the scope of the array name deallocates the storage. You can use the
function alloca() to get an effect much like variable-length arrays. The function alloca() is available
in many, but not all, C implementations. On the other hand, variable-length arrays are more elegant.
You might find variable-length arrays more straightforward to use because the syntax is more natural.
Should you use an alloca()-declared array or a variable-length array? Before you decide, consider
the differences between these two methods. Space allocated with alloca() exists until the containing
function returns, whereas space for a variable-length array is deallocated as soon as the array name’s
scope ends. If you use both variable-length arrays and alloca() in the same function, deallocation
of a variable-length array will also deallocate anything more recently allocated with alloca(). You
can also use variable-length arrays as arguments to functions.
void f(int len, char data[len])
{
/* function body here */
}
In this example, you can see the function foo() accepts the integer parameter len, which is also
used to specify the size of the array of data. The array’s length is determined when the storage is allo-
cated and is remembered for the scope of the array, in case the length is accessed using sizeof.
VonHagen_5858 C01.fm Page 17 Wednesday, July 19, 2006 9:25 AM
18 CHAPTER 1 USING GCC’S C COMPILER
If you want to pass the array first and the length second, you can use a forward declaration
in the parameter list (which is, by the way, another GNU extension). A forward declaration in the
parameter list looks like the following:
void f(int len; char data[len], int len)
{
/* function body here */
}
The declaration int len before the semicolon, known as a parameter forward declaration,
makes the name len known when the declaration of data is parsed.
You can make multiple parameter forward declarations in the parameter list, separated by
commas or semicolons, but the last one must end with a semicolon. Following the final semicolon,
you must declare the actual parameters. Each forward declaration must match a real declaration in
parameter name and datatype. ISO C99 does not support parameter forward declarations.
Macros with a Variable Number of Arguments
C99 allows declaring macros with a variable number of arguments, just as functions can accept a
variable number of arguments. The syntax for defining the macro is similar to that of a function. For
example:
#define debug(format, ...) fprintf(stderr, format, __VA_ARGS__)
The ellipsis specifies the variable argument. When you invoke such a macro, the ellipsis repre-
sents zero or more tokens until the closing parenthesis that ends the invocation. This set of tokens
replaces the identifier __VA_ARGS__ in the macro body wherever it appears. See the C preprocessor
manual (info cpp) for more information about how GCC processes variadic arguments.
Subscripting Non-lvalue Arrays
A common C language term, lvalues, is a reference to objects that are addressable and can be exam-
ined, but may or may not be assignable. In ISO C99, arrays that are not lvalues still decay to pointers
and can therefore be subscripted, though they cannot be modified or used after the next sequence
point, and the unary & operator cannot be applied to them. (A sequence point is a point in a program’s
execution where all statements whose order of evaluation is potentially ambiguous have been resolved.
The simplest example of a sequence point is the semicolon that terminates any combination of C
statements.) Non-lvalue arrays are therefore arrays whose existence has been declared but to which
explicit values have not been assigned.
As an extension, GCC’s C compiler allows non-lvalue arrays to be subscripted in C89 mode.
For example, the following code is valid in GNU C but not in C89:
#include <stdio.h>
struct foo {
int a[4];
};
struct foo f();
bar(int index)
{
return f().a[index];
}
VonHagen_5858 C01.fm Page 18 Wednesday, July 19, 2006 9:25 AM
CHAPTER 1 USING GCC’S C COMPILER 19
Being able to reference arrays whose elements may not have values simplifies coding, but can
introduce subtle, data-dependent bugs in your code.
Arithmetic on Void and Function Pointers
GNU C supports adding and subtracting pointer values on pointers to void and on pointers to functions.
GCC implements this feature by assuming that the size of a void or a function is 1. As a consequence,
sizeof also works on void and function types, returning 1. The option -Wpointer-arith enables
warnings if these extensions are used.
Nonconstant Initializers
GNU C does not require the elements of an aggregate initializer for automatic variables to be constant
expressions. This is the same behavior permitted by both standard C++ and ISO C99. An initializer
with elements that vary at runtime might resemble the following code:
float f(float f, float g)
{
float beats [2] = { f-g, f+g };
/* function body here */
return beats[1];
}
Designated Initializers
Standard C89 requires initializer elements to appear in the same order as the elements in the array
or structure being initialized. C99 relaxes this restriction, permitting you to specify the initializer
elements in any order by specifying the array indices or structure field names to which the initializers
apply. These are known as designated initializers. GNU C allows this as an extension in C89 mode,
but not—for you C++ programmers—in GNU C++.
To specify an array index, for example, write [index] = before the element value as shown here:
int a[6] = {[4] = 29, [2] = 15};
This is equivalent to
int a[6] = {0, 0, 15, 0, 29, 0};
The index values must be a constant expression, even if the array being initialized is automatic.
To initialize a range of elements with the same value, use the syntax [first ... last]= value.
This is a GNU extension. For example
int widths[] = {[0 ... 9] = 1, [10 ... 99] = 2, [100] = 3};
If value has side effects, the side effects happen only once, rather than for each element
initialized.
In a structure initializer, specify the name of a field to initialize with .member=. Given a structure
triplet that is defined as
struct triplet {
int x, y, z;
};
VonHagen_5858 C01.fm Page 19 Wednesday, July 19, 2006 9:25 AM
20 CHAPTER 1 USING GCC’S C COMPILER
The following code snippet illustrates the proper initialization method:
struct triplet p = {
.y = y_val,
.x = x_val,
.z = z_val
};
This initialization is equivalent to
struct triplet p = {
x_val,
y_val,
z_val
};
The [index] or .member is referred to as a designator.
You can use a designator when initializing a union in order to identify the union element you
want to initialize. For example
union foo {
int i;
double d;
};
The following statement converts 4 to a double to store it in the union using the second element:
union foo f = {
.d = 4
};
In contrast, casting 4 to type union foo would store it in the union as the integer i, because it is
an integer.
You can combine designated initializers with ordinary C initialization of successive elements.
In this case, initializers lacking designators apply to the next consecutive element of the array or
structure. For example, the line
int a[6] = { [1] = v1, v2, [4] = v4 };
is equivalent to
int a[6] = { 0, v1, v2, 0, v4, 0 };
Labeling the elements of an array initializer is especially useful when the indices are characters
or belong to an enum type. For example
int whitespace[256] = {
[' '] = 1, ['\t'] = 1, ['\v'] = 1,
['\f'] = 1, ['\n'] = 1, ['\r'] = 1 };
You can also write a series of .member and [index] designators before = to specify a nested subobject
to initialize; the list is taken relative to the subobject corresponding to the closest surrounding brace
pair. For example, with the preceding struct triplet declaration, you would use the following:
struct triplet triplet_array[10] = { [2].y = yv2, [2].x = xv2, [0].x = xv0 };
VonHagen_5858 C01.fm Page 20 Wednesday, July 19, 2006 9:25 AM
CHAPTER 1 USING GCC’S C COMPILER 21
Note If the same field is initialized multiple times, its value will be from the last initialization. If multiple overridden
initializations have side effects, the standard does not specify whether the side effect will happen or not. GCC
currently discards additional side effects and issues a warning.
Case Ranges
You can specify a range of consecutive values in a single case label like this:
case m ... n:
Spaces around the ellipsis (...) are required. This has the same effect as the proper number of
individual case labels, one for each integer value from m to n, inclusive. This feature is especially
useful for ranges of ASCII character codes and numeric values, as in the following example:
case 'A' ... 'Z':
Mixed Declarations and Code
ISO C99 and ISO C++ allow declarations and code to be freely mixed within compound statements.
The GCC extension to this feature allows mixed declarations and code in C89 mode. For example,
you can write
int i;
/* other declarations here */
i++;
int j = i + 2;
Each identifier is visible from the point at which it is declared until the end of the enclosing
block.
Declaring Function Attributes
GNU C enables you to tell the compiler about certain features or behaviors of the functions in your
program. This is done using keywords that declare function attributes. Function attributes permit
the compiler to optimize function calls and check your code more carefully. The keyword
__attribute__ allows you to specify function attributes. __attribute__ must be followed by an
attribute specification inside double parentheses. The following attributes are currently defined for
functions on all targets:
alias
always_inline
• cdecl
const
constructor
deprecated
destructor
• dllexport
• dllimport
• fastcall
VonHagen_5858 C01.fm Page 21 Wednesday, July 19, 2006 9:25 AM
22 CHAPTER 1 USING GCC’S C COMPILER
• flatten
format
format_arg
malloc
no_instrument_function
noinline
nonull
noreturn
pure
regparm
section
stdcall
unused
used
• warn_unused_result
weak
These attributes are explained throughout the remainder of this section. This list includes x86-
specific attributes, since x86 is the most popular GCC platform. Several other attributes are defined
for functions on particular target systems—these are discussed in Appendix B of this book, which
discusses platform-specific options. Other attributes are supported for variable declarations and
for types.
Tip You can also specify attributes by embedding each keyword between double underscores (__). This alter-
native syntax allows you to use function attributes in header files without being concerned about a possible macro
of the same name. For example, you can write __noreturn__ instead of __attribute__((noreturn)).
The alias attribute enables you to identify a declaration as an alias for an existing, predefined
symbol elsewhere in your code.
Generally, functions are not inline unless optimization is specified. For functions declared inline,
the always_inline attribute inlines the associated function even in the absence of optimization.
Conversely, to prevent a function from ever being considered for inlining, use the function attribute
noinline.
On x86 systems, the cdecl attribute causes the compiler to assume that the calling function will
clean up the stack, removing the storage used to pass arguments. This is useful in conjunction with
the -mrtd switch, which causes calling functions to use the ret NUM convention that pops arguments
off the stack during the return to the calling function.
Many functions do not examine or modify any values except their arguments or have any effect
other than returning a value. Such functions can be given the const attribute. A function that has
pointer arguments and examines the data pointed to must not be declared const. Likewise, a function
that calls a non-const function cannot be const. Naturally, it does not make sense for a const function
to return void.
The deprecated attribute results in a warning if the associated function is used anywhere in the
source file. This attribute is useful to identify functions you expect to remove in a future version of a
VonHagen_5858 C01.fm Page 22 Wednesday, July 19, 2006 9:25 AM
CHAPTER 1 USING GCC’S C COMPILER 23
program. The warning also includes the location of the declaration of the deprecated function,
enabling users to find further information about why the function is deprecated, or what they should
do instead. The warning only occurs when the function’s return value is used. For example
int old_f() __attribute__ ((deprecated));
int old_f();
int (*f_ptr)() = old_f;
The third line generates a warning, but the second line does not.
Tip You can also use the deprecated attribute with variables and typedefs.
The ddlexport and dllimport attributes are only useful when using GCC for Microsoft Windows
or Symbian OS targets, and respectively provide a global pointer to a function and enable access to
a function through a global pointer.
On x86 systems and for functions that pass a fixed number of arguments, the fastcall attribute
tells the compiler to pass the first two arguments in the registers ECX and EDX as an optimization.
Any other arguments are passed on the stack, and are popped by the function that you are calling.
If you are calling a function with a variable number of arguments this attribute is ignored and all
arguments are pushed on the stack.
The flatten attribute tells gcc to inline every instance of a call to a specific function whenever
possible, though whether inlining actually occurs is still dependent on the inlining options specified
on the command line. Like the always_inline attribute, this attribute provides an interesting alter-
native to defining macros when you only want certain functions to be inline whenever possible.
The malloc attribute tells the compiler that a function should be treated as if it were the malloc()
function. The purpose for this attribute is that the compiler assumes that calls to malloc() result in a
pointer that cannot alias anything. This will often improve optimization specifically during alias
analysis (see Chapter 5 for discussion of GCC alias analysis during optimization).
The nonnull (arg-index, ...) attribute is useful to check that function parameters are nonnull
pointers, and takes a list of such arguments. Using this attribute generates a warning if any of the
specified arguments are actually NULL. If no parenthesized argument list is supplied, all parameters
are verified not to be NULL.
A few standard library functions, such as abort() and exit(), cannot return (they never return
to the calling function). GCC automatically knows this about standard library functions and its own
built-in functions. If your own code defines functions that never return, you can declare them using
the noreturn attribute to tell the compiler this fact. For example
void bye(int error) __attribute__ ((noreturn));
void bye(int error)
{
/* error handling here*/
exit(1);
}
The noreturn keyword tells the compiler to assume that bye() cannot return. The compiler can
then optimize without needing to consider what might happen if bye() does return, which can result
in slightly better code. Declaring functions noreturn also helps avoid spurious warnings about
uninitialized variables. However, you should not assume that registers saved by the calling function
are restored before calling the noreturn function. If a function does not return and is given the
noreturn attribute, it should not have a return type other than void.
VonHagen_5858 C01.fm Page 23 Wednesday, July 19, 2006 9:25 AM
24 CHAPTER 1 USING GCC’S C COMPILER
Many functions have no effects to return a value. Similarly, such functions’ return values often
depend only on the function parameters and/or global variables. As you will learn in Chapter 5, such
functions can easily be optimized during common subexpression elimination and loop optimization,
just as arithmetic operators would be. Such functions should be declared with the pure attribute.
For example, the following function declaration asserts that the cube() function is safe to opti-
mize using common subexpression elimination:
int cube(int i) __attribute__ ((pure));
Functions that might benefit from declaration as pure functions include functions that resemble
strlen() and memcmp(). Functions you might not want to declare using the pure attribute include
functions with infinite loops and those that depend on volatile memory or other system resources.
The issue with such functions is that they depend on values that might change between two consec-
utive calls, such as feof() in a multithreading environment.
Similar to the fastcall attribute, the regparm (number) attribute causes the compiler to pass up
to number integer arguments in registers EAX, EDX, and ECX instead of on the stack. Like fastcall,
this only applies to functions that take a fixed number of arguments—functions that take a variable
number of arguments will continue to be passed all of their arguments on the stack.
On x86 systems, the stdcall attribute causes the compiler to assume that the function that is
being called will clean up the stack space used to pass arguments.
The function attribute unused means that it might not be used and that this is acceptable. Accord-
ingly, GCC will omit producing a warning for this function. Likewise, the used function attribute
declares that code must be emitted for the function even if it appears that the function is never refer-
enced. This is useful, for example, when the function is referenced only in inline assembly.
The warn_unused_result attribute causes a warning to be emitted if a caller of the function with
this attribute does not use its return value. This can be extremely useful in detecting potential security
problems or a definite bug, such as with the realloc function.
Note GNU C++ does not currently support the unused attribute because definitions without parameters are
valid in C++.
Before the language lawyers among you start complaining that ISO C’s pragma feature should
be used instead of __attribute__, consider the following points the GCC developers make in the
GCC Texinfo help file:
At the time __attribute__ was designed, there were two reasons for not using #pragma:
1. It is impossible to generate #pragma commands from a macro.
2. There is no telling what the same #pragma might mean in another compiler.
These two reasons applied to almost any application that might have been proposed for #pragma.
It was basically a mistake to use #pragma for anything.
The first point is somewhat less relevant now, because the ISO C99 standard includes _Pragma,
which allows pragmas to be generated from macros. GCC-specific pragmas (#pragma GCC), more-
over, now have their own namespace. So why does __attribute__ persist? Again, GCC developers
explain that “it has been found convenient to use __attribute__ to achieve a natural attachment of
attributes to their corresponding declarations, whereas #pragma GCC is of use for constructs that do
not naturally form part of the grammar.”
VonHagen_5858 C01.fm Page 24 Wednesday, July 19, 2006 9:25 AM
CHAPTER 1 USING GCC’S C COMPILER 25
Specifying Variable Attributes
You can also apply __attribute__ to variables. The syntax is the same as for function attributes. GCC
supports ten variable attributes:
aligned
deprecated
mode
nocommon
packed
section
transparent_union
unused
vector_size
weak
To specify multiple attributes, separate them with commas within the double parentheses: for
example, __attribute__ ((aligned (16),packed)). GCC defines other attributes for variables on
particular target systems. Other front ends might define more or alternative attributes. For details,
consult the GCC online help (info gcc).
The aligned (n) attribute specifies a minimum alignment of n bytes for a variable or structure
field. For example, the following declaration tells the compiler to allocate a global variable j aligned
on a 16-byte boundary:
int j __attribute__ ((aligned (16))) = 0;
You can also specify the alignment of structure fields. For example, you can create a pair of ints
aligned on an 8-byte boundary with the following declaration:
struct pair {
int x[2] __attribute__ ((aligned (8)));
};
If you choose, you can omit a specific alignment value and simply ask the compiler to align a
variable or a field in a way that is appropriate for the target.
char s[3] __attribute__ ((aligned));
An aligned attribute lacking an alignment boundary causes the compiler to set the alignment
automatically to the largest alignment ever used for any datatype on the target machine. Alignment
is a valuable optimization because it can often make copy operations more efficient. How? The
compiler can use native CPU instructions to copy natural memory sizes when performing copies to
or from aligned variables or fields.
Tip The aligned attribute increases alignment; to decrease it, specify packed as well.
The deprecated attribute has the same effect and behavior for variables as it does for functions.
The mode (m) attribute specifies the datatype for the declaration with a type corresponding to
the mode m. In effect, you declare an integer or floating-point type by width rather than type. Similarly,
VonHagen_5858 C01.fm Page 25 Wednesday, July 19, 2006 9:25 AM
26 CHAPTER 1 USING GCC’S C COMPILER
you can specify a mode of byte or __byte__ to declare a mode of a one-byte integer; word or __word__
for a one-word integer mode, or pointer or __pointer__ for the mode used to represent pointers.
The packed attribute requests allocating a variable or struct member with the smallest possible
alignment, which is 1 byte for variables and 1 bit for a field. You can specify a larger alignment with
the aligned attribute. The following code snippet illustrates a struct in which the field s is packed,
which means that s immediately follows index—that is, there is no padding to a natural memory
boundary.
struct node
{
int index;
char s[2] __attribute__ ((packed));
struct node *next;
};
Normally, the compiler places the code objects in named sections such as data and bss. If you
need additional sections or want certain particular variables to appear in special sections, you can
use the attribute section (name) to obtain that result. For example, an operating system kernel
might use the section name .kern_data to store kernel-specific data. The section attribute declares
that a variable or a function should be placed in a particular section.
The following small program, adapted from the GCC documentation, declares several section
names, DUART_A, DUART_B, STACK, and INITDATA:
struct duart a __attribute__ ((section ("DUART_A"))) = { 0 };
struct duart b __attribute__ ((section ("DUART_B"))) = { 0 };
char stack[10000] __attribute__ ((section ("STACK"))) = { 0 };
int init_data __attribute__ ((section ("INITDATA"))) = 0;
int main(void)
{
/* set up stack pointer */
init_sp(stack + sizeof (stack));
/* set up initialized data */
memcpy(&init_data, &data, &edata - &data);
/* enable the serial ports */
init_duart(&a);
init_duart(&b);
}
Note that the sample program uses the section attribute with an initialized definition of a
global variable, such as the four global definitions at the beginning of the program. If you fail to use
an initialized global variable, GCC will emit a warning and ignore the section attribute applied to
uninitialized variable declarations. This restriction exists because the linker requires each object be
defined once. Uninitialized variables are temporarily placed in the .common (or .bss) section and so
can be multiply-defined. To force a variable to be initialized, specify the -fno-common flag or declare
the variable using the nocommon attribute.
Tip Some executable file formats do not support arbitrary sections; so the section attribute is not available on
those platforms. On such platforms, use the linker to map the contents of a module to a specific section.
VonHagen_5858 C01.fm Page 26 Wednesday, July 19, 2006 9:25 AM
CHAPTER 1 USING GCC’S C COMPILER 27
The transparent_union attribute is used for function parameters that are unions. A transparent
union declares that the corresponding argument might have the type of any union member, but that
the argument is passed as if its type were that of the first union member. The unused attribute has the
same syntax and behavior as the unused attribute for functions.
Inline Functions
When you use inline with a function, GCC attempts to integrate that function’s code into its callers.
As an optimization, inline functions make execution faster by eliminating the overhead of function
calls (saving and restoring stack pointers, for example). If the argument values are constant, they can
be optimized at compile time, reducing the amount of function code integrated into the callers.
Although at first sight inlining might seem to inflate code size, this is not necessarily the case. Other
optimizations might allow sufficient code hoisting or subexpression elimination in such a way that
the actual integrated code is smaller.
Although C99 includes inline functions, one of the shortcomings of GCC is that its implementa-
tion of inline functions differs from requirements of the standard. To declare a function inline, use
the inline keyword in its declaration:
inline long cube(long i)
{
return i * i * i;
}
Note If you are writing a header file for inclusion in ISO C programs, use __inline__ instead of inline.
In the absence of the inline attribute, or in addition to it, you can instruct GCC to inline all
“simple enough” functions by specifying the command-line option -finline-functions, where GCC
decides what constitutes a “simple enough” function.
Code constructs that make it impossible (or, at the least, extremely difficult) to inline functions
include using variadic arguments; calling alloca() in the function body; using variable-sized datatypes
(such as variable-length arrays); jumping to computed and nonlocal gotos; calling functions before
their definition; including recursive function calls with a function definition; and nesting functions.
If there is a nonintegrated call, then the function is compiled to assembler code as usual. The func-
tion must also be compiled as usual if the program refers to its address, because that cannot be inlined.
If you need to know when requested inlines can not be implemented, specify the command-
line option -Winline to emit both a warning that a function could not be inlined and an explanation
of why it could not be inlined.
For functions that are both inline and static, that function’s assembly language code will never
be referenced if, first, all calls to that function are integrated into a calling function, and, second, the
integrated function’s address is never taken. Accordingly, GCC will not even emit assembler code for
the function, which you can override by specifying the option -fkeep-inline-functions.
Anticipating future compatibility with C99 semantics for inline functions, GCC’s developers
recommend using only static inline for inline functions. Why? The existing semantics will continue
to function as expected when -std=gnu89 is specified, but the eventual default for inline will be
GCC’s behavior when -std=gnu99 is specified. The issue is that -std=gnu99 will implement the C99
semantics but that it does not yet do so.
VonHagen_5858 C01.fm Page 27 Wednesday, July 19, 2006 9:25 AM
28 CHAPTER 1 USING GCC’S C COMPILER
Tip GCC does not inline any functions when not optimizing unless you specify the always_inline attribute for
the function, such as
inline void f (const char) __attribute__ ((always_inline));
Function Names As Strings
GCC predefines two magic identifiers that store the name of the current function. __FUNCTION__
stores the function name as it appears in the source code; __PRETTY_FUNCTION__ stores the name
pretty printed in a language-specific fashion. In C programs, the two function names are the same,
but in C++ programs, they will probably be different. Consider the following source code from the
file FUNCTION_example.c:
#include <stdio.h>
void here(void)
{
printf("Function %s in %s\n", __FUNCTION__, __FILE__);
printf("Pretty Function %s in %s\n", __PRETTY_FUNCTION__, __FILE__);
}
int main(void)
{
here();
return 0;
}
Running the resulting program, you get the following:
$ ./a.out
Function here in FUNCTION_example.c
Pretty Function here in FUNCTION_example.c
Because __FUNCTION__ and __PRETTY_FUNCTION__ are not macros, #ifdef __FUNCTION__ is mean-
ingless inside a function because the preprocessor does not do anything special with the identifier
__FUNCTION__ (or __PRETTY_FUNCTION__).
A third related, predefined identifier is __LINE__, which holds the current line number in the
source code. As an example, consider the following slightly modified source code from the source
file FUNCTION_example_with_line.c:
#include <stdio.h>
void here(void)
{
printf("Function %s in %s, line %d\n", __FUNCTION__, __FILE__, __LINE__);
printf("Pretty Function %s in %s, line %d\n", __PRETTY_FUNCTION__, \
__FILE__, __LINE__);
}
VonHagen_5858 C01.fm Page 28 Wednesday, July 19, 2006 9:25 AM
CHAPTER 1 USING GCC’S C COMPILER 29
int main(void)
{
here();
return 0;
}
Running the resulting program, you get the following:
$ ./a.out
Function here in FUNCTION_example_with_line.c, line 5
Pretty Function here in FUNCTION_example_with_line.c, line 6
#pragmas Accepted by GCC
GCC supports several types of #pragmas, primarily in order to compile code originally written for
other compilers. Pragmas essentially enable you to embed special instructions when code is compiled
on specific platforms or under specific circumstances—you can think of them as a special case of
platform-specific #ifdef. Note that in general I do not recommend the use of pragmas. In particular,
GCC defines pragmas for ARM, Darwin, Solaris, and Tru64 systems.
ARM #pragmas
ARM targets define #pragmas for controlling the default addition of long_call and short_call
attributes to functions.
long_calls: Enables the long_call attribute for all subsequent functions.
no_long_calls: Enables the short_call attribute for all subsequent functions.
long_calls_off: Disables the long_call and short_call attributes for all subsequent
functions.
Darwin #pragmas
The following #pragmas are available for all architectures running the Darwin operating system.
These are useful for compatibility with other Mac OS compilers.
mark token: Is accepted for compatibility, but otherwise ignored.
options align=target: Sets the alignment of structure members. The values of target may be
mac68k, to emulate m68k alignment, or power, to emulate PowerPC alignment. reset restores
the previous setting.
segment token: Is accepted for compatibility, but otherwise ignored.
unused (var [, var]...): Declares variables as potentially unused, similar to the effect of the
attribute unused. Unlike the unused attribute, #pragma can appear anywhere in variable
scopes.
Solaris #pragmas
For compatibility with the SunPRO compiler, GCC’s C compiler supports the redefine_extname
oldname newname pragma. This #pragma assigns the assembler label newname to the C function
oldname, which is equivalent to the asm label’s extension. The #pragma must appear before the func-
tion declaration. The preprocessor defines __PRAGMA__REDEFINE_EXTNAME if this #pragma is available.
VonHagen_5858 C01.fm Page 29 Wednesday, July 19, 2006 9:25 AM
30 CHAPTER 1 USING GCC’S C COMPILER
Tru64 #pragmas
GCC’s C compiler supports the extern_prefix string #pragma for compatibility with the Compaq
C compiler. #pragma extern_prefix string prefixes the value of string to all subsequent function
and variable declarations. To terminate the effect, use another #pragma extern_prefix with an
empty string. The preprocessor defines __PRAGMA_EXTERN_PREFIX if this #pragma is available.
Objective-C Support in GCC’s C Compiler
Objective-C is an object-oriented superset of C with extensions that provide a message-passing
interface similar to that provided by the Smalltalk-80 language. Objective-C was originally written by
Brad J. Cox and Kurt J. Schmucker at Stepstone Corporation (originally known as Productivity Prod-
ucts International). Objective-C’s primary goal is to add some of the promises of truly reusable code
to the C language by adding some of the core concepts of Smalltalk-80 while leaving behind baggage
such as the fact that most Smalltalk environments ran on virtual machines rather than as stand-
alone compiled code. Unfortunately, the virtual machine concept lives on, to some extent, in Objective-
C’s heavy reliance on a runtime environment, which means that it is not possible to compile stand-
alone (i.e., static) Objective-C code.
Though excellent in both concept and implementation, Objective-C was saved from potential
obscurity by its adoption in 1988 as the default language used for developing NeXTSTEP applica-
tions. NeXTSTEP was the operating system and execution environment used on Steve Jobs’ NeXT
computers, and is now the parent of the Cocoa execution and development environment used on
Mac OS X. Objective-C support was added to GCC’s C compiler, gcc, beginning in 1992, and is
heavily used in the GNUstep project.
The fact that Objective-C is a pure superset of C differentiates it from C++, while its dynamic
typing and other runtime features distinguish it from the other object-oriented languages supported
by GCC, namely C++ and Java. The Objective-C runtime library supports accessing methods and
classes by their string names, does a significant amount of typing at runtime (i.e., when you actually
execute your application), and supports the addition of classes and categories at runtime. There are
actually two standard Objective-C runtime libraries/environments available. If you are running
applications on Mac OS X platforms, you will link against the NeXT runtime library that is present on
that platform—on all other platforms, you will compile and link with gcc’s default Objective-C library.
Regardless of whether you build gcc yourself for the Mac OS X platform or install a precompiled
version as part of Apple’s Xcode tools development environment, its default behavior on OS X
systems is to expect and link with the NeXTSTEP/OS X Objective-C runtime.
IDENTIFYING LIBRARY DEPENDENCIES
Given the differences in capabilities between the GNU and the NeXTSTEP runtimes, it is often useful to identify the
libraries that your application has linked against. This is especially important if you have built your own version of the
Objective-C compiler for your Mac OS X system. By default, Apple’s gcc compiler (provided with its Xcode develop-
ment environment) includes and uses the NeXTSTEP Objective-C runtime. If you’ve built your own gcc, you may be
using its runtime and therefore cannot use all of the capabilities provided by the NeXTSTEP runtime.
The traditional mechanism for listing library dependencies used by the loader to resolve symbols is to use the
ldd program, which is traditionally built and installed as part of the GNU C library, Glibc. On Linux systems and most
other systems with Glibc installed, its output looks something like the following for a traditional Objective-C application:
VonHagen_5858 C01.fm Page 30 Wednesday, July 19, 2006 9:25 AM
CHAPTER 1 USING GCC’S C COMPILER 31
$ ldd hello
libobjc.so.2 => /usr/local/gcc4.1svn/lib64/libobjc.so.2 (0x00002aaaaabc2000)
libgcc_s.so.1 => /usr/local/gcc4.1svn/lib64/libgcc_s.so.1 (0x00002aaaaacde000)
libc.so.6 => /lib64/tls/libc.so.6 (0x00002aaaaadec000)
/lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000)
Okay, maybe that’s not so standard—you can see that I’m using a 64-bit system and running my own version
of gcc, built from the latest Subversion sources. Well, you wanted this book to be up-to-date, right? Regardless, it at
least tells me what libraries my application depends on.
Unfortunately, the ldd application is not provided by default as part of the Xcode gcc environment on Mac OS X
systems. To list library dependencies on OS X systems, you’ll need to use the otool –L command, as in the following
example:
$ otool -L hello
hello:
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 92.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.2)
This example shows that this application uses the standard libraries provided with the default gcc delivered
with Xcode. However, after compiling my application with a hand-built version of gcc for OS X, I get the following output:
$ otool -L hello
hello:
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
/usr/local/lib/libgcc_s.1.0.dylib (compatibility version 1.0.0,
current version 1.0.0)
/usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 92.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.2)
In this case, my application is still using the default NeXTSTEP runtime, but is using its own version of libgcc,
which should work correctly in the OS X environment. However, if you encounter problems or “new behavior” after
recompiling an existing application with a hand-built version of gcc on Mac OS X systems, it’s worth quickly checking
library dependencies before plunging into an orgy of printf()’s and other more classic diagnostic techniques.
Like the other chapters in this book that explain how to use the GCC compilers for different
languages, this section is not a tutorial on the Objective-C programming language. Some excellent
sites that provide that sort of information include the following:
Objective-C Links, Resources, Stuff: http://www.foldr.org/~michaelw/objective-c/
About Objective-C: http://www.objc.info/about/
Object-Oriented Programming and the Objective-C Language: http://toodarkpark.org/
computers/objc/
The rest of this section discusses the basics of compiling Objective-C code with GCC’s C compiler,
the GCC options that are specific to compiling Objective-C programs, and the highlights of GCC’s
Objective-C runtime library.
VonHagen_5858 C01.fm Page 31 Wednesday, July 19, 2006 9:25 AM
32 CHAPTER 1 USING GCC’S C COMPILER
Compiling Objective-C Applications
Objective-C source code files traditionally have the .m extension. As an example, Listing 1-4 shows
the file hello.m, the traditional hello, world program written in Objective-C.
Listing 1-4. Hello, World Written in Objective-C
#include <objc/Object.h>
#include <stdlib.h>
#include <stdio.h>
@interface Hello:Object
{
// Empty because no instance variables are used
}
- (void)msg;
@end
@implementation Hello
- (void)msg
{
printf("Hello, world!\n");
}
@end
int main(void)
{
id myHello; // id is a generic representation of any Objective-C object
myHello=[Hello new]; // or myHello = [[Hello alloc] init]; for purists
[myHello msg];
[myHello free];
return EXIT_SUCCESS;
}
Note This hello, world example was largely cloned from the example in the Beginners Guide to Objective-C
Programming by Dennis Leeuw and Pascal Bourguignon, available at http://gnustep.made-it.com/BG-
objc. This is a friendly and useful introduction to Objective-C that is humorously sprinkled with lines from “Look
What They’ve Done to My Song, Ma,” by Melanie Safka. No need for YAHWPIO (yet another hello, world program in
Objective-C), though I changed things a bit to make it more readable for this context.
As you can see from this example, the extensions to C provided by Objective-C are defined using
keywords that begin with the @ symbol, and the objects and control constructs defined by those
extensions are invoked within square brackets in your code. The @keyword declarations are typically
put into Objective-C header files, but this is just an example, so I’ve put everything into one file.
Once again, this is not a tutorial on Objective-C programming, but consistent examples are
always a good thing. Table 1-2 summarizes the @keyword statements that are supported in GCC’s
Objective-C implementation.
VonHagen_5858 C01.fm Page 32 Wednesday, July 19, 2006 9:25 AM
CHAPTER 1 USING GCC’S C COMPILER 33
GCC Options for Compiling Objective-C Applications
This section describes the command-line options that are only meaningful for Objective-C and
Objective-C++ programs. Because Objective-C is a superset of C, you can also use C language options
when compiling Objective-C programs, as well as the language-independent GCC options that are
discussed in Appendix A. Similarly, you can use C++ language options when compiling Objective-C++
applications.
A sample example of compiling an Objective-C program using gcc is the following:
gcc –lobjc –o hello hello.m
This example compiles the program shown in Listing 1-4, producing an executable named
hello. If you neglect to include the Objective-C runtime library, you will see error output about
undefined references, as in the following:
Table 1-2. @keyword Statements for GCC’s Objective-C Support
Keyword Definition
@compatibility_alias Enables you to define a class name as equivalent to another
class name. For example, @compatibility_alias foo bar; tells
the compiler that each time it encounters foo as a class name,
it should replace it with bar. The alias must not be the name of
an existing class, and the class that you are aliasing must actually
exist. This keyword is unique to GCC’s Objective-C support.
@implementation Defines the unique methods for a defined class—those that are
not simply inherited from its parent. The definition for a class
implementation is terminated by an @end statement.
@interface Defines a class, its parent (if one exists), and any methods
unique to that class. The definition for each class is terminated
by an @end statement.
@private Used within an @interface definition to identify variables that
are local to a specific class.
@protected Used within an @interface definition to explicitly identify
variables that are inherited by all subclasses (which is the
default behavior of Objective-C class variables).
@protocol Defines a set of methods that classes can conform to.
An @protocol definition is terminated by an @end statement.
@public Used within an @interface definition to identify variables that
are visible everywhere.
@selector Identifies a message in Objective-C.
@synchronized Identifies protected areas of code that must be locked
during execution.
@try/@catch/@finally@throw Associated with the structured error handling capabilities
provided by the NeXT runtime on Mac OS X 10.3 and later
systems. See the section later in this chapter titled “Structured
Error Handling” for more information.
VonHagen_5858 C01.fm Page 33 Wednesday, July 19, 2006 9:25 AM
34 CHAPTER 1 USING GCC’S C COMPILER
Listing 1-4. Sample Error Messages from a Missing Objective-C Library
$ gcc hello.m -o hello
/tmp/ccxAki59.o: In function `main':
hello3.m:(.text+0x2b): undefined reference to `objc_get_class'
hello3.m:(.text+0x3b): undefined reference to `objc_msg_lookup'
hello3.m:(.text+0x5d): undefined reference to `objc_msg_lookup'
hello3.m:(.text+0x81): undefined reference to `objc_msg_lookup'
/tmp/ccxAki59.o: In function `__objc_gnu_init':
hello3.m:(.text+0xab): undefined reference to `__objc_exec_class'
/tmp/ccxAki59.o:(.data+0x208): undefined reference to `__objc_class_name_Object'
collect2: ld returned 1 exit status
You must always specify the –lobjc option when linking an Objective-C program using gcc so
that gcc links in the Objective-C runtime library. The gcc compiler also provides a number of options
that are unique to compiling Objective-C and Objective-C++ programs. These options are shown in
Table 1-3.
Table 1-3. GCC Options for Compiling Objective-C and Objective-C++ Code
Option Definition
-fconstant-string-class=
class-name
Specifies the name of the class (class-name) to use as the name
of the constant string class. See the “Constant String Objects”
section later in this chapter for more information about defining
constant strings and specifying a different name for the constant
string class. If the -fconstant-cfstrings option is also specified,
it will override any -fconstant-string-class setting and cause
@"string" literals to be laid out as constant CoreFoundation strings.
-fgnu-runtime Causes gcc to generate object code compatible with the standard
GNU Objective-C runtime. This is the default on most systems
except for gcc running on the Darwin and Mac OS X platforms.
-fnext-runtime Generates output compatible with the NeXT runtime. This is
the default for Darwin and Mac OS X systems. The macro
__NEXT_RUNTIME__ is predefined if this option is used so that
applications can identify and target the NeXT runtime.
-fno-nil-receivers Causes gcc to assume that the receiver is valid in all Objective-C
message instructions ([receiver message:arg]), enabling the
use of more efficient entry points in the runtime. This option is
only available if you are using the NeXT runtime on Mac OS X
10.3 and later systems.
-fobjc-exceptions Enables syntactic support for structured exception handling in
Objective-C, much like that provided by C++ and Java. This
option is only available if you are using the NeXT runtime on
Mac OS X 10.3 and later systems. See the section titled “Structured
Error Handling” later in this chapter for more information.
VonHagen_5858 C01.fm Page 34 Wednesday, July 19, 2006 9:25 AM
CHAPTER 1 USING GCC’S C COMPILER 35
-freplace-objc-classes Causes gcc to embed a special marker that instructs the loader
not to statically link the current object file into the main
executable, which enables the object file to be dynamically
loaded at runtime using the Mac OS X dynamic loader, dyld.
This option is used with the NeXT runtime’s Fix-and-Continue
debugging mode, where an object file can be recompiled and
dynamically reloaded while a program is running, without needing
to restart an application. This functionality is only available on
Mac OS X 10.3 and later systems.
-fzero-link Suppresses the default behavior of the GNU Objective-C
runtime to use calls to objc_getClass() to identify class entry
points at runtime. When theNeXT runtime is being used, and
class names are known at compile time, gcc replaces calls to
objc_getClass() with static references that are initialized at
load time in order to improve runtime performance. This can
be useful in Zero-Link debugging mode, since it enables indi-
vidual class implementations to be modified during program
execution.
-gen-decls Creates a file named sourcename.decl that contains interface
declarations for all classes encountered in the sourcename.m
file and any included files.
-Wno-protocol Issues a warning for every method in a protocol that is not
implemented by the class that was declared to implement that
protocol and any of its superclasses. The default behavior is to
issue a warning for every method not explicitly implemented in
that specific class.
-Wselector Causes gcc to display warnings if multiple methods of different
types for the same selector are found during compilation. The
check is performed on the list of methods in the final stage of
compilation, including methods for selectors declared with an
@selector() expression. These messages are not displayed if
compilation terminates due to errors, or if the generic GCC
-fsyntax-only option was specified and the program is there-
fore not actually being compiled.
-Wundeclared-selector Causes gcc to display warnings if an @selector() expression
referring to an undeclared selector is encountered. A selector is
considered undeclared if no method with that name has been
declared before the @selector() expression, either explicitly
in an @interface or @protocol declaration, or implicitly in an
@implementation section. This option always performs its checks
as soon as an @selector() statement is encountered, which
enforces the Objective-C coding convention that methods and
selectors must be declared before being used.
-print-objc-runtime-info Causes gcc to generate a C header to stdout that describes the
largest structure that is passed by value in an application, if any.
Table 1-3. GCC Options for Compiling Objective-C and Objective-C++ Code
Option Definition
VonHagen_5858 C01.fm Page 35 Wednesday, July 19, 2006 9:25 AM
36 CHAPTER 1 USING GCC’S C COMPILER
Exploring the GCC Objective-C Runtime
In addition to such standard Objective-C features as dynamic runtime typing, the Objective-C
runtime provides support for specific Objective-C constructs that are present in your code or acti-
vate during its compilation. This section highlights those features and explains how and why they
are used.
Constant String Objects
When compiling Objective-C programs, gcc can generate constant string objects that are instances of the
Objective-C runtime’s NXConstantString class, which is defined in the header file objc/NXConstStr.h.
You must therefore include this header file when using Objective-C’s constant string objects feature.
Constant string objects are declared by defining an identifier consisting of a standard C constant
string that is prefixed with the character @, as in the following example:
id myString = @"this is a constant string object";
The gcc compiler also enables you to define your own constant string class by using the -fconstant
-string-class=class-name command-line option. The class that you specify as a new constant string
class must conform to the same structure as NXConstantString, namely
@interface MyConstantStringClass
{
Class isa;
char *c_string;
unsigned int len;
}
@end
Note The default class name is NXConstantString if you are using GCC’s default GNU Objective-C runtime
library, and is NSConstantString if you are using the NeXT runtime. The discussion in this section focuses on the
standard GNU Objective-C runtime.
When creating a statically allocated constant string object, the compiler copies the specified
string into the structure’s c_string field, calculates the length of the string, inserts that value into the
length field, and temporarily assigns the value NULL to the class pointer. The correct value of that
pointer is determined and filled in at execution time by the Objective-C runtime, either with the
runtime default or any value that you specified as the value of the –fconstant-string-class option.
Note Because you can incrementally compile Objective-C files and subsequently link the resulting object code,
it is possible to specify different constant string classes in different object files using different values of the –fconstant
-string-class option. While not illegal, this is also not suggested, since at a minimum, this is confusing to
everyone but the author of the code and it complicates debugging.
By default, the Objective-C runtime’s NXConstantString class inherits from the Object class.
When defining your own constant string class, you can choose to inherit your customized constant
string class from a class other than Object. Your constant string class doesn’t have to provide any
VonHagen_5858 C01.fm Page 36 Wednesday, July 19, 2006 9:25 AM
CHAPTER 1 USING GCC’S C COMPILER 37
specific methods, but the layout of the data elements in your string class must be compatible with
the layout of the standard class definition.
Executing Code Before Main
The GNU Objective-C runtime enables you to execute code before your program enters the main
function using the +load class load mechanism, which is executed on a per-class and per-category
basis. This can be useful to initialize global variables, correctly bind I/O streams, or perform other
setup/initialization actions before actually sending a message to a class. The standard +initialize
mechanism is only invoked when the first message is sent to a class, which could depend on the
existing state you would like to set up with the +load mechanism.
Though executed on a per-class and per-category basis, the +load directive is not overridden by
category invocations of that directive—instead, these augment the class’s +load directives. If a class
and a category of that class both invoke the +load directive, both methods are invoked. This enables
you to do generic initialization on a class and then refine that initialization for specific categories of
that class.
Garbage Collection
As discussed in Chapter 11, GCC 4.x enables you to optionally configure and build GCC’s Objective-C
compiler to use a new memory management policy and associated garbage collector, known to its
friends as the Boehm-Demers-Weiser conservative garbage collector. When this garbage collector is
used, objects are allocated using a special typed memory allocation mechanism that requires precise
information on where pointers are located inside objects. This information is calculated once per
class, immediately after the class has been initialized.
In GCC 4.x, the class_ivar_set_gcinvisible() runtime function enables you to declare weak
pointer references that are essentially hidden from this garbage collector. This function enables you
to programmatically track allocated objects, yet still allow them to be collected. Weak pointer refer-
ences cannot be global pointers, but can only be members of objects. Every type that is a pointer
type can be declared a weak pointer, including id, Class, and SEL.
Weak pointers are supported through a new type character specifier represented by the ! char-
acter. The class_ivar_set_gcinvisible() function adds or removes this specifier to the string type
description of the instance variable named as its argument, as in the following example for the inter-
face foo:
class_ivar_set_gcinvisible (self, "foo", YES);
Structured Error Handling
The NeXT Objective-C runtime introduced on Mac OS X 10.3 provides structured error-handling
capabilities that should be familiar to most programmers working in object-oriented languages. The
rough structure of this error-handling mechanism is the following:
@try {
@throw expr;
...
}
@catch (AnObjCClass *exc) {
...
@throw expr;
...
VonHagen_5858 C01.fm Page 37 Wednesday, July 19, 2006 9:25 AM
38 CHAPTER 1 USING GCC’S C COMPILER
@throw;
...
}
@catch (AnotherClass *exc) {
...
}
@catch (id allOthers) {
...
}
@finally {
...
@throw expr;
...
}
Only pointers to Objective-C objects can be thrown and caught using this scheme. An @throw
statement may appear anywhere in an Objective-C or Objective-C++ program. When used inside of
an @catch block, the @throw statement need not have an argument, in which case the object caught
by the enclosing @catch block is rethrown. When an object is thrown, it is caught by the nearest
@catch clause capable of handling objects of that type, just as in C++ and Java. You can also specify
an @catch(id ...) clause to catch any exceptions that are not caught by specific @catch clauses. If
provided, an @finally block is executed as soon as the application exists from a preceding @try ...
@catch section. The @finally block is executed regardless of whether any exceptions are thrown,
caught, or rethrown inside the @try ... @catch section, in the same way that the finally clause
works in Java.
Note The Objective-C exception model does not interoperate with C++ exceptions in GCC 4.1 and earlier.
You cannot @throw an exception from Objective-C and catch it in C++, or catch an exception thrown in C++ in
Objective-C.
Synchronization and Thread-Safe Execution
The -fobjc-exceptions switch also enables the use of synchronization blocks for thread-safe execu-
tion, as in the following example:
@synchronized (ObjCClass *guard) {
...
}
When entering an @synchronized block, a thread of execution first checks whether another
thread has already placed a lock on the corresponding guard object. If so, the current thread waits
until the lock is released before proceeding. Once the guard object is unlocked, the current thread
places its own lock on it, executes the code contained in the @synchronized block, and then releases
the lock. Throwing exceptions out of @synchronized blocks will cause the guarding object to be
unlocked properly.
Note Unlike Java, entire methods cannot be marked as @synchronized in GCC’s Objective-C.
VonHagen_5858 C01.fm Page 38 Wednesday, July 19, 2006 9:25 AM
CHAPTER 1 USING GCC’S C COMPILER 39
Type Encoding
The GCC Objective-C compiler generates type encodings for all the types encountered in an appli-
cation. These encodings are used at runtime to find out information about selectors and methods as
well as about objects and classes. Table 1-4 shows the type encodings used by GCC’s Objective-C
and Objective-C++ compilers for basic datatypes, type identifiers, and nonatomic datatypes. Type
identifiers are encoded immediately before the types themselves, but are only encoded when they
appear in method arguments.
Table 1-4. Type Encodings Used by GCC for Types and Type Identifiers
Type Encoding
array [ followed by the number of elements in the array, followed by the type of
those elements; terminated by ]
bit-fields b: followed by the starting position of the bit-field, the type of the bit-field,
and the size of the bit-field. This differs from the encoding used by tradi-
tional Objective-C runtimes, such as the NeXT runtime, in order to allow
bit-fields to be properly handled by runtime functions that compute sizes
and alignments of types that contain bit-fields.
bycopy O
char c
char * *
class #
const r
double d
float f
id @
in n
inout N
int I
long l
long long q
oneway V
out o
pointer ^: followed by the pointed type
SEL :
short s
structure { followed by the name of the structure, the = sign, the type of the members,
and terminated by }
union ( followed by the name of the structure, the = sign, the type of the members,
and terminated by )
VonHagen_5858 C01.fm Page 39 Wednesday, July 19, 2006 9:25 AM
40 CHAPTER 1 USING GCC’S C COMPILER
Note Unnamed data structures are encoded using a question mark as the structure name.
unknown type ?
unsigned char C
unsigned int I
unsigned long L
unsigned long long Q
unsigned short S
void v
Table 1-4. Type Encodings Used by GCC for Types and Type Identifiers (Continued)
Type Encoding
VonHagen_5858 C01.fm Page 40 Wednesday, July 19, 2006 9:25 AM
41
■ ■ ■
CHAPTER 2
Using GCC’s C++ Compiler
This chapter discusses typical usage of the GNU Compiler Collection’s C++ compiler, g++, focusing
on the command-line options and constructs that are specific to g++. GCC’s C++ compiler is tradi-
tionally installed so you can execute it by either the g++ or c++ commands, just as many installations
install cc as a synonym for gcc. This chapter uses g++ in examples and running text because this is
the more traditional name of the executable for the GCC C++ compiler.
GCC Option Refresher
Appendix A discusses the options that are common to all of the GCC compilers and the ways to
customize various portions of the compilation process. But so you don’t have to jump back and forth
in the book, this section provides a quick refresher of basic compiler usage as it applies to the GCC
C compiler. For detailed information, see Appendix A. If you are new to g++ and just want to get
started quickly, you’re in the right place.
The g++ compiler accepts both single-letter options, such as -o, and multiletter options, such as
-ansi. Because it accepts both types of options you cannot group multiple single-letter options
together, as you may be used to doing in many GNU and Unix/Linux programs. For example, the
multiletter option -pg is not the same as the two single-letter options -p -g. The -pg option creates
extra code in the final binary that outputs profile information for the GNU code profiler, gprof. On
the other hand, the -p -g options generate extra code in the resulting binary that produces profiling
information for use by the prof code profiler (-p) and causes gcc to generate debugging information
using the operating system’s normal format (-g).
Despite its sensitivity to the grouping of multiple single-letter options, you are generally free to
mix the order of options and compiler arguments on the gcc command line. That is, invoking g++ as
g++ -pg -fno-strength-reduce -g myprog.c -o myprog
has the same result as
g++ myprog.c -o myprog -g -fno-strength-reduce -pg
I wrote that you are generally free to mix the order of options and compiler arguments because,
in most cases, the order of options and their arguments does not matter. In some situations, order
does matter, if you use several options of the same kind. For example, the -I option specifies the
directory or directories to search for include files. So, if you specify -I several times, gcc searches the
listed directories in the order specified.
Compiling a single source file, myprog.cc, using g++ is easy—just invoke g++, passing the name
of the source file as the argument.
VonHagen_5858 C02.fm Page 41 Tuesday, June 27, 2006 5:28 AM
42 CHAPTER 2 USING GCC’S C++ COMPILER
$ g++ myprog.cc
$ ls -l
-rwxr-xr-x 1 wvh users 13644 Oct 5 16:17 a.out
-rw-r--r-- 1 wvh users 220 Oct 5 16:17 myprog.cc
By default, the result on Linux and Unix systems is an executable file named a.out in the current
directory, which you execute by typing ./a.out. On Cygwin systems, you will wind up with a file
named a.exe that you can execute by typing either ./a or ./a.exe.
To define the name of the output file that g++ produces, use the -o option, as illustrated in the
following example:
$ g++ myprog.cc -o runme
$ ls -l
-rw-r--r-- 1 wvh users 220 Oct 5 16:17 myprog.cc
-rwxr-xr-x 1 wvh users 13644 Oct 5 16:28 runme
If you are compiling multiple source files using g++, you can simply specify them all on the gcc
command line, as in the following example, which leaves the compiled and linked executable in the
file named showdate:
$ g++ showdate.cc helper.cc –o showdate
If you want to compile these files incrementally and eventually link them into a binary, you can
use the –c option to halt compilation after producing an object file, as in the following example:
$ g++ -c showdate.cc
$ g++ -c helper.cc
$ g++ showdate.o helper.o –o showdate
$ ls -l
total 124
-rw-r--r-- 1 wvh users 210 Oct 5 12:42 helper.cc
-rw-r--r-- 1 wvh users 45 Oct 5 12:29 helper.h
-rw-r--r-- 1 wvh users 1104 Oct 5 13:50 helper.o
-rwxr-xr-x 1 wvh users 13891 Oct 5 13:51 showdate
-rw-r--r-- 1 wvh users 208 Oct 5 12:44 showdate.cc
-rw-r--r-- 1 wvh users 1008 Oct 5 13:50 showdate.o
Note All of the GCC compilers “do the right thing” based on the extensions of the files provided on any GCC
command line. Mapping file extensions to actions (for example, understanding that files with .o extensions only
need to be linked) is done via the GCC specs file. Prior to GCC version 4, the specs file was a stand-alone text file
that could be modified using a text editor; with GCC 4 and later, the specs file is built-in and must be extracted
before it can be modified. For more information about working with the specs file, see “Customizing GCC Using Spec
Strings” in Appendix A.
VonHagen_5858 C02.fm Page 42 Tuesday, June 27, 2006 5:28 AM
CHAPTER 2 USING GCC’S C++ COMPILER 43
It should be easy to see that a project consisting of more than a few source code files would
quickly become exceedingly tedious to compile from the command line, especially after you start
adding search directories, optimizations, and other g++ options. The solution to this command-line
tedium is the make utility, which is not discussed in this book due to space constraints (although it
is touched upon in Chapter 8).
Filename Extensions for C++ Source Files
As mentioned in the previous section, all GCC compilers evaluate filename suffixes to identify the
type of compilation that they will perform. Table 2-1 lists the filename suffixes that are relevant to
g++ and the type of compilation that g++ performs for each.
A filename with no recognized suffix is considered an object file to be linked. GCC’s failure
to recognize a particular filename suffix does not mean you are limited to using the suffixes listed
previously to identify source or object files. As discussed in Appendix A, you can use the -x lang
option to identify the language used in one or more input files if you want to use a nonstandard
extension. The lang argument tells g++ the input language to use; and for C++, input files can be
either c++ (a standard C++ source file) or c++-cpp-output (a C++ source file that has already been
preprocessed and therefore need not be preprocessed again).
Note When any GCC compiler encounters a file with one of the suffixes shown in Table 2-1, it treats the file as
a C++ file. Nonetheless, other GCC compilers (such as gcc) do not understand the complete chain of dependencies,
such as class libraries, that C++ programs often require, and do not directly know how to compile C++ code. You
should therefore always use g++ (or c++ if you are in environments that require this name) to invoke GCC’s C++
compiler directly.
Command-Line Options for GCC’s C++ Compiler
As explained in Appendix A, many command-line options are common to all of the compilers in the
GCC suite. Table 2-2 shows the command-line options that are specific to the g++ compiler.
Table 2-1. GCC Filename Suffixes for C++
Suffix Operation
.C C++ source code to preprocess.
.cc C++ source code to preprocess. This is the standard extension for C++ source files.
.cpp C++ source code to preprocess.
.cxx C++ source code to preprocess
.ii C++ source code not to preprocess.
VonHagen_5858 C02.fm Page 43 Tuesday, June 27, 2006 5:28 AM
44 CHAPTER 2 USING GCC’S C++ COMPILER
Table 2-2. Standard C++ Command-Line Options
Option Description
-fabi-version=nSpecifies the version of the C++ application binary interface that
the compiled code should conform to. For GCC versions 3.4 and
greater, the default version is version 2. See the section of this
chapter titled “ABI Differences in g++ Versions” for additional
information.
-fcheck-new Ensures that the pointer returned by the new operator is not NULL
before accessing the allocated storage.
-fconserve-space Puts global variables initialized at runtime and uninitialized
global variables in the common segment, conserving space in
the executable.
-fdollars-in-identifiers Permits the $ symbol in identifiers (the default).
-fms-extensions Allows g++ to omit warnings about nonstandard idioms in the
Microsoft Foundation Classes (MFC).
-fno-access-control Disables access checking.
-fno-const-strings Forces g++ to assign string constants to the char * type, even
though the ISO C++ mandates const char *.
-fno-elide-constructors Instructs g++ to always call the copy constructor rather than using
a temporary to initialize another object of the same type.
-fno-enforce-eh-specs Disables runtime checks for violations of exception handling.
-ffor-scope Limits the scope of variables declared in a for initialization statement
to the end of the for loop. You can specify the –fno-for-scope option
to force the scope of variables declared in a for initialization state-
ment to be the enclosing scope, which is contrary to the ISO standard
but was the behavior in older versions of g++ and in many traditional
C++ compilers.
-fms-extensions Disables pedantic warnings about constructs from the Microsoft
Foundation Classes.
-fno-gnu-keywords Disables the use of typeof as a keyword so it can be used as an
identifier. You can still use the __typeof__ keyword. This option is
implied when using the –ansi option.
-fno-implement-inlines Saves space by not creating out-of-line copies of inline functions
controlled by #pragma statements. Using this option will generate
linker errors if the such functions are not inlined everywhere they
are called.
-fno-implicit-inline-
templates
Saves space by not creating implicit instantiations of inline templates
(see -fno-implicit-templates).
-fno-implicit-templates Saves space by only creating code for explicit instantiations of out-
of-line (noninline) templates.
-fno-nonansi-builtins Disables use of built-ins not required by the ANSI/ISO standard,
including ffs, alloca, _exit, index, bzero, conjf, and related
functions.
-fno-operator-names Disables the use of the and, bitand, bitor, compl, not, or, and xor
keywords as synonyms for those operators.
VonHagen_5858 C02.fm Page 44 Tuesday, June 27, 2006 5:28 AM
CHAPTER 2 USING GCC’S C++ COMPILER 45
The g++ compiler recognizes other options specific to C++, but these options deal with optimi-
zations, warnings, and code generation, so we will discuss them in detail in other chapters. In particular,
the section of Appendix A titled “Enabling and Disabling Warning Messages” provides general infor-
mation about using warning options and includes C++-specific warning options. Chapter 5 covers
C++-specific optimization options. Table 2-3 summarizes warning options that are specific to C++.
-fno-optional-diags Disables nonstandard internal diagnostics, such as when a specific
name is used in different ways within a class.
-fno-rtti Disables generation of runtime type identification information for
classes with virtual functions.
-fno-threadsafe-statics Causes g++ not to generate the additional code required for the
thread-safe initialization of local statics as specified in the C++ ABI.
Using this option can reduce code size in applications that do not
need to be thread-safe.
-fno-weak Causes g++ not to use weak symbol support, even if it is provided
by the linker. This option is intended for use when testing g++, and
should not be used in any other situation.
-fpermissive Converts errors about nonconformant code to warnings, allowing
compilation to continue.
-frepo Allows template instantiation to occur automatically at link time.
Using this option implies the –fno-implicit-templates option.
-fstats Displays statistics about front end processing when compilation
completes. This option is generally only used by the g++ develop-
ment team.
-ftemplate-depth-nPrevents template instantiation recursion going deeper than the
integral value of n.
-fuse-cxa-atexit Registers destructors for static objects with static storage duration
with the __cxa_atexit function rather than atexit.
-fvisibility=value (GCC 4.02 and later) Causes g++ to not export ELF symbols
(Executable and Linking Format, the default binary format used on
systems such as Linux and Solaris) from the current object module
or library when specifying hidden as the value of this option. This
substantially reduces the size of resulting binaries and results in
performance improvements due to symbol table lookup improve-
ments. However, using this option can also cause problems throwing
exceptions across modules with different visibility levels. See the
section “Visibility Attributes and Pragmas for GCC C++ Libraries”
later in this chapter for more information. If this option is not
used, the default visibility value is default, which exports all ELF
symbols across object files and from libraries.
-nostdinc++ Disables searching for header files in standard directories specific
to C++.
Table 2-2. Standard C++ Command-Line Options
Option Description
VonHagen_5858 C02.fm Page 45 Tuesday, June 27, 2006 5:28 AM
46 CHAPTER 2 USING GCC’S C++ COMPILER
ABI Differences in g++ Versions
The C++ application binary interface (ABI) is the binary flip side of the application programming
interface (API) defined by the C++ datatypes, classes, and methods in the include files and libraries
that are provided by a C++ library implementation. A consistent binary interface is required in order
for compiled C++ applications to conform to the binary conventions used in associated C++ libraries
Table 2-3. Warning-Related Options for C++
Option Description
-Wabi Generates a warning when the compiler generates code that is not
compatible with the standard C++ ABI. For GCC versions 3.4 and
greater, the default version is version 2. See the section of this
chapter titled “ABI Differences in g++ Versions” for additional
information.
-Wctor-dtor-privacy Generates a warning when all constructors and destructors in a
class are private and therefore inaccessible.
-Weffc++ Generates a warning for any violation of the stylistic C++ guide-
lines given in Effective C++, Scott Meyers (Addison-Wesley, 2005.
ISBN: 0-321-33487-6).
-Wno-deprecated Does not generate warnings for deprecated C++ features or usage.
-Wno-non-template-friend Does not generate warnings when nontemplated friend functions
are declared within a template. In the C++ language template
specification, a friend must declare or define a nontemplate
function if the name of the friend is an unqualified identifier.
-Wno-pmf-conversions Does not generate a warning when a pointer to a member function is
internally converted to a standard pointer.
-Wnon-virtual-dtor Generates a warning when a class requires a virtual destructor but
declares a nonvirtual destructor. Implied by GCC’s –Wall option
(discussed in Appendix A).
-Wold-style-cast Generates a warning if a traditional C-language-style cast to a
nonvoid type is used within a C++ source file.
-Woverloaded-virtual Generates a warning when a function declaration hides virtual
functions from a base class.
-Wreorder Generates a warning when the order in which members are
initialized in code does not match the order of their use. The g++
compiler automatically records the initialization sequence to
reflect the correct initialization order. Implied by –Wall.
-Wsign-promo Generates a warning when an overloaded operation chooses to
promote a value to a signed type over a conversion to an unsigned
type. Versions of g++ prior to version 3.4 would attempt to preserve
unsigned types, which is contrary to the C++ standard.
-Wstrict-null-sentinel Generates a warning if an uncast NULL is used as a sentinel. A
sentinel value is a value that is not a legitimate value for a particular
input and is used to indicate a “stopping” value. This is a potential
problem because an uncast NULL may have different sizes in different
compiler implementations.
VonHagen_5858 C02.fm Page 46 Tuesday, June 27, 2006 5:28 AM
CHAPTER 2 USING GCC’S C++ COMPILER 47
and related object files for things such as physical organization, parameter passing conventions, and
naming conventions. This consistency is especially critical for specific language support routines,
most notably those used for throwing or catching exceptions.
Most recent C++ compilers conform to a specific ABI, which effectively determines the execution
environments in which code compiled with that compiler can execute correctly (modulo coding
errors, of course—perhaps “execute as written” would be a more precise statement). Beginning with
version 3 of the GNU C++ compiler, g++ conforms to an industry-standard C++ ABI as defined in the
ABI specification at http://www.codesourcery.com/cxx-abi/abi.html. Though this specification was
originally written for 64-bit Itanium systems, it provides generic specifications that apply to any
platform and is the C++ ABI implemented on platforms such as GNU/Linux and BSD systems.
As with other types of libraries, an existing ABI can be extended through versioning. Versioning
enables subsequent library releases to add new symbols and functionality while retaining backward
compatibility with previous releases. Obviously, the reverse is not true—binaries linked with the
latest release of a library cannot execute against libraries that do not support all of the symbols and
functionality provided in the new library.
Versions of g++ prior to version 3.4 use ABI version 1. Versions 3.4 through 4.1 of g++ use ABI
version 2. You cannot use libraries compiled with one version of the C++ ABI with an application
compiled with another. If you are unsure of the version of the C++ ABI that your version of g++ provides,
you can determine this by checking the g++ version using the g++ --version command or by extracting
the ABI identifier from a pseudo-compile using a command like the following:
g++ -E -dM - < /dev/null | awk '/GXX_ABI/ {print $3}'
This command will display 102 for g++ compilers using version 1 of the C++ ABI, and 1002 for
g++ compilers using version 2 of the C++ ABI.
If you are using version 3.4 or later of g++, you should recompile any of your personal or enterprise
code libraries that were compiled with a previous version of g++. If you absolutely must link with or
load libraries compiled by a previous version of g++, you can compile your applications using the
g++ option -fabi-version=n, where n is the version of the C++ ABI that you want your application to
conform to. Using this option to force an older ABI version should really only be viewed as a stopgap—
upgrading all the code and libraries that you depend on to the latest version of the C++ ABI is defi-
nitely “the right thing.”
GNU C++ Implementation Details and Extensions
This book is not a tutorial or reference on writing C++ applications—there are already plenty of
books that do that job and do it well. However, when writing C++ code that you will compile using
the GCC C++ compiler, you can take advantage of a number of extensions to both C++ through the
compiler itself and the Standard C++ library used by g++, libstdc++. This section highlights the most
significant extensions that are provided by both, as of the time this book was written, and discusses
some differences in behavior you may see between C++ as defined by the C++ specification and the
compilation and behavior of C++ code compiled using the GCC C++ compiler.
Attribute Definitions Specific to g++
In addition to the visibility attributes, discussed later in this chapter in the section titled “Visibility
Attributes and Pragmas for GCC C++ Libraries,” g++ supports two additional attributes that are
explicitly designed for use in C++ applications. These are the init_priority(priority) and
java_interface attributes.
VonHagen_5858 C02.fm Page 47 Tuesday, June 27, 2006 5:28 AM
48 CHAPTER 2 USING GCC’S C++ COMPILER
Note The function attributes discussed in the section of Chapter 1 titled “Declaring Function Attributes” can also
be used with C++ applications. When using format attributes such as nonnull with C++ methods, you may want
to test all parameters (by not specifying one or more argument indices) rather than trying to identify specific parameters,
because g++ may internally add parameters to a call because such attributes apply to an entire type.
The init_priority Attribute
The init_priority(priority) attribute enables user control over the order in which objects defined in
a namespace scope are initialized. Normally, objects are initialized in the order in which they are
defined within a translation unit. The init_priority attribute takes a single argument, which is an
integer value between 101 and 65,535 (inclusive), where lower numbers indicate a higher priority.
For example, in the following pseudo-code, class MyClass would be initialized before class YourClass:
class MyClass
{
};
class YourClass
{
__attribute__ ((visibility("default"))) void MyMethod();
};
To reverse the order in which these are initialized, you could modify this code to look some-
thing like the following:
class MyClass
{
__attribute__ ((init_priority(65535)));
};
class YourClass
{
__attribute__ ((init_priority(101)));
};
Only the relative ordering of the priority values that you specify matter—the specific numeric
values that you use do not.
The java_interface Attribute
The java_interface type attribute informs g++ that the class is a Java interface, and can only be used
with classes that are declared within an extern “Java” block. Calls to methods declared in this class
are called using the GCC Java compiler’s interface table mechanism, instead of the regular C++ virtual
function table mechanism.
Tip Remember that Java’s runtime requires a fair amount of initialization that must occur before you call Java
methods. When combining C++ and Java code, it is simplest to write your main program in Java so that the initial-
ization is guaranteed to occur before any Java method calls.
VonHagen_5858 C02.fm Page 48 Tuesday, June 27, 2006 5:28 AM
CHAPTER 2 USING GCC’S C++ COMPILER 49
C++ Template Instantiation in g++
Templates are one of the most interesting and useful features of C++, reducing code size and the
amount of duplicate code, encouraging reusability, and simplifying debugging and code maintenance.
Templates are also very useful for enforcing type checking at compile time. For example, using
templates eliminates the need for passing a void pointer, since you can define a template and then
an instance of the template with the expected types.
The GCC g++ compiler extends the standard ISO template definition by adding three capabilities:
Support for forward declaration of explicit instantiations by using the extern keyword.
The ability to instantiate the support data required by the compiler for a named template
class without actually instantiating it by using the inline keyword.
The ability to only instantiate the static data members of a class without instantiating support
data or member functions by using the static keyword.
In general, GCC’s g++ compiler supports both the Borland and Cfront (AT&T) template models.
To support the Borland model of template instantiation and use, g++ provides the –frepo option to
enable template instances for each translation unit that uses them to be generated at compile time
by the preprocessor, which stores them in files with the .rpo extension. These files are subsequently
included in the compilation process and are collapsed into single instances within compilation
units by the linker. To support the Cfront model, g++ internally maintains a repository of template
instances and integrates them into code that uses them at link time. The Cfront model requires that
code that uses templates either explicitly instantiates them or includes a declaration file so the
template definitions are available for instantiation. You can explicitly instantiate the templates you
use at any point in your code or in a single file that you include. In the latter case, you may want to
compile your code without the -fno-implicit-templates option, so you only get all of the instances
required by your explicit instantiations.
Function Name Identifiers in C++ and C
GCC compilers predefine two identifiers that store the name of the current function. The __FUNCTION__
identifier stores the function name as it appears in the source code; while __PRETTY_FUNCTION__
stores the name pretty printed in a language-specific fashion. In C programs, the two function names
are the same, but in C++ programs they are usually different. To illustrate, consider the following
code from a program named FUNCTION_example.cc:
#include <iostream>
using namespace std;
class c {
public:
void method_a(void)
{
cout << "Function " << __FUNCTION__ << " in " << __FILE__ << endl;
cout << "Pretty Function " << __PRETTY_FUNCTION__ << " in "
<< __FILE__ << endl;
}
};
VonHagen_5858 C02.fm Page 49 Tuesday, June 27, 2006 5:28 AM
50 CHAPTER 2 USING GCC’S C++ COMPILER
int main(void)
{
c C;
C.method_a();
return 0;
}
At runtime, the output is:
$ ./a.out
Function method_a in FUNCTION_example.cc
Pretty Function void c::method_a() in FUNCTION_example.cc
In C++, __FUNCTION__ and __PRETTY_FUNCTION__ are variables. On the other hand, because they
are not macros, #ifdef __FUNCTION__ is meaningless inside a function because the preprocessor
does not do anything special with the identifier __FUNCTION__ (or __PRETTY_FUNCTION__).
For a discussion of the same concept in GCC’s C compiler, see the section “Function Name As
Strings” in Chapter 1.
Note If you are updating existing code to work with GCC 3.2 and later, these newer GCC versions
handle __FUNCTION__ and __PRETTY_FUNCTION__ the same way as __func__, which is defined by the
C99 standard as a variable. Versions of GCC’s C compiler prior to version 3.2 defined __FUNCTION__ and
__PRETTY_FUNCTION__ as string literals, meaning that they could be concatenated with other string literals in
character string definitions.
Minimum and Maximum Value Operators
GCC’s g++ compiler adds the <? and >? operators, which, respectively, return the minimum and
maximum of two integer arguments. For example, the following statement would assign 10 to the
min variable:
min = 10 <? 15 ;
Similarly, the following statement would assign 15 to the max variable:
max = 10 >? 15;
Tip Because these operators are language primitives, they can also be overloaded to operate on any class or
enum type.
Using Java Exception Handling in C++ Applications
The Java and C++ exception handling models differ, and though g++ tries to guess when your C++
code uses Java exceptions, it is always safest to explicitly identify such situations to avoid link fail-
ures. To tell g++ that a block of code may use Java exceptions, insert the following pragma in the
current translation unit before any code that catches or throws exceptions:
#pragma GCC java_exceptions
You cannot mix Java and C++ exceptions in the same translation unit.
VonHagen_5858 C02.fm Page 50 Tuesday, June 27, 2006 5:28 AM
CHAPTER 2 USING GCC’S C++ COMPILER 51
Visibility Attributes and Pragmas for GCC C++ Libraries
A traditional problem when writing C++ libraries is that the number of visible ELF symbols can
become huge, even when symbols are not used externally and therefore need not be made public.
GCC versions 4.02 and later provide the new –fvisibility=value option and related internal
attributes to enable you to control this behavior in a fashion similar to the mechanism provided by
__declspec(dllexport) in Microsoft’s C++ compilers. The new –fhidden option takes two possible
values: default, to continue to export all symbols from the current object file (which is the default
value if this option is not specified), and hidden, which causes g++ not to export the symbols from
the current object module. These two visibility cases are reflected by two new per-function/class
attributes for use in C++ applications: __attribute__ ((visibility("default"))) and
__attribute__ ((visibility("hidden"))).
By default, ELF symbols are still exported. To prevent ELF symbols from being exported from
a specific object file, use the –fvisibility=hidden option when compiling that file. This can lead to
increased complexity when creating a C++ library using a single Makefile because it requires that
you either set manual compilation options for each object file contained in a shared library, or that
you add this option to your global compilation flags for the library and therefore do not export any
symbols from any of a shared library’s component object files. This can be a pain and is actually the
wrong thing if you need to make certain symbols visible externally for debugging purposes or for
catching exceptions for throwable entities within a library.
Caution Being able to catch an exception for any user-defined type in a binary other than the one that threw
the exception requires a typeinfo lookup. Because typeinfo information is part of the information that is hidden
by the –fvisibility=hidden option or the visibility __attribute__ attribute specification, you must be
very careful not to hide symbols for any class or method that can throw exceptions across object file boundaries.
The best mechanism for making selected symbols visible is through a combination of using the
visibility attributes and the –fvisibility=hidden command-line option. For any structs, classes, or
methods whose symbols must be externally visible, add the __attribute__
((visibility("default"))) attribute to their definition, as in the following example:
class MyClass
{
int i;
__attribute__ ((visibility("default"))) void MyMethod();
};
You can then add the fvisibility=hidden option to the generic Makefile compilation flags for
all of your object files, which will cause symbols to be hidden for all structs, classes, and methods
that are not explicitly marked with the default visibility attribute. When the source module containing
this code fragment is compiled, symbols are hidden by default, but those for the MyMethod() method
would be externally visible.
A slightly more elegant and memorable solution to symbol visibility is to define a local visibility
macro in a global header file shared by all of the object modules in a library, and then put that macro
in front of the declaration for any class or method definition whose symbols you do not want to
export. In the converse of the previous example, if you want to export symbols by default but restrict
those for selected classes and methods, this might look something like the following:
VonHagen_5858 C02.fm Page 51 Tuesday, June 27, 2006 5:28 AM
52 CHAPTER 2 USING GCC’S C++ COMPILER
#define LOCAL __attribute__ ((visibility("hidden")))
class MyClass
{
int i;
LOCAL void MyMethod();
};
The source module containing this sample code could be compiled without using the
–fvisibility=value option and would export all symbols from MyClass with the exception of
those in the method MyMethod().
A pragma for the new visibility mechanism is currently supported, but will probably go away in
future versions. New code should use visibility __attribute__, but existing class and function
declarations can quickly be converted using the visibility pragma, as in the following example:
extern void foo(int);
#pragma GCC visibility push(hidden)
extern void bar(int);
#pragma GCC visibility pop
In this example, symbols would still be exported from foo() but not from bar(). You must also
be especially careful not to use this pragma with user-defined types that can throw exceptions across
object file boundaries due to the fact that typeinfo information is part of the symbol information
that is hidden, as explained earlier.
VonHagen_5858 C02.fm Page 52 Tuesday, June 27, 2006 5:28 AM
53
■ ■ ■
CHAPTER 3
Using GCC’s Fortran Compiler
It used to be that your first computer science class taught you how to use some variant of FORTRAN, the
FORmula TRANslation language. It also used to be the case that the machines you learned it on had
no GUIs, and they serviced large numbers of users with 256KB of RAM. (Honest!) Times have obviously
changed, so why would anyone care about Fortran nowadays?
Note Since Fortran is pronounced as a word, rather than saying each letter, I will follow the standard by writing
it in initial-cap style rather than in all caps.
If you’re reading this, you certainly care or are at least curious about Fortran and GCC. Regardless of
your motivation, there are a number of good reasons to use Fortran today. Since you are probably
less interested in philosophy than in actually compiling and debugging some Fortran code, we’ll just
hit the highlights:
A vast amount of legacy Fortran is already available and is both time tested and programmer
approved. Unless you need to make substantial changes to existing code, why bother to change
it at all (and risk breaking something) if it already works?
Fortran is a powerful, low-overhead language that was originally designed for scientific
number crunching, and still does a great job at it. It offers a number of language constructs
that are both convenient and highly tuned, such as built-in support for exponentiation of
various data types, complex arithmetic, and very small floating-point numbers, and the
ability to pass variable dimension arrays as arguments to subroutines. It is therefore well-suited
to operations such as huge matrix manipulation operations and other calculation-intensive
operations.
Fortran is a simple language. Fortran code is often much easier to debug than code in more
modern languages because it typically relies on simple data structures and array indices
rather than C constructs such as *foo, &foo, **foo, and so on, which can resemble line noise
or TECO commands.
Some more creative explanations for the continued existence of Fortran can be found in the
Fortran FAQ, which is available on sites such as http://www.faqs.org/faqs/fortran-faq/. However,
the fact that this FAQ hasn’t been updated since January 1997 is a statement in itself. The next
section has some more modern Fortran references.
For a contrarian view, see the petition to retire Fortran at http://www.fortranstatement.com/
cgi-bin/petition.pl.
VonHagen_5858 C03.fm Page 53 Friday, June 9, 2006 5:02 AM
54 CHAPTER 3 USING GCC’S FORTRAN COMPILER
Fortran History and GCC Support
Though you’re probably reading this chapter because you actually want to use the GNU Fortran
compiler, a bit of background on Fortran and GNU Fortran support is always useful.
FORTRAN IS FUN
Just to show that Fortran can indeed be fun, here’s a classic Fortran joke:
GOD is REAL (unless declared INTEGER)
This joke had them rolling in the aisles in the 1960s. But if it just leaves you scratching your head, the idea
behind this joke is that in Fortran, variables with names that begin with the letters I through N are considered to be
integer variables, while variables beginning with any other letters are considered to be real variables (unless explicitly
associated with a specific type using the IMPLICIT statement). I’ll bet you’re laughing now!
Another fun bit of Fortran humor is available in the discussion of the COME FROM statement, originally
published in the December 1973 issue of Datamation, but now available online at http://www.fortran.com/
come_from.html.
Fortran was the first high-level language to escape from research labs and academia into actual
commercial use. Fortran was invented in 1954 by a team of researchers at IBM led by John Backus.
Originally developed for the IBM 701 and known as Speedcoding, Fortran was made commercially
available for the IBM 704, which Backus also helped to design, in 1957. (A PDF version of the original
manual for Fortran on the IBM 704 is available at http://www.fortran.com/FortranForTheIBM704.pdf.) In
recognition of his contributions to computer science by inventing Fortran, Backus was awarded the
National Academy of Engineering’s Charles Stark Draper Prize in 1993, which is the highest prize
awarded in engineering in the United States.
High-level languages are a given today, but in the mid-1950s, the idea of a computer language
that had a logical, abstract syntax that was independent of the architecture or implementation of a
specific computer or instruction set was still fairly revolutionary. This is not to say that Fortran was
invented in 1954 and has continued unchanged to this day. Quite the contrary. The following is a
capsule summary of the different “official” versions of Fortran that have been used as standards
from 1957 until today:
FORTRAN I - (1957, IBM): Became the original version of Fortran.
FORTRAN II - (1958, IBM): Introduced subroutines, functions, and common block. Featured
a primordial three-way if statement based on whether a numeric expression was negative,
zero, or positive.
FORTRAN III - (1958, IBM): Designed in 1958 but never officially released, largely because its
support for inline assembler code was viewed as a violation of the high-level language concept.
Introduced Boolean expressions, which actually saw the light of day in FORTRAN IV.
FORTRAN IV - (1961, IBM): Introduced Boolean expressions and actual if tests based on the
Boolean value of an expression.
FORTRAN 66 - (1966, ANSI Standard X3.9-1966): Became the first official Fortran standard—
36 pages of Fortran fun.
FORTRAN 77 - (1977, ANSI Standard X3.9-1978): Provided an improved I/O facility and new
features for querying, opening, and closing files. Introduced the if-then-else-end if construct
and the character data type for text.
VonHagen_5858 C03.fm Page 54 Friday, June 9, 2006 5:02 AM
CHAPTER 3 USING GCC’S FORTRAN COMPILER 55
Fortran 82, Fortran 8x, Fortran 88: Helped fill the dangerously long gap between FORTRAN 77
and Fortran 90 but were aborted for not producing a new standard.
Fortran 90 - (1990, ANSI Standard X3.198-1992, ISO Standard 1539:1991): Introduced “free-
form” Fortran that was liberated from the punch card–oriented formatting rules of earlier
versions of the language. Also introduced dynamic memory allocation, recursion, CASE state-
ments, array operations, abstract data types, operator overloading, and pointers.
Fortran 95 - (1995, ISO/IEC Standard 1539-1:1997): Introduced the FORALL construct and
user-defined pure and elemental functions. Essentially a minor revision of Fortran 90.
Fortran 2003 - (2003, ISO/IEC Standard 1539-1:2004): Introduced support for IEEE floating-point
arithmetic, exception handling, object-oriented programming, and improved interoperability
with the C language.
A related standard for anyone developing modern Fortran code is IEEE’s POSIX FORTRAN 77
Language Interfaces standard (IEEE Std 1003.9-1992). It defines a standardized interface for accessing
the system services of IEEE Std 1003.1-1990 (POSIX.1), and describes routines to access capabilities
that are not directly available in FORTRAN 77. See http://standards.ieee.org/reading/ieee/
std_public/description/posix/1003.9-1992_desc.html for a table of contents. Unfortunately, the
IEEE folks charge money for copies of their standards. (They are not alone—so does ISO.) You can
view this standard at http://standards.ieee.org/reading/ieee/std/posix/1003.9-1992.pdf if
you’re an IEEE standards online subscriber—otherwise it will redirect you to a page explaining
where to send your hard-earned cash.
The first GNU compiler for Fortran was the g77 compiler by James Craig Burley and a host of
others. As the name suggests, g77 is a FORTRAN 77–compliant Fortran compiler. For a variety of
reasons, work on actively enhancing g77 ceased around the release of GCC 3.0. The decision was
made to write a new Fortran 95–compliant compiler, known as gfortran, rather than do a substantial
rewrite of g77 to bring it into line with the latest GCC internals. Because FORTRAN 77 is essentially a
proper subset of Fortran 95, most existing code that you can compile with g77 can also be compiled
with gfortran. Later in this chapter, the section “Classic GNU Fortran: The g77 Compiler” discusses
the status of g77 and explores issues in migrating and compiling code that was written for use with g77.
Note At the time this book was written, GCC’s gfortran compiler was largely, but not completely, compliant with
Fortran 95. Work toward this goal is actively in progress. Currently, there are still known problems with using
the ENTRY and the NAMELIST declarations, as well as with more advanced uses of MODULES, POINTERS, and
DERIVED TYPES. If you are trying to compile Fortran 95 code that you can’t get to work with gfortran, file a bug
with the GNU folks (http://gcc.gnu.org/bugs.html). If the problem you have encountered is a show-stopper
for you, see the section later in this chapter titled “Alternatives to gfortran and g77.”
Compiling Fortran Applications with gfortran
This section discusses how to compile applications using gfortran and provides sample code that
highlights some of the features of gfortran and the changes in Fortran over the last n years. It begins
by highlighting compilation options that are shared with other compilers in the GCC family.
Common Compilation Options with Other GCC Compilers
Compiling Fortran applications with gfortran is quite straightforward for anyone familiar with other
compilers in the GCC family. Because gfortran depends on many of the core components of GCC,
gfortran shares most of the standard command-line options for GCC compilers. Listing 3-1 shows
VonHagen_5858 C03.fm Page 55 Friday, June 9, 2006 5:02 AM
56 CHAPTER 3 USING GCC’S FORTRAN COMPILER
the output from the gfortran --help command, which lists the standard GCC options that are available
in gfortran. These general options are discussed in Appendix A of this book. Command-line options
that are specific to gfortran (and do not appear in Listing 3-1) are discussed in the section “Command-
Line Options for gfortran,” later in this chapter.
Listing 3-1. Output from the gfortran --help Command
Usage: gfortran [options] file..
Options:
-pass-exit-codes Exit with highest error code from a phase
--help Display this information
--target-help Display target specific command line options
(Use '-v --help' to display command line options of sub-processes)
-dumpspecs Display all of the built in spec strings
-dumpversion Display the version of the compiler
-dumpmachine Display the compiler's target processor
-print-search-dirs Display the directories in the compiler's search path
-print-libgcc-file-name Display the name of the compiler's companion library
-print-file-name=<lib> Display the full path to library <lib>
-print-prog-name=<prog> Display the full path to compiler component <prog>
-print-multi-directory Display the root directory for versions of libgcc
-print-multi-lib Display the mapping between command line options and
multiple library search directories
-print-multi-os-directory Display the relative path to OS libraries
-Wa,<options> Pass comma-separated <options> on to the assembler
-Wp,<options> Pass comma-separated <options> on to the preprocessor
-Wl,<options> Pass comma-separated <options> on to the linker
-Xassembler <arg> Pass <arg> on to the assembler
-Xpreprocessor <arg> Pass <arg> on to the preprocessor
-Xlinker <arg> Pass <arg> on to the linker
-combine Pass multiple source files to compiler at once
-save-temps Do not delete intermediate files
-pipe Use pipes rather than intermediate files
-time Time the execution of each subprocess
-specs=<file> Override built-in specs with the contents of <file>
-std=<standard> Assume that the input sources are for <standard>
--sysroot=<directory> Use <directory> as the root directory for headers
for headers and libraries
-B <directory> Add <directory> to the compiler's search paths
-b <machine> Run gcc for target <machine>, if installed
-V <version> Run gcc version number <version>, if installed
-v Display the programs invoked by the compiler
-### Like -v but options quoted and commands not executed
-E Preprocess only; do not compile, assemble or link
-S Compile only; do not assemble or link
-c Compile and assemble, but do not link
-o <file> Place the output into <file>
-x <language> Specify the language of the following input files
Permissible languages include: c c++ assembler none
'none' means revert to the default behavior of
guessing the language based on the file's extension
Options starting with -g, -f, -m, -O, -W, or --param are automatically
passed on to the various sub-processes invoked by gfortran. In order to pass
other options on to these processes the -W<letter> options must be used.
VonHagen_5858 C03.fm Page 56 Friday, June 9, 2006 5:02 AM
CHAPTER 3 USING GCC’S FORTRAN COMPILER 57
Sample Code
Listing 3-2 uses a Fortran program for displaying numbers in the Fibonacci sequence. This program
prints the first eight values in the Fibonacci sequence. I didn’t write this code, but it serves as a useful
starting point for the discussion of compiling Fortran code in the next section.
Listing 3-2. Sample Fortran Code fib.f90
!
! Hacked Fibonacci program from the web:
! http://cubbi.org/serious/fibonacci/fortran.html
!
PROGRAM MAIN
DO 200, K=0,7
I=K
J=K+1
CALL F(I)
PRINT *,J,'th Fibonacci number is',I
200 CONTINUE
END PROGRAM
!
! Subroutine F(I) calculates the I'th Fibonacci number
! It uses ALGORITHM 2A-3: DATA STRUCTURE - SIMPLE LIST
!
! Modified to begin with 0 - wvh
!
SUBROUTINE F(I)
DIMENSION A(I+1)
A(1)=0; A(2)=1
DO 1, J=3,I+1
A(J)=A(J-1)+A(J-2)
1 CONTINUE
I=A(I+1)
RETURN
END SUBROUTINE
The code shown in Listing 3-2 is vanilla Fortran code that compiles successfully using most
Fortran 90 and Fortran 95 compilers. The name of the file containing this code is fib.f90. I’ve used
Fortran 90–compliant syntax in Listing 3-2 in order to highlight some of the features of gfortran, as
explained in the next section.
Tip You can download the source code for this example and other examples throughout this book from the
Apress Web site at http://apress.com/book/download.html.
Compiling Fortran Code
The most basic gfortran compilation command is the following:
$ gfortran fib.f90
As with all GCC compilers, this command produces a binary named a.out by default. The
output of executing this program is the following:
VonHagen_5858 C03.fm Page 57 Friday, June 9, 2006 5:02 AM
58 CHAPTER 3 USING GCC’S FORTRAN COMPILER
$ ./a.out
1 th Fibonacci number is 0
2 th Fibonacci number is 1
3 th Fibonacci number is 1
4 th Fibonacci number is 2
5 th Fibonacci number is 3
6 th Fibonacci number is 5
7 th Fibonacci number is 8
8 th Fibonacci number is 13
You may have noted that this isn’t the cleanest output. Don’t worry, that’s by design. I’ll clean
this up later in this section as part of an exercise to modernize the code in general.
To identify the name of a specific output file, use the standard GCC -o filename option, as in the
following example:
$ gfortran -o fib fib.f90
This produces the same executable, but gives it the name fib instead of the default name a.out.
gfortran uses the extension of your input program to identify the version of Fortran that your
code conforms to. The following extensions have special meaning to the gfortran compiler:
.f: Interpreted as fixed-form FORTRAN 77 code, with no preprocessing needed
.F: Interpreted as fixed-form Fortran source, but performs preprocessing
.f90: Interpreted as free-form Fortran 90 code, with no preprocessing needed
.F90: Interpreted as free-form Fortran 90 code, but performs preprocessing
.f95: Handled in the same way as code with the .f90 extension
.F95: Handled in the same way as files with the .F90 extension
To demonstrate the implications of your choice of file extension, let’s copy fib.f90 to fib.f to
see if gfortran behaves differently when it treats the input file as a FORTRAN 77 file:
$ cp fib.f90 fib.f
$ gfortran -o fib fib.f
In file wvh_fib.f:17
PROGRAM MAIN
1
Error: Non-numeric character in statement label at (1)
In file wvh_fib.f:17
PROGRAM MAIN
1
Error: Unclassifiable statement at (1)
Well, that was certainly different! In this case, gfortran complained because the PROGRAM
declaration didn’t start in the seventh column, as is required in FORTRAN 77. Listing 3-3 shows the
same code with this correction made.
VonHagen_5858 C03.fm Page 58 Friday, June 9, 2006 5:02 AM
CHAPTER 3 USING GCC’S FORTRAN COMPILER 59
Listing 3-3. FORTRAN 77–Compliant Code Example
!
! Hacked Fibonacci program from the web:
! http://cubbi.org/serious/fibonacci/fortran.html
!
PROGRAM MAIN
DO 200, K=0,31
I=K
J=K+1
CALL F(I)
PRINT *,K,'th Fibonacci number is',I
200 CONTINUE
END PROGRAM
!
! Subroutine F(I) calculates the I'th Fibonacci number
! It uses ALGORITHM 2A-3: DATA STRUCTURE - SIMPLE LIST
!
! Modified to begin with 0 - wvh
!
SUBROUTINE F(I)
DIMENSION A(I+1)
A(1)=0; A(2)=1
DO 1, J=3,I+1
A(J)=A(J-1)+A(J-2)
1 CONTINUE
I=A(I+1)
RETURN
END SUBROUTINE
This program now compiles successfully as a FORTRAN 77 program:
$ gfortran -o fib fib.f
As an alternative to modifying the code to be FORTRAN 77–compliant, you could also use the
-ffree-form option, which tells the gfortran compiler to ignore any formatting requirements that are
associated with a specific version of Fortran, as in the following example:
$ gfortran -o fib -ffree-form fib.f
Modernizing the Sample Fortran Code
The sample code shown in Listings 3-2 and 3-3 is interesting but somewhat primitive, and doesn’t
really match the Fibonacci code we use elsewhere in this book. Modifying the code to behave in the
same way as our Fibonacci code written in C requires changing the code so it can interpret command-
line arguments, display a usage message, and exit if none are provided. This is somewhat outside the
scope of normal Fortran code, but it’s easy enough to do, thanks to some of the extensions that are
built into gfortran. These extensions are explained in detail in the section “gfortran Intrinsics and
Extensions,” later in this chapter.
Listing 3-4 shows an updated version of the same program called fib_cmdline.f90, with command-
line parsing and a usage message added.
VonHagen_5858 C03.fm Page 59 Friday, June 9, 2006 5:02 AM
60 CHAPTER 3 USING GCC’S FORTRAN COMPILER
Listing 3-4. Modernized Sample Code with Command-Line Arguments
!
! Simple program to print a certain number of values
! in the Fibonacci sequence.
!
! Lifted the F(I) routine from:
!
! http://cubbi.org/se