Created attachment 534602 [details] dlibtool build log When building sandbox with slibtool instead of libtool on a 32-bit linux install I encounter a build issues with undefined for '__umoddi3' and '__udivdi3'. From some research these appear to caused by 64-bit arithmetic functions where libgcc.a is required on 32-bit platforms. This can be fixed by explicitly added as a dependency for libsbutil and has been tested on 32-bit and 64-bit installs with libtool and slibtool using gcc and clang. My presumption is that libtool is secretly adding this dependency and does not fail as a result. I've attached a full build log with dlibtool and a patch that resolves this. Additionally the following issue is similar, but not the same. https://bugs.gentoo.org/show_bug.cgi?id=656184
Created attachment 534604 [details, diff] Patch to fix the build with slibtool.
Comment on attachment 534604 [details, diff] Patch to fix the build with slibtool. Thank you for your patch. However, adding '-lgcc' is clearly wrong for users of compilers other than GCC, in particular clang with compiler-rt.
Thanks for the reply. Yes I was told in #midipix where slibtool development is discussed that this is wrong after I made this. 00:29 <@midipix> orbea: the problem is that sandbox passes -nodefaultlibs 00:30 <@midipix> (and then manually passes -lc, which surely defeats the purpose of -nodefaultlibs) Removing -nodefaultlibs from libsandbox/Makefile.am also seems to work and I've attached another example patch. Of course if a better solution can be found that is preferred.
Created attachment 534634 [details, diff] Alternative slibtool patch.
The slibtool dev took a closer look at this issue and the problem is that libtool has a list of "known" linker flags and will swallow any which are not on this list. Its possible to grep the generated libtool in the build directory for any linker flags and since 'nodefaultlibs' does not return any output its not on this list. The result is that libtool swallows '-nodefaultlibs' and it is never passed to the compiler driver (gcc), it has no effect with builds using GNU libtool. On the other hand slibtool does not have this behavior and will pass '-nodefaultlibs' to the compiler even if this is not correct. The second patch which removes '-nodefaultlibs' from libsandbox/Makefile.am should be the correct and portable solution.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/sandbox.git/commit/?id=8bb9e5e7607ff12f8119729077d3d420e999f7ee commit 8bb9e5e7607ff12f8119729077d3d420e999f7ee Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2018-07-19 11:27:09 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2018-07-19 11:27:09 +0000 libsandbox: Remove meaningless/broken -nodefaultlibs Remove '-nodefaultlibs' from linking flags for libsandbox as it is apparently meaningless and broken at the same time. When regular libtool is used, it silently strips the option, making it meaningless. When slibtool is used instead, it passes the option which causes linking to fail due to undefined symbols. Thanks to the bug reporter and slibtool devs from researching the problem in detail. Bug: https://bugs.gentoo.org/657184 libsandbox/Makefile.am | 1 - 1 file changed, 1 deletion(-)
Forgot to set this as fixed.
