This is a multi-part message in MIME format.

--nextPart1815397.VLH7GnMWUR
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="utf-8"

I've come to realise the ITK build has 15 libraries that lintian flags with error library-not-linked-against-libc.

https://lintian.debian.org/tags/library-not-linked-against-libc.html[1]

The error description seems straightforward. But how does one solve this? I have to
assume that the linker would by default link with the libc (?), so perhaps the linker
invocation has options that suppress this? What would that be?

The (CMake-generated) link line does have a bunch of options. Nothing jumped out at me:

/usr/bin/c++ -fPIC -g -O2 -ffile-prefix-map=/home/steve/Packages/insighttoolkit/build-area/
insighttoolkit5-5.4.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -
Werror=format-security -fcf-protection -Wdate-time
-D_FORTIFY_SOURCE=2 -I/usr/include/nifti -g1 -mtune=generic -march=corei7 -Wall -
Wcast-align -Wdisabled-optimization -Wextra -Wformat=2 -Winvalid-pch -Wno-format-
nonliteral -Wpointer-arith -Wshadow -Wunused -Wwrite-strings -Wno-strict-overflow -Wno-deprecated -Wno-invalid-offsetof -Woverloaded-virtual -Wctad-
maybe-unsupported -Wstrict-null-sentinel -fno-sized-deallocation -msse2 -Wl,-- dependency-file=CMakeFiles/ITKColormap.dir/link.d -Wl,-z,re
lro -shared -Wl,-soname,libITKColormap-5.4.so.1 -o ../../../../lib/x86_64-linux-gnu/
libITKColormap-5.4.so.1 CMakeFiles/ITKColormap.dir/ itkScalarToRGBColormapImageFilter.cxx.o

The package builds 80 libraries in total, so 65 of them DON'T have this problem.

One example is:

/usr/bin/c++ -fPIC -g -O2 -ffile-prefix-map=/home/steve/Packages/insighttoolkit/build-area/
insighttoolkit5-5.4.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -
Werror=format-security -fcf-protection -Wdate-time
-D_FORTIFY_SOURCE=2 -I/usr/include/nifti -g1 -mtune=generic -march=corei7 -Wall -
Wcast-align -Wdisabled-optimization -Wextra -Wformat=2 -Winvalid-pch -Wno-format-
nonliteral -Wpointer-arith -Wshadow -Wunused -Wwrite-strings -Wno-strict-overflow -Wno-deprecated -Wno-invalid-offsetof -Woverloaded-virtual -Wctad-
maybe-unsupported -Wstrict-null-sentinel -fno-sized-deallocation -msse2 -w -Wl,--
dependency-file=CMakeFiles/ITKMetaIO.dir/link.d -Wl,-z,r
elro -shared -Wl,-soname,libITKMetaIO-5.4.so.1 -o ../../../../../../lib/x86_64-linux-gnu/
libITKMetaIO-5.4.so.1 CMakeFiles/ITKMetaIO.dir/metaUtils.cxx.o CMakeFiles/ ITKMetaIO.dir/metaArray.cxx.o CMakeFiles/ITKMetaIO.dir/metaAr
row.cxx.o CMakeFiles/ITKMetaIO.dir/metaBlob.cxx.o CMakeFiles/ITKMetaIO.dir/ metaCommand.cxx.o CMakeFiles/ITKMetaIO.dir/metaContour.cxx.o CMakeFiles/ ITKMetaIO.dir/metaDTITube.cxx.o CMakeFiles/ITKMetaIO.dir/metaEllipse.cxx.o CMa keFiles/ITKMetaIO.dir/metaFEMObject.cxx.o CMakeFiles/ITKMetaIO.dir/metaForm.cxx.o
CMakeFiles/ITKMetaIO.dir/metaGroup.cxx.o CMakeFiles/ITKMetaIO.dir/ metaGaussian.cxx.o CMakeFiles/ITKMetaIO.dir/metaImage.cxx.o CMakeFiles/ITKMet aIO.dir/metaImageUtils.cxx.o CMakeFiles/ITKMetaIO.dir/metaLandmark.cxx.o CMakeFiles/
ITKMetaIO.dir/metaLine.cxx.o CMakeFiles/ITKMetaIO.dir/metaMesh.cxx.o CMakeFiles/
ITKMetaIO.dir/metaObject.cxx.o CMakeFiles/ITKMetaIO.dir/metaS
cene.cxx.o CMakeFiles/ITKMetaIO.dir/metaSurface.cxx.o CMakeFiles/ITKMetaIO.dir/ metaTube.cxx.o CMakeFiles/ITKMetaIO.dir/metaTransform.cxx.o CMakeFiles/ ITKMetaIO.dir/metaTubeGraph.cxx.o CMakeFiles/ITKMetaIO.dir/metaVesselTube.c xx.o /usr/lib/x86_64-linux-gnu/libz.so

Possibly the libz.so pulls in libc??

Any ideas appreciated!

Thanks,
-Steve
P.S. Please CC, not subscribed, thanks!


--------
[1] https://lintian.debian.org/tags/library-not-linked-against-libc.html

--nextPart1815397.VLH7GnMWUR
Content-Transfer-Encoding: base64
Content-Type: text/html; charset="utf-8"

PGh0bWw+CjxoZWFkPgo8bWV0YSBodHRwLWVxdWl2PSJjb250ZW50LXR5cGUiIGNvbnRlbnQ9InRl eHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+CjwvaGVhZD4KPGJvZHk+PHAgc3R5bGU9Im1hcmdpbi10 b3A6MDttYXJnaW4tYm90dG9tOjA7bWFyZ2luLWxlZnQ6MDttYXJnaW4tcmlnaHQ6MDsiPkkndmUg Y29tZSB0byByZWFsaXNlIHRoZSBJVEsgYnVpbGQgaGFzIDE1IGxpYnJhcmllcyB0aGF0IGxpbnRp YW4gZmxhZ3Mgd2l0aCA8L3A+CjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTow O21hcmdpbi1sZWZ0OjA7bWFyZ2luLXJpZ2h0OjA7Ij5lcnJvciBsaWJyYXJ5LW5vdC1saW5rZWQt YWdhaW5zdC1saWJjLjwvcD4KPGJyIC8+PHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90 dG9tOjA7bWFyZ2luLWxlZnQ6MDttYXJnaW4tcmlnaHQ6MDsiPiZuYnNwOyA8YSBocmVmPSJodHRw czovL2xpbnRpYW4uZGViaWFuLm9yZy90YWdzL2xpYnJhcnktbm90LWxpbmtlZC1hZ2FpbnN0LWxp YmMuaHRtbCI+aHR0cHM6Ly9saW50aWFuLmRlYmlhbi5vcmcvdGFncy9saWJyYXJ5LW5vdC1saW5r ZWQtYWdhaW5zdC1saWJjLmh0bWw8L2E+PC9wPgo8YnIgLz48cCBzdHlsZT0ibWFyZ2luLXRvcDow O21hcmdpbi1ib3R0b206MDttYXJnaW4tbGVmdDowO21hcmdpbi1yaWdodDowOyI+VGhlIGVycm9y IGRlc2NyaXB0aW9uIHNlZW1zIHN0cmFpZ2h0Zm9yd2FyZC4mbmJzcDsgQnV0IGhvdyBkb2VzIG9u ZSBzb2x2ZSB0aGlzPyZuYnNwOyBJIGhhdmUgdG8gYXNzdW1lIHRoYXQgdGhlIGxpbmtlciB3b3Vs ZCBieSBkZWZhdWx0IGxpbmsgd2l0aCB0aGUgbGliYyAoPyksIHNvIHBlcmhhcHMgdGhlIGxpbmtl ciBpbnZvY2F0aW9uIGhhcyBvcHRpb25zIHRoYXQgc3VwcHJlc3MgdGhpcz8mbmJzcDsgV2hhdCB3 b3VsZCB0aGF0IGJlPzwvcD4KPGJyIC8+PHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90 dG9tOjA7bWFyZ2luLWxlZnQ6MDttYXJnaW4tcmlnaHQ6MDsiPlRoZSAoQ01ha2UtZ2VuZXJhdGVk KSBsaW5rIGxpbmUgZG9lcyBoYXZlIGEgYnVuY2ggb2Ygb3B0aW9ucy4mbmJzcDsgTm90aGluZyBq dW1wZWQgb3V0IGF0IG1lOjwvcD4KPGJyIC8+PHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4t Ym90dG9tOjA7bWFyZ2luLWxlZnQ6MDttYXJnaW4tcmlnaHQ6MDsiPjxzcGFuIHN0eWxlPSJiYWNr Z3JvdW5kLWNvbG9yOiNmZmZmZmY7Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMDAwMDsiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTptb25vc3BhY2U7Ij4vdXNyL2Jpbi9jKysgLWZQSUMgLWcgLU8y IC1mZmlsZS1wcmVmaXgtbWFwPS9ob21lL3N0ZXZlL1BhY2thZ2VzL2luc2lnaHR0b29sa2l0L2J1 aWxkLWFyZWEvaW5zaWdodHRvb2xraXQ1LTUuNC4wPS4gLWZzdGFjay1wcm90ZWN0b3Itc3Ryb25n IC1mc3RhY2stY2xhc2gtcHJvdGVjdGlvbiAtV2Zvcm1hdCAtV2Vycm9yPWZvcm1hdC1zZWN1cml0 eSAtZmNmLXByb3RlY3Rpb24gLVdkYXRlLXRpbWU8L3NwYW4+PC9zcGFuPjwvc3Bhbj48YnIgLz4t RF9GT1JUSUZZX1NPVVJDRT0yIC1JL3Vzci9pbmNsdWRlL25pZnRpIC1nMSDCoC1tdHVuZT1nZW5l cmljIC1tYXJjaD1jb3JlaTcgLVdhbGwgLVdjYXN0LWFsaWduIC1XZGlzYWJsZWQtb3B0aW1pemF0 aW9uIC1XZXh0cmEgLVdmb3JtYXQ9MiAtV2ludmFsaWQtcGNoIC1Xbm8tZm9ybWF0LW5vbmxpdGVy YWwgLVdwb2ludGVyLWFyaXRoIC1Xc2hhZG93IC1XdW51c2VkIC1Xd3JpdGUtc3RyaW5ncyA8YnIg Lz4tV25vLXN0cmljdC1vdmVyZmxvdyAtV25vLWRlcHJlY2F0ZWQgLVduby1pbnZhbGlkLW9mZnNl dG9mIC1Xb3ZlcmxvYWRlZC12aXJ0dWFsIC1XY3RhZC1tYXliZS11bnN1cHBvcnRlZCAtV3N0cmlj dC1udWxsLXNlbnRpbmVsIMKgLWZuby1zaXplZC1kZWFsbG9jYXRpb24gLW1zc2UyIC1XbCwtLWRl cGVuZGVuY3ktZmlsZT1DTWFrZUZpbGVzL0lUS0NvbG9ybWFwLmRpci9saW5rLmQgLVdsLC16LHJl PGJyIC8+bHJvIMKgLXNoYXJlZCAtV2wsLXNvbmFtZSxsaWJJVEtDb2xvcm1hcC01LjQuc28uMSAt byAuLi8uLi8uLi8uLi9saWIveDg2XzY0LWxpbnV4LWdudS9saWJJVEtDb2xvcm1hcC01LjQuc28u MSBDTWFrZUZpbGVzL0lUS0NvbG9ybWFwLmRpci9pdGtTY2FsYXJUb1JHQkNvbG9ybWFwSW1hZ2VG aWx0ZXIuY3h4Lm88c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjojZmZmZmZmOyI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMDAwMDA7Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxiciAvPjwvcD4KPHAg c3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjA7bWFyZ2luLWxlZnQ6MDttYXJnaW4t cmlnaHQ6MDsiPlRoZSBwYWNrYWdlIGJ1aWxkcyA4MCBsaWJyYXJpZXMgaW4gdG90YWwsIHNvIDY1 IG9mIHRoZW0gRE9OJ1QgaGF2ZSB0aGlzIHByb2JsZW0uPC9wPgo8YnIgLz48cCBzdHlsZT0ibWFy Z2luLXRvcDowO21hcmdpbi1ib3R0b206MDttYXJnaW4tbGVmdDowO21hcmdpbi1yaWdodDowOyI+ T25lIGV4YW1wbGUgaXM6PC9wPgo8YnIgLz48cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1i b3R0b206MDttYXJnaW4tbGVmdDowO21hcmdpbi1yaWdodDowOyI+PHNwYW4gc3R5bGU9ImJhY2tn cm91bmQtY29sb3I6I2ZmZmZmZjsiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMDAwOyI+L3Vzci9i aW4vYysrIC1mUElDIC1nIC1PMiAtZmZpbGUtcHJlZml4LW1hcD0vaG9tZS9zdGV2ZS9QYWNrYWdl cy9pbnNpZ2h0dG9vbGtpdC9idWlsZC1hcmVhL2luc2lnaHR0b29sa2l0NS01LjQuMD0uIC1mc3Rh Y2stcHJvdGVjdG9yLXN0cm9uZyAtZnN0YWNrLWNsYXNoLXByb3RlY3Rpb24gLVdmb3JtYXQgLVdl cnJvcj1mb3JtYXQtc2VjdXJpdHkgLWZjZi1wcm90ZWN0aW9uIC1XZGF0ZS10aW1lPC9zcGFuPjwv c3Bhbj48YnIgLz4tRF9GT1JUSUZZX1NPVVJDRT0yIC1JL3Vzci9pbmNsdWRlL25pZnRpIC1nMSDC oC1tdHVuZT1nZW5lcmljIC1tYXJjaD1jb3JlaTcgLVdhbGwgLVdjYXN0LWFsaWduIC1XZGlzYWJs ZWQtb3B0aW1pemF0aW9uIC1XZXh0cmEgLVdmb3JtYXQ9MiAtV2ludmFsaWQtcGNoIC1Xbm8tZm9y bWF0LW5vbmxpdGVyYWwgLVdwb2ludGVyLWFyaXRoIC1Xc2hhZG93IC1XdW51c2VkIC1Xd3JpdGUt c3RyaW5ncyA8YnIgLz4tV25vLXN0cmljdC1vdmVyZmxvdyAtV25vLWRlcHJlY2F0ZWQgLVduby1p bnZhbGlkLW9mZnNldG9mIC1Xb3ZlcmxvYWRlZC12aXJ0dWFsIC1XY3RhZC1tYXliZS11bnN1cHBv cnRlZCAtV3N0cmljdC1udWxsLXNlbnRpbmVsIMKgLWZuby1zaXplZC1kZWFsbG9jYXRpb24gLW1z c2UyIC13IC1XbCwtLWRlcGVuZGVuY3ktZmlsZT1DTWFrZUZpbGVzL0lUS01ldGFJTy5kaXIvbGlu ay5kIC1XbCwteixyPGJyIC8+ZWxybyDCoC1zaGFyZWQgLVdsLC1zb25hbWUsbGliSVRLTWV0YUlP LTUuNC5zby4xIC1vIC4uLy4uLy4uLy4uLy4uLy4uL2xpYi94ODZfNjQtbGludXgtZ251L2xpYklU S01ldGFJTy01LjQuc28uMSBDTWFrZUZpbGVzL0lUS01ldGFJTy5kaXIvbWV0YVV0aWxzLmN4eC5v IENNYWtlRmlsZXMvSVRLTWV0YUlPLmRpci9tZXRhQXJyYXkuY3h4Lm8gQ01ha2VGaWxlcy9JVEtN ZXRhSU8uZGlyL21ldGFBcjxiciAvPnJvdy5jeHgubyBDTWFrZUZpbGVzL0lUS01ldGFJTy5kaXIv bWV0YUJsb2IuY3h4Lm8gQ01ha2VGaWxlcy9JVEtNZXRhSU8uZGlyL21ldGFDb21tYW5kLmN4eC5v IENNYWtlRmlsZXMvSVRLTWV0YUlPLmRpci9tZXRhQ29udG91ci5jeHgubyBDTWFrZUZpbGVzL0lU S01ldGFJTy5kaXIvbWV0YURUSVR1YmUuY3h4Lm8gQ01ha2VGaWxlcy9JVEtNZXRhSU8uZGlyL21l dGFFbGxpcHNlLmN4eC5vIENNYTxiciAvPmtlRmlsZXMvSVRLTWV0YUlPLmRpci9tZXRhRkVNT2Jq ZWN0LmN4eC5vIENNYWtlRmlsZXMvSVRLTWV0YUlPLmRpci9tZXRhRm9ybS5jeHgubyBDTWFrZUZp bGVzL0lUS01ldGFJTy5kaXIvbWV0YUdyb3VwLmN4eC5vIENNYWtlRmlsZXMvSVRLTWV0YUlPLmRp ci9tZXRhR2F1c3NpYW4uY3h4Lm8gQ01ha2VGaWxlcy9JVEtNZXRhSU8uZGlyL21ldGFJbWFnZS5j eHgubyBDTWFrZUZpbGVzL0lUS01ldDxiciAvPmFJTy5kaXIvbWV0YUltYWdlVXRpbHMuY3h4Lm8g Q01ha2VGaWxlcy9JVEtNZXRhSU8uZGlyL21ldGFMYW5kbWFyay5jeHgubyBDTWFrZUZpbGVzL0lU S01ldGFJTy5kaXIvbWV0YUxpbmUuY3h4Lm8gQ01ha2VGaWxlcy9JVEtNZXRhSU8uZGlyL21ldGFN ZXNoLmN4eC5vIENNYWtlRmlsZXMvSVRLTWV0YUlPLmRpci9tZXRhT2JqZWN0LmN4eC5vIENNYWtl RmlsZXMvSVRLTWV0YUlPLmRpci9tZXRhUzxiciAvPmNlbmUuY3h4Lm8gQ01ha2VGaWxlcy9JVEtN ZXRhSU8uZGlyL21ldGFTdXJmYWNlLmN4eC5vIENNYWtlRmlsZXMvSVRLTWV0YUlPLmRpci9tZXRh VHViZS5jeHgubyBDTWFrZUZpbGVzL0lUS01ldGFJTy5kaXIvbWV0YVRyYW5zZm9ybS5jeHgubyBD TWFrZUZpbGVzL0lUS01ldGFJTy5kaXIvbWV0YVR1YmVHcmFwaC5jeHgubyBDTWFrZUZpbGVzL0lU S01ldGFJTy5kaXIvbWV0YVZlc3NlbFR1YmUuYzxiciAvPnh4Lm8gwqAvdXNyL2xpYi94ODZfNjQt bGludXgtZ251L2xpYnouc288YnIgLz48YnIgLz5Qb3NzaWJseSB0aGUgbGliei5zbyBwdWxscyBp biBsaWJjPz88L3A+CjxiciAvPjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTow O21hcmdpbi1sZWZ0OjA7bWFyZ2luLXJpZ2h0OjA7Ij5BbnkgaWRlYXMgYXBwcmVjaWF0ZWQhPC9w Pgo8YnIgLz48cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDttYXJnaW4tbGVm dDowO21hcmdpbi1yaWdodDowOyI+VGhhbmtzLDwvcD4KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDtt YXJnaW4tYm90dG9tOjA7bWFyZ2luLWxlZnQ6MDttYXJnaW4tcmlnaHQ6MDsiPi1TdGV2ZTwvcD4K PHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjA7bWFyZ2luLWxlZnQ6MDttYXJn aW4tcmlnaHQ6MDsiPlAuUy4mbmJzcDsgUGxlYXNlIENDLCBub3Qgc3Vic2NyaWJlZCwgdGhhbmtz ITwvcD4KPGJyIC8+PC9ib2R5Pgo8L2h0bWw+


--nextPart1815397.VLH7GnMWUR--

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEy89k8fa3rclNjyokyeVeL63I9LkFAmeVwLYACgkQyeVeL63I 9Lk6wQ//cwunO+M3dngrt1ulthaaX4rDNlNuATCrrb0Tqu15zhNgK+Z9K9s98pAR uQRhyH/1G6ay6vG9CscH0nS2kLC8C/8rRt/tRtbltO5srqicMMw5l1vO5M3H4H0o vACE6zP/hyP1T1Bx+Pa4YHx5iTeu3DqWYWDdkXZqdc7rLlr8dbeQs/bPRx2QR04d cwvZPC/gLtpu6SW6oOJD65ciG/35YgxPrJ3Lzoyh1D+ciYezcPAAykY26AXSYU6e tFij0IgI7MweAcv1q4bViiQF6jw3+vQYMHx/2NLMlfj9NwwFRY+Oe/Yy0HrNeq5e e8W6HbZUK2PduZWbGrxC73ohcFNH323YaS0CBQDno7tGRHeMScRTBMi9+dvEfPlH V/WR7oqdK4EB4IP62Gs+u6LQeJJrxzdYaWN05e2v1URMRICkARlYhpAXp2AdkfxB VoSYsKTOwsCaeUjd418fT8nkNQ1NyiAkibxucaoHjv3lYsKo9Dvea3kfc1GOC1bY tVsHyz4Baa3jwRSGDwkLHYgpQJ0ZgCre8uKbv7NJxZq85b0NlFLRcZrOxxpwl4zH 5NPscG9ZMXWriLXHOmrvWRKQy4EqQFbjiSJVZFNB5RocDQtMH2KGMWBwulsjZiKE N2QEkN2F9bT3lGSgkfpPIQBjypAq9uYkertXl8SK6+3ow6VAmMw=
=5ssm
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Jan 25, 2025 at 10:57:26PM -0600, Steven Robbins wrote:

I've come to realise the ITK build has 15 libraries that lintian flags with error library-not-linked-against-libc.

https://lintian.debian.org/tags/library-not-linked-against-libc.html[1]

The error description seems straightforward. But how does one solve this? I have to
assume that the linker would by default link with the libc (?), so perhaps the linker
invocation has options that suppress this? What would that be?

Before fixing you need to make sure that those libraries indeed use
symbols from libc (with ldd -r, I guess).


--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmeVzeUtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh 45IP/1FcAb2zsc650bmxgikrKPlPt8dDO6LB0RHuoK4bm9OCv+j61K6g8Yg4iAOC AVM3dFcZYgcSH/dXdNhyGE5wbU6BJFGpEzsczbibmZU5Jmh6BWZ7lnQPkleJO309 JcXxJzxhY8tQDPApHi2l29X79wuSaBfEYTS1+a220BYU59BOD29JRRZiiXHrivGV OyaNnBZYGEx0xpMvgiu5Q7mutZPrYIXHbKAzG04CIS1QWHESFsUzwZAPr76bqV68 w5onS6Jat2IS7rCTRDUWJNBoOdoXmJp4eDElFQY9QH5fmwBByoMZc25v+UEVRt45 PKk80WAT3lPi28eNxo3QnfUK9g8I0ZG9qxf6XXBvf6ARiice/dWqNg+qTXzax3zl uG7j1iQ17b7eaTaV9ci0mxmUlvfnjM0rhA7rI6YER8cVtKrX3jxN/f1PVUvuPf+6 DvnqFFku4XJAZf5qVrfGd00XCjluOHWikkEIH6vQvB/mLinw535FFa8UVk2rnR+U 7abiv7jrFxUeg98z9p3xEzlUuRP6xl+WjhLbDEms0IuyZLD96hxAEWHQtqroDaKS XvvBnevyQNX/FZGHqhgbv1N9I3jYbXVlnkHeakDx0VNPsilW5GfrJbXfc+5Sknkg ZvwPSkmNoEXkj9X5DfAkb4m5Adz7c2Byw21dRhwcHJfgvYYO
=eIgL
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.

--nextPart1915084.CQOukoFCf9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

On Saturday, January 25, 2025 10:57:26 P.M. CST you wrote:

I've come to realise the ITK build has 15 libraries that lintian flags with error library-not-linked-against-libc.

Someone suggested to run ldd -r. Okay, so what does this tell me?

$ ldd -r /lib/x86_64-linux-gnu/libITKColormap-5.4.so
linux-vdso.so.1 (0x00007f1b218a1000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1b21400000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1b21766000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1b2120a000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1b218a3000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1b21739000)
Thanks,
-Steve
P.S. Please CC, not subscribed, thanks!


--nextPart1915084.CQOukoFCf9
Content-Transfer-Encoding: base64
Content-Type: text/html; charset="utf-8"

PGh0bWw+CjxoZWFkPgo8bWV0YSBodHRwLWVxdWl2PSJjb250ZW50LXR5cGUiIGNvbnRlbnQ9InRl eHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+CjwvaGVhZD4KPGJvZHk+PHAgc3R5bGU9Im1hcmdpbi10 b3A6MDttYXJnaW4tYm90dG9tOjA7bWFyZ2luLWxlZnQ6MDttYXJnaW4tcmlnaHQ6MDsiPk9uIFNh dHVyZGF5LCBKYW51YXJ5IDI1LCAyMDI1IDEwOjU3OjI24oCvUC5NLiBDU1QgeW91IHdyb3RlOjwv cD4KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjA7bWFyZ2luLWxlZnQ6MDtt YXJnaW4tcmlnaHQ6MDsiPiZndDsgSSd2ZSBjb21lIHRvIHJlYWxpc2UgdGhlIElUSyBidWlsZCBo YXMgMTUgbGlicmFyaWVzIHRoYXQgbGludGlhbiBmbGFncyB3aXRoPC9wPgo8cCBzdHlsZT0ibWFy Z2luLXRvcDowO21hcmdpbi1ib3R0b206MDttYXJnaW4tbGVmdDowO21hcmdpbi1yaWdodDowOyI+ Jmd0OyBlcnJvciBsaWJyYXJ5LW5vdC1saW5rZWQtYWdhaW5zdC1saWJjLjwvcD4KPGJyIC8+PHAg c3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjA7bWFyZ2luLWxlZnQ6MDttYXJnaW4t cmlnaHQ6MDsiPlNvbWVvbmUgc3VnZ2VzdGVkIHRvIHJ1biBsZGQgLXIuJm5ic3A7IE9rYXksIHNv IHdoYXQgZG9lcyB0aGlzIHRlbGwgbWU/PC9wPgo8YnIgLz48cCBzdHlsZT0ibWFyZ2luLXRvcDow O21hcmdpbi1ib3R0b206MDttYXJnaW4tbGVmdDowO21hcmdpbi1yaWdodDowOyI+PHNwYW4gc3R5 bGU9ImJhY2tncm91bmQtY29sb3I6I2ZmZmZmZjsiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMDAw OyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Om1vbm9zcGFjZTsiPiQgbGRkIC1yIC9saWIveDg2 XzY0LWxpbnV4LWdudS9saWJJVEtDb2xvcm1hcC01LjQuc28gPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PGJyIC8+wqDCoMKgwqDCoMKgwqA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjojZmZmZmZm OyI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAwMDA7Ij5saW51eC12ZHNvLnNvLjEgKDB4MDAwMDdm MWIyMThhMTAwMCkgPC9zcGFuPjwvc3Bhbj48YnIgLz7CoMKgwqDCoMKgwqDCoDxzcGFuIHN0eWxl PSJiYWNrZ3JvdW5kLWNvbG9yOiNmZmZmZmY7Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMDAwMDsi PmxpYnN0ZGMrKy5zby42ID0mZ3Q7IC9saWIveDg2XzY0LWxpbnV4LWdudS9saWJzdGRjKysuc28u NiAoMHgwMDAwN2YxYjIxNDAwMDAwKSA8L3NwYW4+PC9zcGFuPjxiciAvPsKgwqDCoMKgwqDCoMKg PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6I2ZmZmZmZjsiPjxzcGFuIHN0eWxlPSJjb2xv cjojMDAwMDAwOyI+bGlibS5zby42ID0mZ3Q7IC9saWIveDg2XzY0LWxpbnV4LWdudS9saWJtLnNv LjYgKDB4MDAwMDdmMWIyMTc2NjAwMCkgPC9zcGFuPjwvc3Bhbj48YnIgLz7CoMKgwqDCoMKgwqDC oDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiNmZmZmZmY7Ij48c3BhbiBzdHlsZT0iY29s b3I6IzAwMDAwMDsiPmxpYmMuc28uNiA9Jmd0OyAvbGliL3g4Nl82NC1saW51eC1nbnUvbGliYy5z by42ICgweDAwMDA3ZjFiMjEyMGEwMDApIDwvc3Bhbj48L3NwYW4+PGJyIC8+wqDCoMKgwqDCoMKg wqA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjojZmZmZmZmOyI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDAwMDA7Ij4vbGliNjQvbGQtbGludXgteDg2LTY0LnNvLjIgKDB4MDAwMDdmMWIyMThh MzAwMCkgPC9zcGFuPjwvc3Bhbj48YnIgLz7CoMKgwqDCoMKgwqDCoDxzcGFuIHN0eWxlPSJiYWNr Z3JvdW5kLWNvbG9yOiNmZmZmZmY7Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMDAwMDsiPmxpYmdj Y19zLnNvLjEgPSZndDsgL2xpYi94ODZfNjQtbGludXgtZ251L2xpYmdjY19zLnNvLjEgKDB4MDAw MDdmMWIyMTczOTAwMCk8L3NwYW4+PC9zcGFuPjxiciAvPlRoYW5rcyw8L3A+CjxwIHN0eWxlPSJt YXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowO21hcmdpbi1sZWZ0OjA7bWFyZ2luLXJpZ2h0OjA7 Ij4mbmJzcDstU3RldmU8L3A+CjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTow O21hcmdpbi1sZWZ0OjA7bWFyZ2luLXJpZ2h0OjA7Ij5QLlMuJm5ic3A7IFBsZWFzZSBDQywgbm90 IHN1YnNjcmliZWQsIHRoYW5rcyE8L3A+CjxiciAvPjwvYm9keT4KPC9odG1sPg==


--nextPart1915084.CQOukoFCf9--

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEy89k8fa3rclNjyokyeVeL63I9LkFAmeV3gEACgkQyeVeL63I 9LkyyBAApGjXbroDKwAzXU6uDy2b67989hnWQRZNjfY8d1ZmF93RtWw9A8oDAEqm XJwDJiDOvpqBGElv38EYdTF2LK6v9M8z3PIFvIdHJ3q4JaiVwo4Jm3cXQFZWCK10 FkqCGra0lQki/NO+GsFyOtWez7wEPyzO+FGyHlX8Z537XtzXG6CShmtHfVMKG+XW 2lDURWPjolgGVw9FWpHjnJJsRy3m3xm5wRmEEpagg7GQ4x/y2zlGEGSy4WGI+8Vl KOClszh0A+ZRcl7EKdN23ZsG5fWHuQF/9WLziS5zSq1dIOXujCkESQpVJGzPJ6/Z D12wteuwZFEvrcI/bbjUbwCaxtz4G48U6i2eU9BGboQqbe1Q31BtfYdceTkzzQsU H8q2t1Bw3rBWOQcpDGrQkKmsj9sAhx3QBvwyUA/SD+cRHgZWKNCj5mTk5hnrlCqV xtuhjmtv5Pbc9hiAoqYPBjFgLi7+EbuME7gnH6rcdhF5gKlx4m+QtV5dI0iVNeZN jJmUnBVkfazBjvkqZA9c/dcWhHkXJ3CiDcjEs5leUSY3NdydTANtkPdd/wiHcOdH B2JD60hxgfiowsjboXoyk6/FmxA2vSvZ72AYQvIphDqmwv7PIsCD0ZVmR9kgu/JO B/RE9BuerQpynLdMtAT+Lxe2hfLqjlLCEc+AsEQCfPFkplTlhv4=
=DDFG
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 26/01/2025 04:57, Steven Robbins wrote:

I've come to realise the ITK build has 15 libraries that lintian flags with

...

The error description seems straightforward.  But how does one solve
this?  I have to assume that the linker would by default link with the
libc (?), so perhaps the linker invocation has options that suppress
this?  What would that be?

You may not need to solve it if it's intentional.
For example, you have a "plugin" style library that only uses functions
from the main library and nothing else.

I do this to confirm if lintian is correct:

$ objdump -p file.so
...
NEEDED libc.so.6
...

If it doesn't need libc, then lintian error is correct.
You would then sift through the code to see what that library
includes/links against.
Is it intentional that it doesn't need libc? If yes, then override the
error.


--
Regards,
Ahmad

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

unrelated to your question, but there are things that jump out for me:

Am Sat, Jan 25, 2025 at 10:57:26PM -0600, schrieb Steven Robbins:

The (CMake-generated) link line does have a bunch of options. Nothing jumped out at me:

/usr/bin/c++ -fPIC -g -O2 -ffile-prefix-map=/home/steve/Packages/insighttoolkit/build-area/
insighttoolkit5-5.4.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -
Werror=format-security -fcf-protection -Wdate-time
-D_FORTIFY_SOURCE=2 -I/usr/include/nifti -g1 -mtune=generic -march=corei7 -Wall -

^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Wcast-align -Wdisabled-optimization -Wextra -Wformat=2 -Winvalid-pch -Wno-format-
nonliteral -Wpointer-arith -Wshadow -Wunused -Wwrite-strings -Wno-strict-overflow -Wno-deprecated -Wno-invalid-offsetof -Woverloaded-virtual -Wctad-
maybe-unsupported -Wstrict-null-sentinel -fno-sized-deallocation -msse2 -Wl,--

^^^^^^

dependency-file=CMakeFiles/ITKColormap.dir/link.d -Wl,-z,re
lro -shared -Wl,-soname,libITKColormap-5.4.so.1 -o ../../../../lib/x86_64-linux-gnu/
libITKColormap-5.4.so.1 CMakeFiles/ITKColormap.dir/ itkScalarToRGBColormapImageFilter.cxx.o

You are building the package only for amd64, but even for that corei7
might be a bit much to ask for.

You and/or upstream might be interested in some of the tipps and tricks
from https://wiki.debian.org/InstructionSelection to use more/less
instructions as needed than the baseline.

On a sidenote: I would have expected this thread on d-mentors.


Best regards

David Kalnischkies

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE5sn+Q4uCja/tn0GrMRvlz3HQeIMFAmeWIeMACgkQMRvlz3HQ eIP1zhAAnkH6stQQMTxlzbLq5VTvAAatXJcub3vyL15ftJwOhQyAHL+FN/gjXFIX bVktXja0o82RsIYrc35ep4bJoXL1xRhEBV7KKjJdcm3yNSInO6DagDzodJcfqwBK oaKLJXfLYsEw0LWZBTS4nmxo9L3EG/dPZ4E25+Igdws9hebVZTnG/2R5NxNnYovL Ow8QpthQzV/j5WE1xTlSdZGyOmqOy0FTNuvH5+7JO1e3379j/rQFu6Hf4usLf+ZK fgJ3F0qIz/4cDt7NnSKHcd4WPikSTf+W/Clid0LO5vuXqLkHZCMtLr4QX1rB+/e1 UBCKaAnpHy7H/3PRN0Jad/jqSjGtIW94X/RjjsqihyizfFQFErhAoO0Z7lzOT2Bc I0z9275WYhMl7phzAv3aGlmRkAlH0rPEmLSKLtiUOWqwylTeUj3Yp+ohPCnkaeg/ nPo+eWt7PZGATO86HBb6QspIY5C2L4ZS1bqztCnEQCEtLiNkOoLM2vUjvRDuX1Vg RxH44KIJo8LNsfaONns7g+P7hJ83a+4SuhSy7m0lcnebaJx96pQ5b+kW7kLnfggI 1wHv1CLeIuzM71QgH06RT5iLptWKlUMprLLcXJooRNAdwtPfRm6aZdGGc5XmIe2S 52YXrAILEd2eMU0AqMkAFvAd+FMzI8IVNkpPm3ZiXJto1wScd0o=
=g8Mc
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Jan 26, 2025 at 11:07:12AM +0000, Ahmad Khalifa wrote:

The error description seems straightforward.  But how does one solve this?  I have to assume that the linker would by default link with the libc (?), so perhaps the linker invocation has options that suppress this?  What would that be?

You may not need to solve it if it's intentional.
For example, you have a "plugin" style library that only uses functions from the main library and nothing else.

Yes.

I do this to confirm if lintian is correct:

$ objdump -p file.so
...
NEEDED libc.so.6
...

No?
Lintian already says there is no "NEEDED libc.so.6", the
question is whether that is an error or not.


--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmeWGiotFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh VekP/0jOUtRQ2wLAvMwLLG+T5hogyWQBC/8v6KfnQpH63tzv57KqFbZGTHBNDUtR UcglFUCRicA9vhhWPztqdnj+NChee7A67PnB75OC6GOCK5BMa2QM95Md3rYSZzc8 6rEWXvJh/LRrylFC+UcvXmWqpQLE6Y+jJpfSLPpxw+q5xVUQh6p2XmMQ2VVRbhtn 2yRoANHOU35VEpBpWQs07t82nLCvfjY2eSY7yFQy2ZhEIzvMegTENUUbPF8qcD16 mp7L4LPJ78Xf0e50u3vy73JDOjcsbVX7xL3sSb3O3CLQmSMFVX7KVIvDw7A8Xhtl mfOwjeBWCdSwDPPiiziOaQxuaGSVprnmzOM/ODQ3eFBzJ8BaTBFyc4tf5+a8CK2b EUplzTVv9pgM3RhtbRGTMqhCnG1Jej6wswudlRCjKvCM4betVZhYsYjJCX09M+81 uykGMPs05INxI05TK+oQLL5VhACaVOSP8xN3E4KnNURowYyZDCGQj/N7Zo6UOVuh 71SpeCRu98et/RhmruH/6084Np6C2ekGL+9ZhOVgmJZ9AbJj+nASV/nnq3Rkf5e/ w7K1VMXUCG7+rNq5nU8NYxmROtiLMMmCQe0yRqCuknGZjl03ga4OmwLdttS7ER8U b2ZCXBIVeG0c4UL/8b+h69CEVmuCWaLzgINyPf23v7iuTkM/
=LUC1
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Jan 26, 2025 at 01:02:25AM -0600, Steven Robbins wrote:

I've come to realise the ITK build has 15 libraries that lintian flags with error library-not-linked-against-libc.

Someone suggested to run ldd -r. Okay, so what does this tell me?

$ ldd -r /lib/x86_64-linux-gnu/libITKColormap-5.4.so
linux-vdso.so.1 (0x00007f1b218a1000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1b21400000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1b21766000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1b2120a000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1b218a3000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1b21739000)

Oh right, this is not a useful check if the library is linked to anything
that is linked to libc. The correct way is, as lintian says, to check the symbols imported by the library (with e.g. nm -D) to make sure none of
them are from libc.

Thanks,
-Steve
P.S. Please CC, not subscribed, thanks!

Done.
And please use debian-mentors@ for packaging questions next time.



--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmeWGsctFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh dAIP/3WmNQOzZRUuHXMcOHI3Pc4xIyyXQQ3ZOHlRtS63uNhKTmzmbAbkfq0XJJhB Hv869bFX126FytlY/9b8G8hmOCiyeX+rHOhyAkMCOZy7kMxiy8xasP9BDIHp0CG3 SBvzaGelKzaBTdzrHeDWkboUFSfFTS1z07UhjADK4G9QlU8/CDTVybziIuxeBSlH H9JkmZao14/jBSCdfblOqjq9bTL9SoxQJXD4DiYkQ92vAdwCFOqR/NL2Lcw8tUnh tBCEcA/6Ehqkav02IughJ2YWv9VLaxuOHBAkjtZ7jagkNF0vklqv0teYFNbpgbE2 mRIJ21Z3fRmKpgixxgG8ngIbAWkTV9yPzQGFaxHiXrFZK6acpyciasX7IfC5V2E7 sCpUwVKIPGLJ6v30BqJvlnw6tz55VpcqczYiQ7rvf1suvRBamc2avDD6bWyojwJ4 Do/e+TpcggHZQ4BCALIaOb74b8ydsTo8FUJ3U+fovo5Lg+1XBLz23Fwfv9vSTbv6 6VpmcjkZkSNX6OnDKd66CBmlcIGOLNu7i3hmriIZlDgWu4UI9gwsjROBNL9eCxWT E6ov16cYS9Ll6+XjGCnDqou/ArDtslKP2PGRBMZN8HQvSENN2xCHyOUVDtGwxZP1 KWzm7k4Knycm6vyLv2m2foPfwdcyh3cJfog+Skw6k0K4GRdg
=2o9i
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 26/01/2025 11:19, Andrey Rakhmatullin wrote:

On Sun, Jan 26, 2025 at 11:07:12AM +0000, Ahmad Khalifa wrote:

I do this to confirm if lintian is correct:

$ objdump -p file.so
...
NEEDED libc.so.6
...

No?
Lintian already says there is no "NEEDED libc.so.6", the question is whether that is an error or not.

I think we're on the same page, I just added an extra step out of caution :)

The lintian error is a great heads-up and it's up to the reader to
decide whether it's a true error to fix or a false-positive to override.

--
Regards,
Ahmad

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Jan 26, 2025 at 6:28 AM Ahmad Khalifa <ahmad@khalifa.ws> wrote:

The lintian error is a great heads-up and it's up to the reader to
decide whether it's a true error to fix or a false-positive to override.

I have never seen this Lintian error actually be useful. I think an
error is far too strong for this; I think even a warning is too
strong; maybe info would be ok.

Thank you,
Jeremy Bícha

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 26/01/2025 12:41, Jeremy Bícha wrote:

On Sun, Jan 26, 2025 at 6:28 AM Ahmad Khalifa <ahmad@khalifa.ws> wrote:

The lintian error is a great heads-up and it's up to the reader to
decide whether it's a true error to fix or a false-positive to override.

I have never seen this Lintian error actually be useful. I think an
error is far too strong for this; I think even a warning is too
strong; maybe info would be ok.

Good point. As a heads-up, Info-level is more appropriate or even Pedantic.

Also looking at this partial list of affected packages, 40% have
overridden it - which is pretty high if it were a real error.

https://udd.debian.org/lintian-tag/library-not-linked-against-libc?affected=yes


--
Regards,
Ahmad

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Jeremy Bícha <jeremy.bicha@canonical.com> writes:

On Sun, Jan 26, 2025 at 6:28 AM Ahmad Khalifa <ahmad@khalifa.ws> wrote:

The lintian error is a great heads-up and it's up to the reader to
decide whether it's a true error to fix or a false-positive to
override.

I have never seen this Lintian error actually be useful. I think an
error is far too strong for this; I think even a warning is too strong;
maybe info would be ok.

When we introduced it many years ago, it was definitely useful. It's
intended to catch plugin libraries that are linked with the main library
but not with libc explicitly, while still using libc symbols. This case
often works due to the implicit dependency up until it doesn't.

Maybe the tooling is now better in ways that make this much less likely to happen? And maybe it's more common these days to have plugin libraries
that aren't linked with libc? Back in the day, it was very rare for people
to successfully manage to write code that never called a libc symbol.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 26 Jan 2025 at 09:14:30 -0800, Russ Allbery wrote:

maybe it's more common these days to have plugin libraries
that aren't linked with libc? Back in the day, it was very rare for people
to successfully manage to write code that never called a libc symbol.

In ecosystems with a "platform" runtime library like GLib, Qt or even
SDL, and especially when intending to be portable to Windows and macOS
as well as Linux and other Unixy platforms, it's very common to write
code that only ever calls into that runtime library, and never directly
calls libc functions. I think the reason Jeremy is so negative about this lintian check is that false positives are particularly common in GNOME,
where basically everything is linked to GLib and uses its functions in preference to going directly to libc.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Simon McVittie <smcv@debian.org> writes:

On Sun, 26 Jan 2025 at 09:14:30 -0800, Russ Allbery wrote:

maybe it's more common these days to have plugin libraries that aren't
linked with libc? Back in the day, it was very rare for people to
successfully manage to write code that never called a libc symbol.

In ecosystems with a "platform" runtime library like GLib, Qt or even
SDL, and especially when intending to be portable to Windows and macOS
as well as Linux and other Unixy platforms, it's very common to write
code that only ever calls into that runtime library, and never directly
calls libc functions. I think the reason Jeremy is so negative about
this lintian check is that false positives are particularly common in
GNOME, where basically everything is linked to GLib and uses its
functions in preference to going directly to libc.

I suspect what's changed since the introduction of this tag is that use of as-needed is now much more common and as-needed is removing the libc dependency. That specific pattern is safe, since the libc dependency would
be introduced if it were needed in the future. Unfortunately, Lintian
currently can't distinguish between that case and the case where the
linker was told not to link against libc at all.

In theory it would be possible to do better in Lintian by scanning the
symbol table to see if the libc dependency is really unneeded. But doing
that sounds at least a little annoying. Downgrading the tag is not really
a fix. That doesn't make the false positives go away; it just encourages
people to ignore more Lintian tags. If people think the problem the tag
was designed to detect is so rare as to warrant downgrading to pedantic, I would just delete the check entirely.

I have a warning flag set in the back of my head that it's possible for
GCC to introduce calls into libc even if they're not present in the source (memcpy, maybe?) unless you explicitly tell it to build things in
standalone mode, although maybe I'm misremembering. It's certainly easy to introduce a libc dependency by writing normal C code and calling some
function that's universally available, including on Windows, without
thinking about it, thus making the state of "not using libc" somewhat
unstable. But problems like that combined with a build system error of
omitting libc entirely are probably much less common than as-needed
removing libc because it's not needed.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Russ Allbery <rra@debian.org> [250126 12:47]:

In theory it would be possible to do better in Lintian by scanning the
symbol table to see if the libc dependency is really unneeded. But doing
that sounds at least a little annoying.

Annoying to users of lintian or annoying to implement? How so?

I thought of this solution while reading earlier in this thread, and it
seems like the "correct" solution to me. What is wrong with it?

Clearly the current state is a bug in lintian, as so many packages
override this error. And from your description, the test has a
significant purpose that is still needed in the situations it was
intended to catch, even if they are few. The lintian test simply does
not correctly identify _only_ the situations it was supposed to; it
catches many more false positives (now, due to changing programming
practices) than true positives.

...Marvin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marvin Renich <mrvn@renich.org> writes:

* Russ Allbery <rra@debian.org> [250126 12:47]:

In theory it would be possible to do better in Lintian by scanning the
symbol table to see if the libc dependency is really unneeded. But
doing that sounds at least a little annoying.

Annoying to users of lintian or annoying to implement? How so?

Annoying to implement because I think the implementation would have to
know what symbols are provided by libc.

I thought of this solution while reading earlier in this thread, and it
seems like the "correct" solution to me. What is wrong with it?

Nothing so far as I know. It's just work, and if people don't think that
the problem is likely to occur, maybe the work isn't worth doing and the
tag should just be deleted.

Clearly the current state is a bug in lintian, as so many packages
override this error. And from your description, the test has a
significant purpose that is still needed in the situations it was
intended to catch, even if they are few.

Well, I'm not sure I would go that far. It *had* a significant purpose; we added it originally because it was catching a real problem. But it's
entirely possible that this was an artifact of build systems at the time
and the state of build systems in the archive has gotten much better.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 27/01/2025 18:24, Russ Allbery wrote:

Marvin Renich <mrvn@renich.org> writes:

* Russ Allbery <rra@debian.org> [250126 12:47]:

In theory it would be possible to do better in Lintian by scanning the
symbol table to see if the libc dependency is really unneeded. But
doing that sounds at least a little annoying.

Annoying to users of lintian or annoying to implement? How so?

Annoying to implement because I think the implementation would have to
know what symbols are provided by libc.

To my knowledge objdump will spit out the symbols with (GLIBC_v*)

Having said that, lintian is slow enough as a single thread, I'd vote
for downgrading the tag to Pedantic, but not deleting it.


--
Regards,
Ahmad

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ahmad Khalifa <ahmad@khalifa.ws> writes:

On 27/01/2025 18:24, Russ Allbery wrote:

Annoying to implement because I think the implementation would have to
know what symbols are provided by libc.

To my knowledge objdump will spit out the symbols with (GLIBC_v*)

Oh, if one can reliably detect libc symbols by looking at the symbol
version, that would indeed make it a lot easier. I was assuming that
wasn't necessarily the case, but now I'm not sure why I thought that.

Having said that, lintian is slow enough as a single thread, I'd vote for downgrading the tag to Pedantic, but not deleting it.

So, I guess I'll say this more explicitly: I am opposed to downgrading the
tag to pedantic. If the tag is useful, we should fix it; if it's not
useful, we should delete it.

It's not a pedantic issue with the package. If the error is real, it's
serious, but Lintian's check for the error has a high false positive rate. That's not what pedantic is for. Pedantic is intended for tags where
Lintian has correctly understood the thing that it is complaining about,
but people do not always agree that thing is worth fixing.

If you really want to keep the tag despite a lot of false positives, the
way to do that would be to make it experimental, but I think experimental
tags are often a dumping ground for things that will never be fixed and it might be better to just delete it.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 27/01/2025 23:14, Russ Allbery wrote:

Ahmad Khalifa <ahmad@khalifa.ws> writes:

Having said that, lintian is slow enough as a single thread, I'd vote for
downgrading the tag to Pedantic, but not deleting it.

So, I guess I'll say this more explicitly: I am opposed to downgrading the tag to pedantic. If the tag is useful, we should fix it; if it's not
useful, we should delete it.

It's not a pedantic issue with the package. If the error is real, it's serious, but Lintian's check for the error has a high false positive rate. That's not what pedantic is for. Pedantic is intended for tags where
Lintian has correctly understood the thing that it is complaining about,
but people do not always agree that thing is worth fixing.

If you really want to keep the tag despite a lot of false positives, the
way to do that would be to make it experimental, but I think experimental tags are often a dumping ground for things that will never be fixed and it might be better to just delete it.

With your definition, I agree, it's not something to be pedantic about,
it's not a real error.

Here is a quick check I did on random packages from udd [1]:
Picking abseil (300+ overridden), clanlib (9 error) and chicken (300+ error)

# download the relevant debs (sorry formatting)

wget https://ftp.debian.org/debian/pool/main/a/abseil/libabsl20230802_20230802.1-4_{amd64,arm64,armel,armhf,i386,mips64el,mipsel,ppc64el,s390x,riscv64}.deb
wget https://ftp.debian.org/debian/pool/main/c/clanlib/libclanapp-1.0t64_1.0~svn3827-11.2+b1_{amd64,arm64,armel,armhf,i386,mips64el,mipsel,ppc64el,s390x,riscv64}.deb
wget https://ftp.debian.org/debian/pool/main/c/chicken/chicken-bin_5.3.0-2_{amd64,arm64,armel,armhf,i386,mips64el,mipsel,ppc64el,s390x,riscv64}.deb

# extract

for f in *.deb; do dpkg --extract "$f" ROOT; done

# check for GLIBC symbol without NEEDED libc, libm or loaders

for f in ROOT/usr/lib/*-linux-gnu/*.so.* ROOT/var/lib/chicken/11/*.so*; do
(objdump -T "$f" | grep " (GLIBC_[0-9]" > /dev/null) &&
( (objdump -p "$f" | grep -E 'NEEDED *libc.so|NEEDED *libm.so|NEEDED *ld-linux.*.so|NEEDED *ld64.so' > /dev/null) || echo "bad so: $f");
done

Outputs nothing.
Meaning for all libc dynamic symbols, the linker will load one of the
libc libraries.

But reading that, I don't see how the linker could declare a dynamic
GLIBC_ symbol without the related library reference.
In fact, it should choke with "undefined reference" long before
outputting a .so file. Even when compiling with -nolibc. But there is
always a special case somewhere :)
And if the linker wrote broken dynamic sections, I doubt lintian could
find out from just inspecting the .so.

Perhaps the tag really is not relevant anymore or someone has a better test.


1. https://udd.debian.org/lintian-tag/library-not-linked-against-libc?affected=yes

--
Regards,
Ahmad

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ahmad Khalifa <ahmad@khalifa.ws> writes:

But reading that, I don't see how the linker could declare a dynamic
GLIBC_ symbol without the related library reference.

In fact, it should choke with "undefined reference" long before outputting
a .so file. Even when compiling with -nolibc. But there is always a
special case somewhere :)

Historically, it happened with plugins that were built with the Libtool
-module flag or the underlying equivalents, which allows creation of a
shared library module with undefined references. This is (or at least was) normal behavior for modules meant to be opened with dlopen; the symbols
are resolved at dlopen time from the program that is importing the module.

This is desired behavior when the symbols are coming from the program, but
it is (or at least was) easy to accidentally leave libc symbols undefined
as well, in which case they too are resolved from the main executable at
dlopen time. My recollection (it's been a *lot* of years so I'm hoping I'm getting this right) is that this interfered with proper symbol versioning
and could cause the symbols to be resolved weirdly in a way that could
cause serious bugs.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Russ" == Russ Allbery <rra@debian.org> writes:

Russ> recollection (it's been a *lot* of years so I'm hoping I'm
Russ> getting this right) is that this interfered with proper symbol
Russ> versioning and could cause the symbols to be resolved weirdly
Russ> in a way that could cause serious bugs.

Yeah, and so the symbol versions would not be present, and so I think
we're back to needing to know what symbols are from libc6.
A better error if we knew how to generate it efficiently would be using
a libc symbol without a symbol version.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ahmad Khalifa <ahmad@khalifa.ws> writes:

On 28/01/2025 22:28, Sam Hartman wrote:

"Russ" == Russ Allbery <rra@debian.org> writes:

Russ> recollection (it's been a *lot* of years so I'm hoping I'm
Russ> getting this right) is that this interfered with proper
Russ> symbol versioning and could cause the symbols to be resolved
Russ> weirdly in a way that could cause serious bugs.

Yeah, and so the symbol versions would not be present, and so I think
we're back to needing to know what symbols are from libc6. A better
error if we knew how to generate it efficiently would be using a libc
symbol without a symbol version.

dlopen() itself is versioned to libc on the calling object, but there is
no record of what is passed to it aside from a floating string somewhere
in the ro section. Unless you parse the source or disassemble the .so,
you can't find out what is being called.

In other words, lintian can't find out if the library loads printf() for example. But you can test it to see if it works correctly :)

I think we may still not be on quite the same page about what I understand
the problem to be, and what the Lintian check is trying to detect. The
Lintian check is not aimed at the binary doing the dlopen() call. It's
aimed at the *.so file that is the target of the dlopen() call.

Warning: lots of simplification and hand-waving here. This is not fully accurate to how things work, but is hopefully close enough to get the idea across.

When shared code is loaded through dlopen(), its declared library
dependencies are resolved in a similar manner to when dynamic libraries
are loaded. Then, once those symbols are resolved, any remaining
unresolved symbols are resolved from the binary that called dlopen().

Historically we have relied on this behavior in, for example, Perl XS
modules which have unresolved references to the Perl interpreter symbols,
which can be resolved either from /usr/bin/perl (in the normal case) or
from libperl.so.5.40 (in the embedded Perl case). In other words, those
symbols are left *intentionally* unresolved because we do not want to
create a dependency on libperl because we do not want to load libperl into /usr/bin/perl; we want the module symbols to be resolved against
/usr/bin/perl. (There are various reasons for this that mostly come down
to performance.)

The problem is that once you start linking modules using the flags that
allow them to leave the Perl symbols unresolved, you run the risk of also leaving *other* shared library symbols unresolved, including,
specifically, libc.

Now, you may think that this is not really a problem, because the main
binary has a dependency on libc and thus those symbols will be resolved at dlopen() time just like the Perl symbols. The problem is that, at least as
I remember this, the symbol version resolution happens at link time. The
binary only knows that it needs strerror@GLIBC_2.2.5 because it was linked
with libc. If it's *not* linked with libc, the unresolved symbol will just
be strerror without the version. That in turn means, I believe, that it resolves to the latest version of strerror found in the process space,
which can be the wrong version of strerror if the ABI has changed. (It
hasn't for strerror, but it has for some other things.)

You can detect this from readelf on the module *.so file, but you can't
detect this by looking for the @GLIBC symbol versions because in the
unlinked case the symbol versioning doesn't happen. You have to look for
bare undefined strerror references with no symbol version, which would
indeed represent a bug. But you *don't* want to alert on the unresolved
Perl symbols, because those are intentional. So that's how we get back to having to know which symbols are found in libc and therefore should have attached symbol versions.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ahmad Khalifa <ahmad@khalifa.ws> writes:

Instead, lintian should alert that some symbols are "unversioned".

The problem is that unversioned symbols are often correct. For one, not
every shared library uses symbol versioning; we may want them all to use
symbol versioning, and certainly way more of them do today, but I don't
think it's universal.

But, more critically, the Perl XS case relies on unversioned symbols. We
have a use case that uses unresolved symbols, which therefore aren't
versioned. And even if we decided to handle Perl XS modules a different
way, I believe this pattern occurs elsewhere when the symbols in the
loaded module need to be resolved against the executable that loads that module. I believe those symbols basically *can't* be versioned, at least
in the normal way.

Whether you can detect this or not, it would probably be a new tag
anyway. But being practical, the stability of libc nowadays is much
higher and it's better to just have lintian-is-always-right!!

I don't think this problem is about the stability of libc. I don't think anything relevant has changed there; libc does change ABIs in a way that
isn't backward compatible, because that's exactly what symbol versioning
was designed to allow it to do. Older binaries use the older symbol
version and get the old behavior and everything continues to work.

Lintian is trying to ensure that the libc symbols in modules are correctly versioned and wired to the correct libc symbols. That's hard to check correctly, but will happen automatically if the module is linked with
libc, which is why Lintian is instead detecting a proxy for the problem
that it's trying to detect and complaining about modules not linked with
libc. The problem is that not linking with libc if one doesn't use any of
its symbols is both fine and more common these days due to increased use
of --as-needed.

The bug that Lintian is trying to detect is the presence of unversioned unresolved symbols in a shared library or module when the underlying
symbol to which that symbol should resolve is, in fact, versioned. The
problem is that the information required to diagnose that problem is
difficult for Lintian to acquire.

In my short experience running lintian, it has been right 99% of the
time, so this feels like a bug.

Oh, sure, I completely agree that the false positives are a bug.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)