[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.44fuzdxlifch2...@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"
> 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:

           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

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

           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

           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


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to