To deploy testing versions of applications built with (yet unreleased) versions of gcc may be difficult due to linked in libraries as libgfortran and libgomp. Similar to -static-libgcc, options like -static-libgfortran or -static-libgomp would help to avoid problems. Especially for libgomp, one can not simply use LDFLAGS=-static as libgomp pulls in libpthread and static linking is not supported with libpthread (see PR30471, PR30613).
You may want to look at http://gcc.gnu.org/ml/gcc/2005-12/msg00783.html
In general this is wrong. There are reasons why you don't want static linking. code size/memory usage is one of them.
Andrew, I agree that static linking should not be overused. But there are valid cases where one may want to do it anyway. Deploying a testing application may be one of them. Asking the user to compile gcc from scratch just to get the latest libraries is usually not an option. Delivering a bunch of libraries together with the binary may mess up the customers system, especially if it is a test-and-discard like approach. Given the two PRs I cited plus the thread H. J. pointed out, there are people looking for options like the ones requested here.
I certainly agree that we should have an option to ask the driver to link libgfortran statically.
Still pinging for someone to review my one-line patch to gcc.c... maybe we can get this feature into trunk before GCC 12.0 ;-)
Subject: Bug 31400 Author: fxcoudert Date: Wed Jun 27 22:58:37 2007 New Revision: 126068 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126068 Log: PR other/31400 * gcc.c (process_command): Recognize the new -static-libgfortran option. * lang.opt (static-libgfortran): New option. * gfortranspec.c (ADD_ARG_LIBGFORTRAN): New macro. (Option): Add OPTION_static and OPTION_static_libgfortran. (lookup_option): Handle the new -static-libgfortran option. (lang_specific_driver): Check whether -static is passed. Handle the new -static-libgfortran option. * options.c (gfc_handle_option): If -static-libgfortran is passed and isn't supported on this configuration, error out. Modified: trunk/gcc/ChangeLog trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortranspec.c trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/gcc.c
Fixed on mainline.
FX, thanks for your patch :) As libgfortran is one of many, at least -static-libgomp would be nice to have as well (others?). Reopening, so the request is not lost.
I can contribute a patch for -static-libc++/-static-libstdc++.
-static-libstdc++ was added for 4.5.0 (thanks!): 2009-06-25 Ian Lance Taylor <iant@google.com> * g++spec.c (SKIPOPT): define. (lang_specific_driver): Handle -static-libstdc++. Only add LIBSTDCXX_STATIC if we add LIBSTDCXX. Any chance to ever get -static-libgomp? Otherwise this PR can probably be closed?!
The http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126068 patch adds OPTION_static, but nothing ever returns that value, so the code setting static_linking is clearly dead code. That couldn't be the intent.
(In reply to comment #11) > The http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126068 > patch adds OPTION_static, but nothing ever returns that value, so the code > setting static_linking is clearly dead code. That couldn't be the intent. indeed: how about this? (tested on ia32-pc-linux) Index: gcc/fortran/gfortranspec.c =================================================================== --- gcc/fortran/gfortranspec.c (revision 158167) +++ gcc/fortran/gfortranspec.c (working copy) @@ -186,6 +186,8 @@ lookup_option (Option *xopt, int *xskip, const cha opt = OPTION_syntax_only; else if (!strcmp (text, "-static-libgfortran")) opt = OPTION_static_libgfortran; + else if (!strcmp (text, "-static")) + opt = OPTION_static; else if (!strcmp (text, "-fversion")) /* Really --version!! */ opt = OPTION_version; else if (!strcmp (text, "-Xlinker") || !strcmp (text, "-specs")) @@ -351,8 +353,7 @@ lang_specific_driver (int *in_argc, const char *co #ifdef HAVE_LD_STATIC_DYNAMIC static_linking = 1; #endif - /* Fall through, count OPTION_static as an item included in - the rewritten command line. */ + break; case OPTION_l: ++n_infiles;
Created attachment 20349 [details] check for -static in lookup_option. PR bootstrap/31400 * gfortranspec.c (lookup_option): Check for -static and return OPTION_static. (lang_specific_driver): Break when OPTION_static is discovered.
(In reply to comment #10) > Any chance to ever get -static-libgomp? Otherwise this PR can probably be > closed?! On Darwin - I made it so that if -static-* is given for {stdc++,cc, fortran} the specs cause a substitution for static libgomp. Would that work for you?
(In reply to comment #14) > On Darwin - I made it so that if -static-* is given for {stdc++,cc, fortran} > the specs cause a substitution for static libgomp. Would that work for you? Iain, I can't say as I can't parse your statement?! Could you elaborate a bit? Thanks.
(In reply to comment #15) > (In reply to comment #14) > > On Darwin - I made it so that if -static-* is given for {stdc++,cc, fortran} > > the specs cause a substitution for static libgomp. Would that work for you? > > Iain, I can't say as I can't parse your statement?! Could you elaborate a bit? > Thanks. Sorry ;) - specs processing. It's possible to detect that "-static-libgfortran" has been given on the command line and cause that to substitute libgomp.a instead of libgomp.so. I arranged that this would happen on darwin if any of libgcc, libstdc++ or libgfortran were made static (for reasons of unwind symbol consistency, rather than to satisfy a requirement for static-libgomp). I think it's more difficult to approach libgomp directly - since it doesn't "belong" to any specific language - therefore whatever changes you effect to it need to be coordinated between all FEs. Having said that, there was a comment made that libgomp.spec might be "going away". Does that help?
(In reply to comment #16) > Does that help? Much. Thanks. :) Don't know if this is still a problem, but #0 has: > for libgomp, one can not simply use LDFLAGS=-static as libgomp pulls in > libpthread and static linking is not supported with libpthread Question being, is there a difference between darwin and, say, our average linux box, that allows static linking with the one, but not with the other? In PR30471, comment #7, Jakub once posted a semi work around to this question.
(In reply to comment #17) > Question being, is there a difference between darwin and, say, our average > linux box, that allows static linking with the one, but not with the other? yes, there is a significant difference - threads are part of libSystem on darwin (which is always linked dynamically). So I guess that this is not a solution.
Subject: Bug 31400 Author: iains Date: Tue Apr 13 11:37:34 2010 New Revision: 158262 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158262 Log: gcc/fortran: 2010-04-13 Iain Sandoe <iains@gcc.gnu.org> PR bootstrap/31400 * gfortranspec.c (lookup_option): Check for -static and return OPTION_static. (lang_specific_driver): Break when OPTION_static is discovered. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortranspec.c
I would find the -static-libgomp option useful
(In reply to Matt Arsenault from comment #20) > I would find the -static-libgomp option useful +1