bugGNU Octave - Bugs: bug #67247, mkoctfile failing with internal...

 
 

bug #67247: mkoctfile failing with internal error when linking with MSVC import library

Submitter:  Roland <roland67>
Submitted:  Thu 26 Jun 2025 06:30:16 PM UTC
   
 
Category:  Other Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 10.2.0 Release: 
Operating System:  * Microsoft Windows Fixed Release:  10.3.0 (current stable)
Planned Release:  10.3.0 (current stable)
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 09 Jul 2025 04:39:25 PM UTC, comment #15: 

Created a new report (#67299) right now including an example which does not require an external library to link with.

Roland <roland67>
Wed 09 Jul 2025 01:16:03 PM UTC, comment #14: 

Thanks again for the feedback.

I gather from your explanation that the binaries do actually get stripped with the `-s` option even when the temporary file persists occasionally.
That is probably out-of-scope of this report and should be addressed in a different one.
Could you please open a new report about those occasionally remaining temporary files with mkoctfile on Windows (if there isn't one yet)?

Closing this report as fixed (in Octave 10.3.0).

Markus Mützel <mmuetzel>
Group administrator
Wed 09 Jul 2025 11:32:39 AM UTC, comment #13: 

* Temporary files *

At the moment I have a DAQmxCompile.m script recompiling all the functions I did for the project. Once finnished I have not noticed any issue with deleting these object files. But selecting e.g. 10 such files in Windows explorer taking some time, so this might be long enough to release the lock.

This might be related to delays in Windows and/or Octave file handling. There are several similar things which might be related to that:

1. Sometimes mkoctfile fails to write the output complaining the oct file could not be opened for writing (is still in use). It looks like this happenes sometime if there is an error thrown running the code. In that case I'm not able to delete the oct file even from Windows file explorer. But I noticed the file(s) get released if I type "clear all" in Octave. So I have added that to my compile DAQmxCompile.m script before running the sequence of mkoctfile commands.

2. After starting Octave it sometimes takes up to a minute to popolate the file browser. During that period the file browser popup from the editor's file/open dialog display an empty list as well, while loading a file from the recent list working fine.

3. Sometimes it also takes very long to open a file in the editor from double-clicking it in the file browser (or do not open at all).

4. After creating a new .m file it takes quite a long time to recognise this by Octave. If you try to run this file before that period you'll get a function xxx undefined error in Octave. This is well known behaviour, but nobody knows why this happens. The workaround proposed is to use path(path()) in Octave to rescan the folder for files.

... but all of this might be a Windows problem. Quite frequent if I export a document as PDF this do not pop up in Windows file explorer a long time - but when I try to save again the application tells me the file is already existing.

* Stripping output *

The -s option is explicitly mentioned in mkoctfile help. Actually it is reducing oct file size from about 1.7 MBytes without to about 50 kBytes with using -s with the DAQmx library. Most of that size look like being functions linked from Octave as it is about the same size of the stripped output for DAQmx.lib (~940 kBytes) or VISA64.lib (21 kBytes) I'm using in a similar way. For both libraries I'm mapping single functions into respective oct files to call them from my scripts and functions. So far the size of the stripped output files range from 40-69 kBytes with all the functions I did so far.

While I don't know about the implementation details of the stripping process it does the job nicely.



Roland <roland67>
Wed 09 Jul 2025 08:52:32 AM UTC, comment #12: 

Thanks for testing.

Regarding the temporary files: I also recall seeing temporary object files not being deleted from the TEMP directory on Windows at some point. (Not sure if that "resolved itself" in the meantime.)
I could delete those files manually only after some time. My guess is that something (what?) is still holding a lock on those files which prevents them from being deleted earlier.
Maybe, something similar is happening here?

I don't know how the `strip` executable is implemented. Does it strip the binaries in-place? Or does it create a temporary file with the stripped binary and try to replace the original binary after that? Are the resulting .oct files actually stripped?

Markus Mützel <mmuetzel>
Group administrator
Wed 09 Jul 2025 07:36:38 AM UTC, comment #11: 

I used *octave-2025-07-07-20-58-release-w64-installer.exe*.

*Working well, no errors in the linking stage.*

Some notes:

1. The deprecated warnings are gone as well.

2. When I compile and link with option -s (strip output) I get additional files named something like "stZWKKZz" in many cases (typically about 40-90% of the compiles done, look like depending on the library I'm linking).
Some temporary files which get not deleted automatically? Compiling without -s these files are either not created or deleted so fast they do not show up in Windows explorer even for a short time.

Roland <roland67>
Wed 09 Jul 2025 06:48:28 AM UTC, comment #10: 

The buildbot worker that creates the nightly builds of Octave for Windows was down. It is up again now.
Could you please check if the latest installer from the "w64" section works for you?

Markus Mützel <mmuetzel>
Group administrator
Mon 07 Jul 2025 05:59:21 AM UTC, comment #9: 

Look like the nightly builds are not working at the moment. The website still says

Octave 10.2.1 (git rev: 883167f2fb718b5a9a01185a984cfabaa9bd1504) Sun, Jun 29, 2025

So no build since June 29th!

Using that build from the w64 section does not fix the bug, using the build from the mxe section as a temporary fix is still fine.

Roland <roland67>
Sun 06 Jul 2025 01:43:04 PM UTC, comment #8: 

I tried with cherry-picking that commit. But that didn't solve the issue with the example from comment #0.
jwe was fine with grafting the update to binutils to the release branch of MXE Octave. So, I went with that:
https://hg.octave.org/mxe-octave/rev/e261fc5e44cc

It should be part of Octave 10.3.0 when it will be released.

Could you please check whether your project builds correctly with the next nightly build (from Jul 7 or later) that you can download from here?
https://nightly.octave.org/#/download
(Please, use the installer that you find in the "w64" section.)

Marking as ready for test.

Markus Mützel <mmuetzel>
Group administrator
Sat 28 Jun 2025 10:43:30 AM UTC, comment #7: 

Per sr #111267: admins of the tracker can remove any attached files.

Ineiev <ineiev>
Fri 27 Jun 2025 06:44:07 PM UTC, comment #6: 

Looks like I missed to start the installer with admin privileges. I'm used to installers which ask even if started as regular user.

Of course I'll test and report once you tell me which version to download. That's the minimum I can do to support the project.

Roland <roland67>
Fri 27 Jun 2025 04:06:30 PM UTC, comment #5: 

I'm happy to read that linking works with the nightly builds from the default branch of MXE Octave.

The default branch also has a newer version of GCC. That is why you are seeing these warnings about deprecated declarations now.
You can just ignore those warnings for now. But we might need to think about whether we'd like to suppress these warning in that header file also in downstream code...

If I recall correctly, the installer only offers to install for all users if it is being run with elevated privileges ("Run as administrator").
Is your Windows user allowed to elevate privileges? Did you see a privilege elevation dialog from Windows when you started the installer?

It will probably take a couple of months until the next version of Octave (probably 10.3.0) will be released.

I'll try to cherry-pick that change from upstream to the release branch of MXE Octave. I'll let you know once that is done and a nightly build from the release branch with that change is available.
It would be nice if you could check whether that will work. (And you'll probably not get those deprecation warning with that build.)

Markus Mützel <mmuetzel>
Group administrator
Fri 27 Jun 2025 03:43:04 PM UTC, comment #4: 

Using the nightly build the code is compiled and linked. But I'm facing a log of "depreciated" warnings. Output attached.

One note about the nightly build (I've used the w64-installer.exe): It's not asking about installing for the curent user only or all users. But this does not matter now.

I have not tested the resulting .oct for functionality so far.
I'll use this build until the final release of 10.2.1 is out.

Thanks for checking and pointing me to that solution. I have some other ideas as well where I will need to link with libraries built from MSVC.

(file #57337)

Roland <roland67>
Fri 27 Jun 2025 06:43:30 AM UTC, comment #3: 

That looks like an issue with binutils 2.40 when it comes to linking with import libraries that have been produced by MSVC.
Afaict, that was fixed upstream with this change:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=80d4e113d7b9af8a5a36e5ea4399bca86050784f

Maybe, we can cherry-pick that changeset to the release branch of MXE Octave.
I'll try to do that during the weekend.

For the time being, you could try to use a nightly build from the default branch of MXE Octave (which was already updated to binutils 2.44 which includes that upstream change).
You can download a nightly build (make sure you select the one with "default" in its name) from here:
https://nightly.octave.org/#/download

Does the linker still fail with that import library if you try to use a nightly build from the default branch of MXE Octave?

Markus Mützel <mmuetzel>
Group administrator
Thu 26 Jun 2025 07:18:35 PM UTC, comment #2: 

Actually I have not checked in detail. But I own a developer license for that and the software can be used with their hardware only, so anyone who could make use of will also have the software.

If it is possible to hide from all but developers related to that bug it might be great.
Roland

Roland <roland67>
Thu 26 Jun 2025 07:04:23 PM UTC, comment #1: 

What are distribution terms for NIDAQ files (they are copyrighted by National Instruments)?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 26 Jun 2025 06:30:16 PM UTC, original submission:  

Compiling and linking the file attached fails with an internal error during linking, requesting to report this bug.

Save DAQmxTest.cc, and library in same folder (passing another folder via -L did not work at all)

Compile and link as shown below will result in error message

octave:13> mkoctfile -I. -L. -lNIDAQmx DAQmxTest.cc
C:/Program Files/GNU Octave/Octave-10.2.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: internal error: aborting at ldlang.c:527 in compare_section
C:/Program Files/GNU Octave/Octave-10.2.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: please report this bug
collect2.exe: error: ld returned 1 exit status
error: mkoctfile: building exited with failure status


Roland <roland67>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #57337:  DAQmxTest_Log.txt added by roland67 (4KiB - text/plain)
file #57332:  DAQmxTest.cc added by roland67 (5KiB - text/plain)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by roland67 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 15 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-07-09 mmuetzel Open/ClosedOpen Closed
        Fixed ReleaseNone 10.3.0 (current stable)
    2025-07-09 mmuetzel StatusReady For Test Fixed
    2025-07-09 mmuetzel Summarymkoctfile failing with internal error mkoctfile failing with internal error when linking with MSVC import library
    2025-07-06 mmuetzel StatusIn Progress Ready For Test
    2025-06-29 ineiev Attached File#57334 Removed
    2025-06-29 ineiev Attached File#57333 Removed
    2025-06-28 ineiev Carbon-CopyRemoved 46355 -
    2025-06-27 mmuetzel StatusNeed Info In Progress
        Planned ReleaseNone 10.3.0 (current stable)
    2025-06-27 roland67 Attached File- Added DAQmxTest_Log.txt, #57337
    2025-06-27 mmuetzel StatusNone Need Info
    2025-06-26 roland67 Attached File- Added DAQmxTest.cc, #57332
        Attached File- Added NIDAQmx.h, #57333
        Attached File- Added NIDAQmx.lib, #57334

    Back to the top

    Powered by Savane 3.15-e6e5.
    Corresponding source code