relocation truncated to fit: citus build failure on s390x - Mailing list pgsql-hackers

[Cc'ing -hackers]

I said:
> That said, there's a build failure on s390x:
>
> https://buildd.debian.org/status/fetch.php?pkg=citus&arch=s390x&ver=5.0.1-1&stamp=1461670278
>
> gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute
> -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -g -O2 -fstack-protector-strong
-Wformat
> -Werror=format-security -I/usr/include/mit-krb5 -fPIC -pie  -fpic -g -O2 -fstack-protector-strong -Wformat
> -Werror=format-security  -Wall -Wextra -Wno-unused-parameter -Wno-sign-compare -Wno-missing-field-initializers
> -Wno-clobbered -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wmissing-declarations
> -Wmissing-prototypes -shared -o citus.so ./shared_library_init.o commands/create_distributed_table.o
> commands/transmit.o executor/multi_utility.o executor/multi_router_executor.o executor/multi_server_executor.o
> executor/multi_real_time_executor.o executor/multi_executor.o executor/multi_task_tracker_executor.o
> executor/multi_client_executor.o master/master_stage_protocol.o master/master_metadata_utility.o
> master/master_delete_protocol.o master/master_repair_shards.o master/master_create_shards.o
> master/worker_node_manager.o master/master_node_protocol.o planner/multi_physical_planner.o
> planner/multi_master_planner.o planner/multi_explain.o planner/multi_logical_planner.o planner/multi_planner.o
> planner/multi_join_order.o planner/modify_planner.o planner/multi_logical_optimizer.o relay/relay_event_utility.o
> test/generate_ddl_commands.o test/connection_utils.o test/prune_shard_list.o test/distribution_metadata.o
> test/test_helper_functions.o test/connection_cache.o test/fake_fdw.o test/create_shards.o utils/listutils.o
> utils/citus_readfuncs_94.o utils/ruleutils_94.o utils/multi_resowner.o utils/resource_lock.o utils/citus_outfuncs.o
> utils/metadata_cache.o utils/connection_cache.o utils/citus_read.o utils/citus_ruleutils.o utils/citus_nodefuncs.o
> utils/citus_readfuncs_95.o utils/ruleutils_95.o worker/worker_partition_protocol.o worker/task_tracker_protocol.o
> worker/task_tracker.o worker/worker_file_access_protocol.o worker/worker_data_fetch_protocol.o
> worker/worker_merge_protocol.o -L/usr/lib/s390x-linux-gnu -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -L/usr/lib/mit-krb5
> -L/usr/lib/s390x-linux-gnu/mit-krb5  -Wl,--as-needed -Wl,-z,relro  -L/usr/lib/s390x-linux-gnu -lpq
> utils/ruleutils_95.o: In function `simple_quote_literal':
> /«PKGBUILDDIR»/src/backend/distributed/utils/ruleutils_95.c:6114:(.text+0x596): relocation truncated to fit:
> R_390_GOT12 against undefined symbol `standard_conforming_strings'
>
> I've had that problem before, but forgot most of it. I think the
> problem is that "-fPIC -pie  -fpic" isn't consistent and should
> probably be "-fPIC -PIE", but I might be totally wrong. (I'll try to
> dig up some docs.)

Re: Andres Freund 2016-04-28 <20160427230516.44fuzdxlifch2wwp@alap3.anarazel.de>
> > Just talked to a s390x porter, the flags used should be -fPIC -pie",
> > i.e. without the lower case version.
>
> Afaics, that's citus independent, and coming from postgres code.
> Makefile.port:
> ifeq "$(findstring sparc,$(host_cpu))" "sparc"
> CFLAGS_SL = -fPIC
> else
> CFLAGS_SL = -fpic
> endif
>
> I'm not clear why citus triggers this, when other extensions don't?

Maybe it's simply because citus.so is bigger than all the other
extension .so files:

       -fpic
       Generate position-independent code (PIC) suitable for use
       in a shared library, if supported for the target machine.
       Such code accesses all constant addresses through a global
       offset table (GOT).  The dynamic loader resolves the GOT
       entries when the program starts (the dynamic loader is not
       part of GCC; it is part of the operating system).  If the
       GOT size for the linked executable exceeds a machine-
       specific maximum size, you get an error message from the
       linker indicating that -fpic does not work; in that case,
       recompile with -fPIC instead.  (These maximums are 8k on
       the SPARC and 32k on the m68k and RS/6000.  The 386 has no
       such limit.)

       Position-independent code requires special support, and
       therefore works only on certain machines.  For the 386, GCC
       supports PIC for System V but not for the Sun 386i.  Code
       generated for the IBM RS/6000 is always
       position-independent.

       When this flag is set, the macros "__pic__" and "__PIC__"
       are defined to 1.

       -fPIC
       If supported for the target machine, emit
       position-independent code, suitable for dynamic linking and
       avoiding any limit on the size of the global offset table.
       This option makes a difference on the m68k, PowerPC and
       SPARC.

       Position-independent code requires special support, and
       therefore works only on certain machines.

       When this flag is set, the macros "__pic__" and "__PIC__"
       are defined to 2.

This doesn't mention s390(x), but citus.so 382952 bytes (on amd64) is
well beyond the 8k/32k limits mentioned above.

PostgreSQL itself links correctly on s390x:
... -I/usr/include/mit-krb5 -fPIC -pie -I../../../../src/include

I'm not an expert in compiler flags, but it seems to me CFLAGS_SL is
wrong on s390(x) in Makefile.port, it should use -fPIC like sparc.

(The m68k build has yet to happen, I'd guess it would exhibit the same
problem.)

Christoph