Documentation PATCH: avoid gcc -shared trouble

Marc Espie
Thu Oct 12 12:30:00 GMT 2000

I'd like the hints given at gcc -shared  to be updated as follows.
The rationale is that failing to provide -fpic or -fPIC (or -msoft-float) 
along with gcc -shared often appears to work, until you use it in a context
where it does not, and you get a weird error.

I got bitten by libtool which forgets to pass -fpic/-fPIC along, as it
happens not to be strictly necessary on a large proportion of tested 
platforms. I believe that those stronger hints will lead a larger proportion
of portable frameworks to do the right thing.

Thu Oct 12 21:27:46 CEST 2000	Marc Espie <>
	* invoke.texi (-shared): Insist on requiring code generation flags
	to be used along with -shared, and document the subtle failures that
	may occur otherwise.

Index: invoke.texi
RCS file: /cvs/gcc/egcs/gcc/invoke.texi,v
retrieving revision 1.224
diff -u -r1.224 invoke.texi
--- invoke.texi	2000/10/11 21:54:31	1.224
+++ invoke.texi	2000/10/12 19:23:58
@@ -3307,9 +3307,15 @@
 @item -shared
 Produce a shared object which can then be linked with other objects to
-form an executable.  Not all systems support this option.  You must
-also specify @samp{-fpic} or @samp{-fPIC} on some systems when
-you specify this option.
+form an executable.  Not all systems support this option.  For predictable
+results, you must also specify the same set of options that were used to 
+generate code (@samp{-fpic}, @samp{-fPIC}, or model suboptions)
+when you specify this option.@footnote{On some systems, @code{gcc -shared}
+needs to build supplementary stub code for constructors to work. On
+multi-libbed systems, @code{gcc -shared} must select the correct support
+libraries to link against.  Failing to supply the correct flags may lead
+to subtle defects. Supplying them in cases where they are not necessary
+is innocuous.}
 @item -symbolic
 Bind references to global symbols when building a shared object.  Warn

More information about the Gcc-patches mailing list