When linking against libgfortran.a (using gfortran's -static-libgfortran option) get message about library should be recompiled with -fPIC option. E.g. when building a shared library: gfortran -c -fPIC test.f90 gfortran -static-libgfortran -shared -o libtest.so test.o >>>>>>>>>>>> CODE for test.f90 <<<<<<<<<< subroutine subber print*,'hi' end >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Using version 4.3.0 20080117 (experimental) on x86-64 suse9.
I think this is by design. Of course given -static-libgfortran, it might make sense to offer both.
Configure gcc with --with-pic.
*** Bug 83340 has been marked as a duplicate of this bug. ***
Reopening to reconsider but really I think you should not be using static-libgfortran with shared libraries.
Why not? Our use case is building a Python module (an .so file loaded by Python) which wraps some Fortran code. We would like to reduce the external dependencies that this module has. There have been some hard-to-track-down runtime errors resulting from libgcc.so version mismatches and we would like to remove this source of errors. We found that libgfortran.so itself depends on libgcc.so, but had hoped that by using the options `-static-libgfortran -static-libgcc' we could eliminate the runtime dependency on libgcc.so completely
What happens if you follow Andrew's advice in comment 2: > Configure gcc with --with-pic. ?
Thanks for the suggestion. I will give it a try. However, we're using a gcc from the distribution - either Ubuntu or Anaconda, depending on the platform. We are not configuring and building our own gcc. Configuring our own gcc is possible, but a lot of extra overhead. However, we'd like our end-users to be able to modify the code and recompile it. Asking end-users to configure and build gcc in order to compile our package is not really an option for us.
(In reply to cgw from comment #7) > Thanks for the suggestion. I will give it a try. > > However, we're using a gcc from the distribution - either Ubuntu or > Anaconda, depending on the platform. We are not configuring and building > our own gcc. > > Configuring our own gcc is possible, but a lot of extra overhead. However, > we'd like our end-users to be able to modify the code and recompile it. > Asking end-users to configure and build gcc in order to compile our package > is not really an option for us. I recently set up an LUbuntu system and yesterady noticed a link error suggesting that one compile with -fPIC. Now I wonder if the problem I am seeing is the same issue. I did compile the application with -fPIC, but it must be the libgfortran that is the problem.
This is an old thread, but the problem does not seem to have been resolved yet, at least as of GFortran 8.3. I agree with cgw@alum.mit.edu on this matter. This looks more like a bug in the design. The user should not need to rebuild an entire GNU Compiler Collection just for the sake of being able to use a compiler flag "-static-libgfortran". The lack of this feature practically makes the GFortran compiler useless in building shared libraries, as it will always have dependencies that most high-level-language users will not have installed on their systems. Requesting them to be able to install the dependencies correctly is too much, IMO. I would appreciate it very much if this build flaw in GFortran gets fixed by also adding positions-independent library builds.
The manual says: > On systems that provide libgfortran as a shared and a static library, > this option forces the use of the static version. If no shared version > of libgfortran was built when the compiler was configured, this option > has no effect. On MacOSX if I compile a simple test, I get a.out: /opt/gcc/gcc11w/lib/libgfortran.5.dylib (compatibility version 6.0.0, current version 6.0.0) /opt/gcc/gcc11w/lib/libgcc_s.2.dylib (compatibility version 2.0.0, current version 2.0.0) /opt/gcc/gcc11w/lib/libquadmath.0.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.0.0) with -static-libgfortran a.out: /opt/gcc/gcc11w/lib/libgcc_s.2.dylib (compatibility version 2.0.0, current version 2.0.0) /opt/gcc/gcc11w/lib/libquadmath.0.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.0.0) and with -static-libgfortran -static-libgcc a.out: /opt/gcc/gcc11w/lib/libquadmath.0.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.0.0) So AFAICT on an OS for which -fpic is the default everything seems to work.
As Dominique says, Darwin defaults to PIC so this works "out of the tin" - but that's not relevant to Linux cases reported here ---- so it seems that what's requested is the shared libgfortran (which is PIC and available) a convenience library with non-PIC code (libgfortran.a) so that the status quo is not broken. a convenience library that has PIC code (e.g. libgfortran_pic.a) and some way to instruct the driver to use that in linking. This would allow a shared lib to be built statically linking libgfortran_pic.a [the same would need to be done of libquadmath and any other dept]. === A work-around might be to package the shared libgfortran.so with your application and make use of rpath to point to it (so that the end-user does not need to install GCC to use the app).
No feedback. This is not a libgfortran bug, moving.
no feedback since 2021.
It's not a bug but a popular requested feature. See, for example, the discussion here: https://fortran-lang.discourse.group/t/distribute-shared-libraries-or-not/7532/1 Are there any downsides to distributing PIC-enabled `libgfortran.a` on all platforms? For consistency, if this is the default behavior on macOS, it should be the default on all platforms.
(In reply to Amir Shahmoradi from comment #14) > It's not a bug but a popular requested feature. See, for example, the > discussion here: > https://fortran-lang.discourse.group/t/distribute-shared-libraries-or-not/ > 7532/1 OK - I will reopen - but really someone needs to propose a patch - otherwise releases just go by. > Are there any downsides to distributing PIC-enabled `libgfortran.a` on all > platforms? yes. For platforms that support non-pic user-space code (e.g. Linux) then this would produce a performance penalty (since the PIC code is typically slower) > For consistency, if this is the default behavior on macOS, it should be the > default on all platforms. I doubt that would be a general agreement. If a given distribution (or use-case) needs the PIC version [and I can totally see why that would be the case for embedding it in a plugin) - then perhaps a suitable solution would be to introduce a specific configuration flag like "--enable-pic-runtimes" or "--enable-pic-libgfortran"
A new optional flag could be a viable (and in my opinion, very good) solution. Unfortunately, I do not have the expertise and experience with gfortran internals to propose and implement a patch for such an option.