'ld' file truncation

[Gregory A Failing]

Literally out of the blue I start getting error messages from 'gcc' (Arnold's Windows package) to wit:

Begin compile of app-libs.sos into app-libs.dll
cobc (GnuCOBOL) 3.2.0
Built     Jul 28 2023 19:10:09  Packaged  Jul 28 2023 17:02:56 UTC
C version (MinGW) "9.2.0"
loading standard configuration file 'default.conf'
command line:   C:\Users\gafli\GnuCobol\bin\cobc.exe -m -v -A -std=gnu17 -static -Wall -fnotrunc -Wobsolete -I C:\gafling\Projects\Lookin_Good\sorc -L C:\Users\gafli\GnuCobol\lib -L C:\Users\gafli\GnuCobol\bin -L C:\gafling\Projects\Lookin_Good\exec -l pdcurses -l app-libs -T C:\gafling\Projects\Lookin_Good\sorc\lsts\app-libs.lst -o C:\gafling\Projects\Lookin_Good\exec\app-libs.dll C:\gafling\Projects\Lookin_Good\sorc\app-libs.sos
preprocessing:  C:\gafling\Projects\Lookin_Good\sorc\app-libs.sos -> C:\Users\gafli\AppData\Local\Temp\cob4284_0.cob
return status:  0
parsing:        C:\Users\gafli\AppData\Local\Temp\cob4284_0.cob (C:\gafling\Projects\Lookin_Good\sorc\app-libs.sos)
return status:  0
translating:    C:\Users\gafli\AppData\Local\Temp\cob4284_0.cob -> C:\Users\gafli\AppData\Local\Temp\cob4284_0.c (C:\gafling\Projects\Lookin_Good\sorc\app-libs.sos)
executing:      gcc -I"C:\Users\gafli\GnuCobol\include" -std=gnu17
                -I"C:\gafling\Projects\Lookin_Good\sorc" -shared -DDLL_EXPORT
                -DPIC -Wl,--export-all-symbols -Wl,--enable-auto-import
                -Wl,--enable-auto-image-base -o
                "C:\gafling\Projects\Lookin_Good\exec\app-libs.dll"
                "C:\Users\gafli\AppData\Local\Temp\cob4284_0.c"
                -L"C:\Users\gafli\GnuCobol\lib"
                -L"C:\Users\gafli\GnuCobol\bin"
                -L"C:\gafling\Projects\Lookin_Good\exec" -L/mingw/lib -lcob
                -l"pdcurses" -l"app-libs"
C:\Users\gafli\GnuCobol\bin/ld.exe: C:\gafling\Projects\Lookin_Good\exec/app-libs.dll: file not recognized: file truncated
collect2.exe: error: ld returned 1 exit status
return status:  1
GnuCOBOL Compile Returncode = 1

My compile script has not changed in weeks with the single addition of '-static' to the compile call. Removing the '-static' from the call makes no difference.

The output file name is deleted just prior to the compile.

Testing with single program source files and source programs with multiple functions within matters not - all bomb out like this.

Any ideas accepted ...

Gregory

[Vincent (Bryan) Coen]

On 13/10/2025 14:01, Gregory A Failing wrote:

Literally out of the blue I start getting error messages from 'gcc'
(Arnold's Windows package) to wit:

|Have you had any system updates since it was last successful ?

If so take a look at what was.

|

[Gregory A Failing]

No updates to system nor Arnold's package. Obviously changes to Cobol
source code are being made.

G

-----Original Message-----
From: discussion@gnucobol.p.re.sourceforge.net
discussion@gnucobol.p.re.sourceforge.net On Behalf Of Vincent (Bryan) Coen
Sent: Monday, October 13, 2025 8:29 AM
To: [gnucobol:discussion] cobol@discussion.gnucobol.p.re.sourceforge.net
Subject: [gnucobol:discussion] Re: 'ld' file truncation

On 13/10/2025 14:01, Gregory A Failing wrote:

Literally out of the blue I start getting error messages from 'gcc'
(Arnold's Windows package) to wit:

|Have you had any system updates since it was last successful ?

If so take a look at what was.

|

---

'ld' file
truncation

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/gnucobol/discussion/cobol/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Chuck Haatvedt]

Gregory, it appears that the output file is app-libs.dll and you are also telling the linker "ld" to load that file as input as well.

The error "file not recognized: File truncated" when using GCC and LD on Windows 10 typically indicates an issue with file integrity or how the compiler and linker are handling output files. This error can arise from several scenarios:
1. Input and Output File Conflicts:

Writing to the same file being read:
This occurs when the output file of a compilation or linking step is also used as an input file for the same or a subsequent step. For example, if you try to compile a.c and output to a.out (default on some systems) and then immediately try to use a.out as a source file, the compiler might truncate the output file while attempting to read it as input.

    Chuck Haatvedt

ps.. can you confirm if this is actually the issue ? it appears the command line shows the output file and the input to the linker being the same file.

[Simon Sobisch]

I can confirm this with his given outputs :-)
The one that raised an error has

-o "C:\gafling\Projects\Lookin_Good\exec\app-libs.dll"
-l"app-libs"

most likely executed in that directory.

The output of the new one is a -x run, creating an executable.

In this case there's just an -l too much when building the app-libs.dll in the first place.

[Gregory A Failing]

OK ... an interesting development ... when I switch over to Chuck's Windows package the issue disappears.

Begin compile of test-applogger.CBL into test-applogger.exe
cobc (branches/gnucobol-3.x r5575M) 3.3-dev.5575
Built     Aug 31 2025 15:06:53  Packaged  Jul 30 2025 18:42:59 UTC
C version (MinGW) "15.2.0"
loading standard configuration file 'default.conf'
command line:   C:\gafling\GNUCobol\bin\cobc.exe -x -v -A -std=gnu17 -static -Wall -fnotrunc -Wobsolete -I C:\gafling\Projects\Lookin_Good\sorc -L C:\gafling\GNUCobol\lib -L C:\gafling\GNUCobol\bin -L C:\gafling\Projects\Lookin_Good\exec -l pdcurses -l app-libs -T C:\gafling\Projects\Lookin_Good\sorc\lsts\test-applogger.lst -o C:\gafling\Projects\Lookin_Good\exec\test-applogger.exe C:\gafling\Projects\Lookin_Good\sorc\test-applogger.CBL
preprocessing:  C:\gafling\Projects\Lookin_Good\sorc\test-applogger.CBL -> C:\Users\gafli\AppData\Local\Temp\cob6100_0.cob
return status:  0
parsing:        C:\Users\gafli\AppData\Local\Temp\cob6100_0.cob (C:\gafling\Projects\Lookin_Good\sorc\test-applogger.CBL)
return status:  0
translating:    C:\Users\gafli\AppData\Local\Temp\cob6100_0.cob -> C:\Users\gafli\AppData\Local\Temp\cob6100_0.c (C:\gafling\Projects\Lookin_Good\sorc\test-applogger.CBL)
executing:      gcc -c -I"C:\gafling\GNUCobol\include" -std=gnu17
                -I"C:\gafling\Projects\Lookin_Good\sorc" -o
                "C:\Users\gafli\AppData\Local\Temp\cob6100_0.o"
                "C:\Users\gafli\AppData\Local\Temp\cob6100_0.c"
return status:  0
executing:      gcc -Wl,--export-all-symbols -Wl,--enable-auto-import
                -Wl,--enable-auto-image-base -o
                "C:\gafling\Projects\Lookin_Good\exec\test-applogger.exe"
                "C:\Users\gafli\AppData\Local\Temp\cob6100_0.o"
                -fstack-protector-strong -fstack-clash-protection
                -L"C:\gafling\GNUCobol\lib" -L"C:\gafling\GNUCobol\bin"
                -L"C:\gafling\Projects\Lookin_Good\exec" -L/mingw64/lib -lcob
                -l"pdcurses" -l"app-libs"
return status:  0
GnuCOBOL Compile Returncode = 0

Text program looks good - user library looks good (all sub functions referenced in the '.dll').

I guess the newer version of the compiler is the reason.

If anyone wants some diagnostic work done on Arnold's package today, I will have the time.

Gregory

[Chuck Haatvedt]

Gregory,

the build that Arnold has is GNUCOBOL 3.2 the release version. The version which you downloaded from my link is built from the current source plus some of my most recent additions. There were also many changes done to GNUCOBOL since the 3.2 release. So I am not sure if the more recent GCC compiler was the cause of the resolution or changes to GNUCOBOL itself.

In any event, since the issue is resolved, perhaps we should continue on the path of improving the latest build of GNUCOBOL, just my personal opinion.

       Chuck Haatvedt

[Simon Sobisch]

Is that a 32 or 64 bit built? Arnold's is 32.

In any case: all of the C compiler, assembler and linker are much newer in the MSYS2 (Chuck's build).
I guess that if you download the old GC3.2 MSYS2 builds from Arnold's site they work as well, don't they?

What about the MinGW nightly?

[Gregory A Failing]

I appreciate the comments and suggestions. Since I switched to Chuck's Windoze package the issue no longer presents so all is well.

The cause of my initial consternation is this: when compiling Arnold's version on Thursday all was working well. I have been using this compiler for weeks. On Friday afternoon the errors started. The only change was the addition of a new '.dll' (app-libs.dll) to the project. The new library compiles clean; no compiler complaints. All of this using Arnold's package. Very strange ...

Thanks again, y'all.

Gregory

[Gregory A Failing]

A-HA! The geniuses at the helm of GC have come thru again. Using Chuck's package I compile 'app-libs' and the following shows:

Begin compile of app-libs.sos into app-libs.dll
Could Not Find C:\gafling\Projects\Lookin_Good\exec\app-libs.dll
cobc (branches/gnucobol-3.x r5575M) 3.3-dev.5575
Built     Aug 31 2025 15:06:53  Packaged  Jul 30 2025 18:42:59 UTC
C version (MinGW) "15.2.0"
loading standard configuration file 'default.conf'
command line:   C:\gafling\GNUCobol\bin\cobc.exe -m -v -A -std=gnu17 -static -Wall -fnotrunc -Wobsolete -I C:\gafling\Projects\Lookin_Good\sorc -L C:\gafling\GNUCobol\lib -L C:\gafling\GNUCobol\bin -L C:\gafling\Projects\Lookin_Good\exec -l pdcurses -l app-libs -T C:\gafling\Projects\Lookin_Good\sorc\lsts\app-libs.lst -o C:\gafling\Projects\Lookin_Good\exec\app-libs.dll C:\gafling\Projects\Lookin_Good\sorc\app-libs.sos
preprocessing:  C:\gafling\Projects\Lookin_Good\sorc\app-libs.sos -> C:\Users\gafli\AppData\Local\Temp\cob19580_0.cob
return status:  0
parsing:        C:\Users\gafli\AppData\Local\Temp\cob19580_0.cob (C:\gafling\Projects\Lookin_Good\sorc\app-libs.sos)
return status:  0
translating:    C:\Users\gafli\AppData\Local\Temp\cob19580_0.cob -> C:\Users\gafli\AppData\Local\Temp\cob19580_0.c (C:\gafling\Projects\Lookin_Good\sorc\app-libs.sos)
executing:      gcc -I"C:\gafling\GNUCobol\include" -std=gnu17
                -I"C:\gafling\Projects\Lookin_Good\sorc" -shared -DDLL_EXPORT
                -DPIC -Wl,--export-all-symbols -Wl,--enable-auto-import
                -Wl,--enable-auto-image-base -o
                "C:\gafling\Projects\Lookin_Good\exec\app-libs.dll"
                "C:\Users\gafli\AppData\Local\Temp\cob19580_0.c"
                -fstack-protector-strong -fstack-clash-protection
                -L"C:\gafling\GNUCobol\lib" -L"C:\gafling\GNUCobol\bin"
                -L"C:\gafling\Projects\Lookin_Good\exec" -L/mingw64/lib -lcob
                -l"pdcurses" -l"app-libs"
return status:  0
GnuCOBOL Compile Returncode = 0

As Chuck and Simon quickly noticed this compile was creating 'app-libs.dll' while trying to link the same file. This fails using Arnold's package (msys32?) but works with Chuck's (msys64). The same file 'in' and 'out' conflict must have been corrected in msys64.

Interestingly I have not run into this scenario under Linux where my big project has about 70 '.so' libraries which are all referenced in my standard Makefile recipes.

Anyway, good work guys!

Gregory