Add -fPIC to build options allowing static linking

[oleid]

Current build breaks linking gfortran statically like in the following snipplet. Building with -fPIC solves the problem.

{
    "name": "lapack",
    "buildsystem": "cmake",
    "builddir": true,
    "build-options": {
        "env": {
            "FFLAGS": "-O2 -fPIC",
            "LDFLAGS": "-static-libgfortran"
        }
    },
    "config-opts": [
        "-DCMAKE_BUILD_TYPE=Release",
        "-DBUILD_SHARED_LIBS=ON",
        "-DBUILD_TESTING=OFF",
        "-DLAPACKE=ON",
        "-DCBLAS=ON"
    ],
    "sources": [
        {
            "type": "archive",
            "url": "http://www.netlib.org/lapack/lapack-3.8.0.tar.gz",
            "sha512": "17786cb7306fccdc9b4a242de7f64fc261ebe6a10b6ec55f519deb4cb673cb137e8742aa5698fd2dc52f1cd56d3bd116af3f593a01dcf6770c4dcc86c50b2a7f"
        }
    ]
}

Error:

/usr/bin/ld: /usr/lib/sdk/gfortran-62/lib/gcc/x86_64-pc-linux-gnu/6.2.0/../../../../lib/libgfortran.a(stop.o): relocation R_X86_64_32 against `.rodata.report_exception.part.0.str1.8' can not be used when making a shared object; recompile with -fPIC

/usr/bin/ld: /usr/lib/sdk/gfortran-62/lib/gcc/x86_64-pc-linux-gnu/6.2.0/../../../../lib/libgfortran.a(transfer.o): relocation R_X86_64_32S against `.rodata.bswap_array' can not be used when making a shared object; recompile with -fPIC
[...]

Fix: static linking of libgfortran

[nanonyme]

Static linking is usually a bad idea. Why's it required here?

[oleid]

Static linking is usually a bad idea. Why's it required here?

IMHO it's a bad idea when using traditional package managers, which actually share the shared library. With flatpak, the shared gfortran library is merely copied to the application's package.

Using static linking, I can reduce the size of a package, which uses only a fraction of the library, link time optimization can reduce the binary size further (both, due to dead code elimination).

Also, the static library is already there, however, it cannot be used, as it's built improperly. Hence the patch.

[nanonyme]

Nope, runtimes and extensions are not copied anywhere. They get updated independent of apps so security fixes and ABI-compatible updates can be done without updating the app. Only things built with the app are part of the app. This is one of the main advantages of Flatpak compared to Snaps. Staticly linking removes that advantage hence it's discouraged generally

[oleid]

Nope, runtimes and extensions are not copied anywhere. They get updated independent of apps so security fixes and ABI-compatible updates can be done without updating the app.

I'm talking about this very script here:

https://github.com/flatpak/freedesktop-sdk-images/blob/1.6/org.freedesktop.Sdk.Extension.gfortran62.json.in#L78

When using gfortran with your app, you need to call this script (/usr/lib/sdk/gfortran-62/install.sh), so that the library is copied to your app bundle. It would seem, that libgfortran and it's dependencies are not part of the official runtime (or as one of it's extension), only the SDK.

Only things built with the app are part of the app. This is one of the main advantages of Flatpak compared to Snaps. Staticly linking removes that advantage hence it's discouraged generally

I only want to link the stuff statically, which is shipped with my app - not the entire application. I.e. only a static version of libbaz, if that's not part of the runtime and would otherwise be distributed as shared library along with my executable. The reason is to reduce size, as noted above.

[nanonyme]

I'm only going to say wow. This seems like a really strange way to use extensions. Normally apps announce in manifest that they want a runtime extension and that then gets mounted. Maybe there's something specific about fortran that results in this way of operations. Ping @bochecha any idea if this same approach applies for 18.08?

[bochecha]

I'm only going to say wow. This seems like a really strange way to use extensions. Normally apps announce in manifest that they want a runtime extension and that then gets mounted.

But gfortran is in a sdk extension, not a platform extension.

Sdk extensions often come with such an "install.sh" script that apps call at build time when they require it.

One problem is that the libs/tools contained in the extension are in in locations that aren't in the proper paths. (e.g the linker search path)

Another problem is that gfortran is in a sdk extension, which only gets mounted in the app build sandbox. AFAIK there is no corresponding platform extension with the libs that would get mounted in the app run sandbox.

So this install.sh is just the way sdk extensions like this have been used since forever, there is nothing weird here. (although it's certainly not pretty)

---

As for 18.08, we made a mistake and didn't put gfortran in an extension before the release. So now, gfortran is just part of the main sdk/platform and we won't change that before 19.08.

[bochecha]

IMHO it's a bad idea when using traditional package managers, which actually share the shared library. With flatpak, the shared gfortran library is merely copied to the application's package.

Using static linking, I can reduce the size of a package, which uses only a fraction of the library, link time optimization can reduce the binary size further (both, due to dead code elimination).

But then with Flatpak, the shared library is shared on disk, so you only have one copy of it even if multiple apps have it installed.

Same when it's loaded in memory, AFAIK it only gets loaded once.

A static lib loses both benefits.

So your app might be smaller with a static libgfortran, but installing multiple apps doing the same will take more space.

Also, the static library is already there, however, it cannot be used, as it's built improperly. Hence the patch.

This is a good point though: if we ship something, it should be usable. 🙂

[nanonyme]

@oleid since this is against the older 1.6 version of Freedesktop runtime, have you considered updating to 18.08? At this point getting changes included into 18.08 tends to be much easier than 1.6 as the latter is largely in maintenance mode.
Also, see #107; this may be incorrect repository for this file.