GLIB fails to build on host due to linker issues (wants -fPIC now?)

[Deinsti]

Building GLIB on a fresh OS install with MXE dependencies installed + mxe-SHARED cloned, results in the following issues:

This issue covers more than one distro that I've tested: RHEL9 and Debian 12 however I will experiment with Ubuntu LTS (our tried and tested distro) first to see if it suffers the same problem and report back... if it does; then we need to examine what has changed to cause this - if not, it's likely a distro-specific issue...

[Deinsti]

Ubuntu 22.04 LTS also fails to compile GLIB but with only one relocation error ('_dist_code')

[treeswift]

I think the fix is obvious, and position-independent code should be the norm in general. Assigning @pahaze because he was the last one to tinker with glib, but that's exactly where he hit it himself after #39. I am more or less familiar with meson and can probably inject the flag. Gimme a moment.

[treeswift]

This note in meson.build: # FIXME: autotools build also passes -fPIC -DPIC but is it needed in this case?

[treeswift]

Trying this patch right now, build in progress...

diff --git a/glib/meson.build b/glib/meson.build
index 2e2e57f..ded9b99 100644
--- a/glib/meson.build
+++ b/glib/meson.build
@@ -355,7 +355,7 @@ if use_pcre_static_flag
   pcre_static_args = ['-DPCRE_STATIC']
 endif

-glib_c_args = ['-DG_LOG_DOMAIN="GLib"', '-DGLIB_COMPILATION'] + pcre_static_args + glib_hidden_visibility_args
+glib_c_args = ['-fPIC', '-DG_LOG_DOMAIN="GLib"', '-DGLIB_COMPILATION'] + pcre_static_args + glib_hidden_visibility_args
 libglib = library('glib-2.0',
   glib_dtrace_obj, glib_dtrace_hdr,
   sources : [deprecated_sources, glib_sources],

[treeswift]

host build ok, building target

[treeswift]

Target build passed. If you want to run any tests on your side, I can hold that off and wait for a PR; otherwise will post a PR right away. To the best of my knowledge, positional independence is strictly harmless, including performance-wise in any real-world scenario.

[treeswift]

…actually, one thing — let me see how the PIC macro is used internally.

[treeswift]

Haha, it's not. No results found. Let me know whether you want to test it out or want a build fix PR right away.

[Deinsti]

I think the fix is obvious, and position-independent code should be the norm in general. Assigning @pahaze because he was the last one to tinker with glib, but that's exactly where he hit it himself after #39. I am more or less familiar with meson and can probably inject the flag. Gimme a moment.

Yeah of course, but I just wanted to be sure cause I did have an issue in the past with our MXE that would fail to compile a package but it came out it was distro specific problem so :P

Relating to your commit - the fact it breaks new compilations altogether in this case, I'd say just fire a PR - If issues do crop up, we'll deal with them separately imo.

[treeswift]

Posted.

[telpalbrox]

Hello, not sure if I should comment here or open a new issue but this problem is still happening for me.

I trying for the first to cross compile from Linux to Windows, but I cloned the repo in a fresh Ubuntu 22.04 up to date VM, installed all the dependencies of MXE and then I ran :

make cc
make cmake-conf
make meson-wrapper
make qt5

Everything works fine until it builds glib, where it fails. This is the error that I can see in the logs:

usr/bin/ld: /home/alberto/armmxe-shared/usr/x86_64-pc-linux-gnu/lib/libz.a(trees.o): warning: relocation against `_length_code' in read-only section `.text'
/usr/bin/ld: /home/alberto/armmxe-shared/usr/x86_64-pc-linux-gnu/lib/libz.a(deflate.o): relocation R_X86_64_PC32 against symbol `_dist_code' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
[472/557] Compiling C object gio/gio.p/gio-tool-copy.c.o
[473/557] Compiling C object gio/gio.p/gio-tool-launch.c.o
[474/557] Compiling C object gio/gio.p/gio-tool-info.c.o
ninja: build stopped: subcommand failed.
make[1]: *** [Makefile:911: build-only-glib_x86_64-pc-linux-gnu] Error 1
make[1]: Leaving directory '/home/alberto/armmxe-shared'

real    0m53,127s
user    1m58,353s
sys     0m19,403s

I can see in tmp-glib-x86_64-pc-linux-gnu/glib-2.70.2/glib/meson.build that is correctly patched with glib_c_args = ['-fPIC'... from #52 so I think everything is up to date.

Any ideas?

[treeswift]

Again, obvious from the logs — the issue is with libz.a, which is compiled not as a part of GLib, but separately and earlier (src/zlib.mk). Another question of course is whether we need a static build of zlib at all. Let me look into that. @pahaze is there a good reason to keep a static build of zlib? @telpalbrox what happens if you remove/rename libz.a, forcing the build to pick up libz.dll.a?

[telpalbrox]

After renaming ./usr/x86_64-pc-linux-gnu/lib/libz.a now glib was compiled successfully for host and target. Thanks!

[treeswift]

Ack. So the offending static artifact is the host one…

[pahaze]

@pahaze is there a good reason to keep a static build of zlib?

Very late to the party!! But no, but the issue is compiling it as shared brings an error... and... giving it what it wants via CFLAGS still errors out. Until I realized SFLAGS was what it was going for. Gonna push a fix in the January component branch in just a few once GLib is confirmed to be building with no errors on host with the fix in place.