[Bug libfortran/35014] Libgfortran.a (downloaded) is not PIC compiled...

[Bug libfortran/35014] Libgfortran.a (downloaded) is not PIC compiled...

[a.shahmoradi at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014

Amir Shahmoradi <a.shahmoradi at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |a.shahmoradi at gmail dot com

--- Comment #9 from Amir Shahmoradi <a.shahmoradi at gmail dot com> ---
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.

[Bug libfortran/35014] Libgfortran.a (downloaded) is not PIC compiled...

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014

--- Comment #10 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
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.

[Bug libfortran/35014] Libgfortran.a (downloaded) is not PIC compiled...

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org,
                   |                            |iains at gcc dot gnu.org

--- Comment #11 from Iain Sandoe <iains at gcc dot gnu.org> ---
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).

[Bug other/35014] Libgfortran.a (downloaded) is not PIC compiled...

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libfortran                  |other

--- Comment #12 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
No feedback. This is not a libgfortran bug, moving.

[Bug other/35014] Libgfortran.a (downloaded) is not PIC compiled...

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #13 from Iain Sandoe <iains at gcc dot gnu.org> ---
no feedback since 2021.

[Bug other/35014] Libgfortran.a (downloaded) is not PIC compiled...

[a.shahmoradi at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014

--- Comment #14 from Amir Shahmoradi <a.shahmoradi at gmail dot com> ---
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.

[Bug other/35014] Libgfortran.a (downloaded) is not PIC compiled...

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |---

--- Comment #15 from Iain Sandoe <iains at gcc dot gnu.org> ---
(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"

[Bug other/35014] Libgfortran.a (downloaded) is not PIC compiled...

[a.shahmoradi at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014

--- Comment #16 from Amir Shahmoradi <a.shahmoradi at gmail dot com> ---
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.