[Bug lto/88422] collect2.exe: fatal error: lto-wrapper returned 1 exit status: file not recognized: file truncated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88422
--- Comment #6 from Nidal Faour ---
Andrew Pinski is right, after chasing this bug with the help of Andrew Burgess
in the file simple-object.c, calling the creat
outfd = creat (dest, 00777);
the creat function wraps the open function but do not pass open mode
and the fix mentioned by Adrew was as follow:
When opening output files for simple-object creation, we must ensure that the
file is opened in binary mode. Failure to do so causes file corruption, and
LTO failure on Windows targets.
libiberty/ChangeLog:
PR lto/88422
* simple-object.c (O_BINARY): Define if not already defined.
(simple_object_copy_lto_debug_sections): Create file in binary
mode.
---
libiberty/ChangeLog | 7 +++
libiberty/simple-object.c | 6 +-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/libiberty/simple-object.c b/libiberty/simple-object.c index
c1f38cee8ee..e061073abd1 100644
--- a/libiberty/simple-object.c
+++ b/libiberty/simple-object.c
@@ -44,6 +44,10 @@ Boston, MA 02110-1301, USA. */ #define SEEK_SET 0 #endif
+#ifndef O_BINARY
+# define O_BINARY 0
+#endif
+
#include "simple-object-common.h"
/* The known object file formats. */
@@ -349,7 +353,7 @@ simple_object_copy_lto_debug_sections (simple_object_read
*sobj,
return errmsg;
}
- outfd = creat (dest, 00777);
+ outfd = open (dest, O_CREAT|O_WRONLY|O_TRUNC|O_BINARY, 00777);
if (outfd == -1)
{
*err = errno;
--
[Bug lto/88422] collect2.exe: fatal error: lto-wrapper returned 1 exit status: file not recognized: file truncated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88422 --- Comment #5 from Nidal Faour --- i've used the RV gcc official toolchain and reverted the patch as Jim did. and it passed in the test case, but when i moved to a bigger code, i failed again to build. and it turned out that it passed only if i drop the -g option from the compiling command. when using the -g option it will get the "file not recognized: file format not recognized" again. i've downloaded the RV toolchain from: https://github.com/riscv/riscv-gnu-toolchain configuration for linux building: ./configure --with-arch=rv64imafdc --with-abi=lp64d --enable-multilib --prefix= configuration for windows building: ./configure --with-arch=rv64imafdc --with-abi=lp64d --enable-multilib --without-system-zlib --with-cmodel=medany --with-host=x86_64-w64-mingw32 --prefix= test case can be found at: https://github.com/westerndigitalcorporation/riscv32-Code-density-test-bench/tree/master/lto_test_case
[Bug c/88422] New: collect2.exe: fatal error: lto-wrapper returned 1 exit status: file not recognized: file truncated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88422 Bug ID: 88422 Summary: collect2.exe: fatal error: lto-wrapper returned 1 exit status: file not recognized: file truncated Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: nidal.faour at wdc dot com Target Milestone: --- Created attachment 45192 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45192=edit test case to reproduce the the failure When attempt to build a simple code including one assembly file and one c code file while calling a c function from the assembly code and using the lto in linkage stage I encountered an error in the lto-wrapper where ld returned 1 exit status, with file not recognized: file truncated. the build has been done in windows machine. the toolchain used: gcc-arm-8.2-2018.08-i686-mingw32-arm-eabi download link: https://developer.arm.com/-/media/Files/downloads/gnu-a/8.2-2018.08/gcc-arm-8.2-2018.08-i686-mingw32-arm-eabi.tar.xz?revision=37b1357c-06a5-4721-8fde-533b0028c083=en gcc build info: Using built-in specs. COLLECT_GCC=..\gcc-arm-8.2\bin\arm-eabi-gcc.exe COLLECT_LTO_WRAPPER=c:/tmp/gcc-arm-8.2/bin/../libexec/gcc/arm-eabi/8.2.1/lto-wrapper.exe Target: arm-eabi Configured with: /tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot/mingw32-i686--arm-eabi/build/src/gcc/configure --target=arm-eabi --prefix=/tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot/mingw32-i686--arm-eabi/build/build-mingw-arm-eabi/install// --with-gmp=/tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot/mingw32-i686--arm-eabi/build/build-mingw-arm-eabi/host-tools --with-mpfr=/tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot/mingw32-i686--arm-eabi/build/build-mingw-arm-eabi/host-tools --with-mpc=/tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot/mingw32-i686--arm-eabi/build/build-mingw-arm-eabi/host-tools --with-isl=/tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot/mingw32-i686--arm-eabi/build/build-mingw-arm-eabi/host-tools --with-pkgversion='GNU Toolchain for the A-profile Architecture 8.2-2018-08 (arm-rel-8.23)' --disable-shared --disable-nls --disable-threads --disable-tls --enable-checking=release --enable-languages=c,c++,fortran --with-newlib --with-multilib-list=aprofile --with-libiconv-prefix=/tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot/mingw32-i686--arm-eabi/build/build-mingw-arm-eabi/host-tools --host=i686-w64-mingw32 Thread model: single gcc version 8.2.1 20180802 (GNU Toolchain for the A-profile Architecture 8.2-2018-08 (arm-rel-8.23)) Attached a simple test case [lto_test_arm.zip] that reproduce the failure.
