http://bugzilla.opensuse.org/show_bug.cgi?id=1141188 http://bugzilla.opensuse.org/show_bug.cgi?id=1141188#c1 --- Comment #1 from Dominique Leuenberger --- Tested a local build of schily with LTO disableD: this indeed does cure the issue. Before: mkisofs -o /tmp/test-iso.iso /mnt/test_autofs_local/ mkisofs: ]��lU: Unknown error 772999628 After: mkisofs -o /tmp/test-iso.iso /mnt/test_autofs_local/ Setting input-charset to 'UTF-8' from locale. Total translation table size: 0 Total rockridge attributes bytes: 0 Total directory bytes: 0 Path table size(bytes): 10 Max brk space used 21000 176 extents written (0 MB) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1141188 http://bugzilla.opensuse.org/show_bug.cgi?id=1141188#c2 Martin Liška changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.liska@suse.com --- Comment #2 from Martin Liška --- So the problem is following: include/schily/schily.h defines: /*PRINTFLIKE1*/ extern int error __PR((const char *, ...)) __printflike__(1, 2); /*PRINTFLIKE1*/ extern int gterror __PR((const char *, ...)) __printflike__(1, 2); #ifdef GT_ERROR #undef error #define error gterror #endif So it's a different declaration of function error that has a different signature in glibc: void error(int status, int errnum, const char *format, ...); And I bet GT_ERROR is not defined for all source files that are then linked with LTO. In LTO linking, we end up with duplicate and different function signatures and the from glibc is taken: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7f67331 in __strlen_avx2 () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff7f67331 in __strlen_avx2 () from /lib64/libc.so.6 #1 0x00007ffff7e731ae in __vfprintf_internal () from /lib64/libc.so.6 #2 0x00007ffff7e7418e in buffered_vfprintf () from /lib64/libc.so.6 #3 0x00007ffff7e71384 in __vfprintf_internal () from /lib64/libc.so.6 #4 0x00007ffff7e7b16a in locked_vfxprintf () from /lib64/libc.so.6 #5 0x00007ffff7e7b26d in __vfxprintf () from /lib64/libc.so.6 #6 0x00007ffff7f0173e in error_tail () from /lib64/libc.so.6 #7 0x00007ffff7f018bc in error () from /lib64/libc.so.6 #8 0x0000555555560b20 in main (argc=4, argv=0x7fffffffe8b8) at mkisofs.c:2801 while without LTO the libschily/gterror.c is taken: (gdb) bt #0 0x00007ffff7fa9a10 in error () from ../libs/x86_64-linux-gcc/pic/libschily.so.2.0 #1 0x00005555555602b9 in main (argc=4, argv=0x7fffffffe8b8) at mkisofs.c:2801 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1141188 http://bugzilla.opensuse.org/show_bug.cgi?id=1141188#c3 Jörg Schiling changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |joerg.schilling@fokus.fraun | |hofer.de --- Comment #3 from Jörg Schiling --- How is this related to LTO tape drives? Thank you for the stack trace! How do you set up things when it works and what differs when it does not work? When the problem occurs, you are obviously using a defective linker. Background: The error() function has been defined in 1980 by Charles River Data Systems by a group of former AT&T developers for the first real time UNIX clone. Libschily implements a UNOS-complient error() function and it seems that your libc defines a non-compliant variant that causes problems. If your linker would correctly honor the official link order rules, there still was no problem, since libschily is mentioned on the linker command line before libc. Since this kind of ambiguity for symbol names is quite frequent, I expect many more similar problems when using this linker. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1141188 http://bugzilla.opensuse.org/show_bug.cgi?id=1141188#c5 --- Comment #5 from Jörg Schiling --- If you were correct, mkisofs would not compile, but fortunately, mkisofs.c does not include /usr/include/error.h where glibc tries to overwrite the standard error() function defined in by a private glibc specific signature. Conclusion is still -> defective linker. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1141188 http://bugzilla.opensuse.org/show_bug.cgi?id=1141188#c7 --- Comment #7 from Jörg Schiling --- If you were correct, mkisofs would not compile. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1141188 http://bugzilla.opensuse.org/show_bug.cgi?id=1141188#c9 --- Comment #9 from Jörg Schiling --- As mentioned for bug https://bugzilla.suse.com/show_bug.cgi?id=1141105 already, the important issue is that both bug reports miss the needed information on what non-standard build procedure has been used to compile the failing binary. There has not been any report about a similar problem when the unmodified schily build system is in use on Linux. This is a proof that there is no problem in my software and as long as you do not document how you caused that problem, there is no way to help you. The problem may have been caused by using an unusual compiler or by enforcing unusual linker flags when compiling/linking the binary. BTW: This is linker bug with the linker used on the target platform and the best way to deal with this bug report is to forward it to a person with skill for the related link sub system. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1141188 http://bugzilla.opensuse.org/show_bug.cgi?id=1141188#c11 --- Comment #11 from Jörg Schiling --- (In reply to Martin Liška from comment #10)

Ok, the build procedure is to add -flto to C{,XX}FLAGS.

Thank you, this allows to reproduce the bug and to identify it as a gcc bug.

Yes, LTO is a cutting edge technology but has been thoroughly tested and used by the various projects during the last couple of years.

You are mistaken, this is obviously in pre-alpha state and if it had been properly tested, then this bug would never have been in a public release of gcc. See tests with that flag below...that show completely different results.

...

BTW: This is linker bug with the linker used on the target platform and the best way to deal with this bug report is to forward it to a person with skill for the related link sub system.

Yes, that's possible, but without a small test-case reproducer nobody will help us.

You are mistaken again: I am sorry to see that you refuse to forward the bug to the responsible people and that you even did not yet run the simple test posted by Jan Engelhardt in the other related bug. If you like to get a fix, just forward the bug report to the GCC people and I can grant you that they do not need additional information to what we already have. Let me explain why this is a problem of an untested pre-alpha feature in gcc: cc (Ubuntu 5.4.0-6ubuntu1~16.04.11) 5.4.0 20160609 together with the proposed test case from Jan Engelhardt results in: binding file /tmp/T/bin/mkisofs/tmp [0] to /lib/x86_64-linux-gnu/libc.so.6 [0]: normal symbol `error' [GLIBC_2.2.5] but the unexpected result is that my test binary /tmp/T/bin/mkisofs behaves correct even though ldd claims that error() is linked against the non-standard error() function in glibc. In other words: this feature causes unpredictable results - do not use it before it has been at least put into a beta state. If you like a smaller example than mkisofs, I recommend to use the command "p" from schilytools. Now to the other bugs in gcc caused by using -flto: static libraries that are project specific and that are not intended to be published as separate .a files are not linked at all: smake LINKMODE=dynamic INS_BASE=/tmp/T COPTX=-flto C++OPTX=-flto LDOPTX=-flto ... ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/obosh" ==> LINKING "OBJ/x86_64-linux-gcc/obosh" /tmp/ccNsUg91.ltrans9.ltrans.o: In function `main': <artificial>:(.text+0x60b): undefined reference to `opt_sp' /tmp/ccNsUg91.ltrans14.ltrans.o: In function `optget': <artificial>:(.text+0x2c): undefined reference to `opt_sp' <artificial>:(.text+0x56): undefined reference to `opt_sp' <artificial>:(.text+0x89): undefined reference to `opt_sp' <artificial>:(.text+0xb6): undefined reference to `opt_sp' collect2: error: ld returned 1 exit status A similar problem exists with SCCS that links against the AT&T internal libs libcassi.a libcomobj.a libmpw.a and with SunPro Make, that links aginst internal libs from Sun: libvroot.a libmksh.a libbsd.a Let me give the background for the Bourne Shell mentioned with error outout above: The Bourne Shell and SCCS need a POSIX compliant getopt() that does not exist in glibc (GNU getopt() is definitely not POSIX compliant and before libgetopt has been created in late 2006, SCCS did not work on Linux). The Bourne Shell in addition needs AT&T specific extensions in getopt() to permit getopt() to be used repeated for the shell builtins and even mixed for the shell builtin "getopts(1)". To be able to support combined options like -abc, getopt() needs to be able to keep an internal state about which letter in a combined option string is currently parsed. To make this work with the shell builtin getopts(1), it needs to restore that state after calling getopt() for internal use. This feature is implemented with the additional external variable opt_sp that is flagged above even though present. The error message above shows that gcc does not link against libgetopt.a or is unable to link against libgetopt.a even though it is present in the linker search path and even though -lgetopt has been specified. See below for a statement on static linking with -flto. If this problem does not appear with your local GCC version, this is just another proof for the untested state of this gcc feature. BTW: If I use only static linking with schilytools internal libraries and call: smake COPTX=-flto C++OPTX=-flto LDOPTX=-flto at top level after the libs/*/ directory has been emptied, none of the comands links and all linker calls complain about the missing entries that are expected from the libraries in $SRCROOT/libs. It is obvious that this gcc feature still needs a lot of work before it may become useful. -- You are receiving this mail because: You are on the CC list for the bug.