s390 symbols exported despite --without-s390

[mbiebl]

Version: 3.2.0

I'm building libblockdev with the following configure parameters in Debian:
https://salsa.debian.org/utopia-team/libblockdev/-/blob/debian/sid/debian/rules?ref_type=heads#L19
which includes --without-s390

Still, it seems that on s390x, libblockdev exposes s390 specific symbols:
https://buildd.debian.org/status/fetch.php?pkg=libblockdev&arch=s390x&ver=3.2.0-1&stamp=1726233201&raw=0

dpkg-gensymbols: error: some new symbols appeared in the symbols file: see diff output below
dpkg-gensymbols: warning: debian/libblockdev3/DEBIAN/symbols doesn't match completely debian/libblockdev3.symbols
--- debian/libblockdev3.symbols (libblockdev3_3.2.0-1_s390x)
+++ dpkg-gensymbolsSqholI	2024-09-13 13:13:09.720119877 +0000
@@ -527,6 +527,19 @@
  bd_plugin_spec_get_type@Base 2.14
  bd_plugin_spec_new@Base 3.1.0
  bd_reinit@Base 2.14
+ bd_s390_dasd_format@Base 3.2.0-1
+ bd_s390_dasd_is_fba@Base 3.2.0-1
+ bd_s390_dasd_is_ldl@Base 3.2.0-1
+ bd_s390_dasd_needs_format@Base 3.2.0-1
+ bd_s390_dasd_online@Base 3.2.0-1
+ bd_s390_error_quark@Base 3.2.0-1
+ bd_s390_is_tech_avail@Base 3.2.0-1
+ bd_s390_sanitize_dev_input@Base 3.2.0-1
+ bd_s390_zfcp_offline@Base 3.2.0-1
+ bd_s390_zfcp_online@Base 3.2.0-1
+ bd_s390_zfcp_sanitize_lun_input@Base 3.2.0-1
+ bd_s390_zfcp_sanitize_wwpn_input@Base 3.2.0-1
+ bd_s390_zfcp_scsi_offline@Base 3.2.0-1
  bd_smart_ata_attribute_copy@Base 3.2.0
  bd_smart_ata_attribute_free@Base 3.2.0
  bd_smart_ata_attribute_get_type@Base 3.2.0
dh_makeshlibs: error: failing due to earlier errors

Is it really intentional, that libblockdev exposes those symbols (on s390x) even when it is built using --without-s390?

[vojtechtrefny]

This is "normal" -- the library always has all the functions available as generated stubs that return errors so even if the plugin is not loaded its functions still exist. I guess it doesn't really make sense when the plugin is disabled during build time because you don't even have the header file in that case. Definitely something we should look into.