storaged-project / libblockdev

A library for manipulating block devices.
GNU Lesser General Public License v2.1
103 stars 54 forks source link

s390 symbols exported despite --without-s390 #1060

Open mbiebl opened 2 weeks ago

mbiebl commented 2 weeks ago

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 commented 1 week ago

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.