bugGNU Octave - Bugs: bug #54182, .o files created by mkoctfile...


bug #54182: .o files created by mkoctfile should be removed

Submitter:  Rik <rik5>
Submitted:  Mon 25 Jun 2018 05:56:37 PM UTC
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  jwe
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Wed 27 Jun 2018 05:50:34 PM UTC, comment #20: 

I pushed one additional change:


With this change, and the proposed change for bug #54165, I expect of-control will also build correctly again.  Testing now and will push a change for the other bug (in mxe-octave) soon.

John W. Eaton <jwe>
Group administrator
Wed 27 Jun 2018 05:39:34 PM UTC, comment #19: 

Finally able to build the MXE version successfully.  Going to close this report.

Rik <rik5>
Group administrator
Wed 27 Jun 2018 10:43:31 AM UTC, comment #18: 

Please ignore the last part of my previous post. With a current tip without local changes, everything is working as expected.

That means I still see bug #54165 but the GUI opens without error.

Markus Mützel <mmuetzel>
Group administrator
Wed 27 Jun 2018 09:02:10 AM UTC, comment #17: 

After make clean, of-control fails to cross-build with a different error that looks like bug #54165.

After removing of-control, of-signal (depends on of-control), of-communications and of-image (both depend on of-signal) from the list of of-packages to build, all other of-packages compiled without errors. So it looks like this is fixed.

The resulting package doesn't start however. I can see the following in the Windows application error log:

Name der fehlerhaften Anwendung: octave-cli.exe, Version:, Zeitstempel: 0x00000000
Name des fehlerhaften Moduls: liboctave-5.dll, Version:, Zeitstempel: 0x00000000
Ausnahmecode: 0xc0000005
Fehleroffset: 0x006aafee
ID des fehlerhaften Prozesses: 0x2160
Startzeit der fehlerhaften Anwendung: 0x01d40df49fa54fea
Pfad der fehlerhaften Anwendung: D:\Repositories\Octave\test\octave-2018-06-27-10-01-w32_wrappers\octave-2018-06-27-10-01-w32\bin\octave-cli.exe
Pfad des fehlerhaften Moduls: D:\Repositories\Octave\test\octave-2018-06-27-10-01-w32_wrappers\octave-2018-06-27-10-01-w32\bin\liboctave-5.dll
Berichtskennung: 3e8ea0ba-39bb-4c7a-97bf-e79c52c5c2b9
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

But that might be unrelated or due to some local changes.
I'll open a new bug report if I can still see this without any local changes.

Markus Mützel <mmuetzel>
Group administrator
Wed 27 Jun 2018 02:20:33 AM UTC, comment #16: 

Did you run "./bootstrap" before "make dist-gzip"?

Markus Mützel <mmuetzel>
Group administrator
Tue 26 Jun 2018 11:01:34 PM UTC, comment #15: 

Here is a bit more of the log.  The problem is in mkoctfile.exe

  CXXLD    src/mkoctfile.exe
liboctave/wrappers/.libs/libwrappers.a(liboctave_wrappers_libwrappers_la-mkostemps-wrapper.o): In function `octave_mkostemps_wrapper':
/home/rik/wip/Projects_Mine/mxe-octave/tmp-default-octave/octave-5.0.0/liboctave/wrappers/mkostemps-wrapper.c:39: undefined reference to `mkostemps'
collect2: error: ld returned 1 exit status
Makefile:14972: recipe for target 'src/mkoctfile.exe' failed
make[4]: *** [src/mkoctfile.exe] Error 1

Rik <rik5>
Group administrator
Tue 26 Jun 2018 10:58:11 PM UTC, comment #14: 

Not quite the same thing, but I'm also not able to build MXE octave.  I used 'make dist-gzip' to create a gzip version of the latest development source code.  I copied that in to the pkg/ directory of mxe octave, and then commented out the PKG_URL line in src/default-octave.mk so that the gzip file will be used.

When I try to build I get an error about mkostemps.

liboctave/wrappers/.libs/libwrappers.a(liboctave_wrappers_libwrappers_la-mkostemps-wrapper.o): In function `octave_mkostemps_wrapper':
/home/rik/wip/Projects_Mine/mxe-octave/tmp-default-octave/octave-5.0.0/liboctave/wrappers/mkostemps-wrapper.c:39: undefined reference to `mkostemps'
collect2: error: ld returned 1 exit status

Any ideas what is missing?

Rik <rik5>
Group administrator
Tue 26 Jun 2018 07:44:04 PM UTC, comment #13: 

I am still seeing the same error. I'll try again after a "make clean". But that might take a while.

Markus Mützel <mmuetzel>
Group administrator
Tue 26 Jun 2018 06:17:38 PM UTC, comment #12: 

OK, I hope this is the last fix needed for this bug report:


Sorry for all the trouble.

John W. Eaton <jwe>
Group administrator
Tue 26 Jun 2018 06:05:07 PM UTC, comment #11: 

It's only supposed to fail if you use both -o and -c.  Maybe I screwed up the logic.

John W. Eaton <jwe>
Group administrator
Tue 26 Jun 2018 05:51:46 PM UTC, comment #10: 

The cross-build stopped for of-control at the following command:

/home/osboxes/Documents/Repositories/Octave/mxe-octave-6/usr/bin/x86_64-w64-mingw32-mkoctfile --verbose -c *.f
mkoctfile: may not use -c and -o with multiple source files
Makefile:27: recipe for target 'slicotlibrary.a' failed
make[2]: *** [slicotlibrary.a] Error 1

If I am reading the commit message to http://hg.savannah.gnu.org/hgweb/octave/rev/f35bd5cddedd correctly, it should still be possible to use multiple source files if only "-c" (not also "-o") is specified.
Is that a bug in mkoctfile or in how of-control is using it?

Markus Mützel <mmuetzel>
Group administrator
Tue 26 Jun 2018 03:54:23 PM UTC, comment #9: 

Sounds reasonable.

Cross-building the default-octave target has completed successfully with that change. Now waiting for the rest of the cross-build to finish (might take a while).

Markus Mützel <mmuetzel>
Group administrator
Tue 26 Jun 2018 03:23:14 PM UTC, comment #8: 

No, we should not be using gnulib when CROSS is defined.  When CROSS is defined, we are building an executable to run on Linux that builds .oct files that are intended to run on Windows.  And mxe-octave has only configured and built a copy of gnulib for Windows, not Linux.

I fixed it this way instead:


There is no distinction between text and binary files on Linux systems, so O_BINARY shouldn't be needed in the flags argument of mkostemps anyway.

If at some point we decide that we do need the portability fixes that gnulib provides when we are building mkoctfile with CROSS defined, then we'll have to fix the mxe-octave and Octave build systems so that when cross compiling, we cross-compile gnulib AND we also build a native version that can be used when building the cross-compiler version of the tools like mkoctfile (i.e., the one that runs on Linux and creates Windows .oct files).  That seems like a lot of unnecessary work at this point so I only want to do it if it is really needed.

John W. Eaton <jwe>
Group administrator
Tue 26 Jun 2018 03:02:05 PM UTC, comment #7: 

I mis-read that gnulib page: Those constants are actually ONLY defined on Windows platforms. That explains why it wouldn't work if we used the default Linux header.

Markus Mützel <mmuetzel>
Group administrator
Tue 26 Jun 2018 02:51:47 PM UTC, comment #6: 

Thanks for the explanation.

I am still seeing the same error with http://hg.savannah.gnu.org/hgweb/octave/rev/ec2492a2af6a

Maybe a different header is picked? Should there be a "-Ilibgnu" somewhere in the makefile rule?

Markus Mützel <mmuetzel>
Group administrator
Tue 26 Jun 2018 01:50:24 PM UTC, comment #5: 

The CROSS macro in mkoctfile.in.cc refers to building a cross-compiler aware version of mkoctfile that can be used to cross compile .oct file for Windows builds of Octave, not that mkoctfile itself is being cross compiled.

We do use the wrapper and gnulib functions when we are cross-compiling mkoctfile (to install and run on Windows systems).  That works because we've already cross-compiled the gnulib and wrapper libraries for Windows.  But when we are trying to build the cross-compiler aware version of mkoctfile, we can't use those.  Since there were originally just a few functions we needed, we simply provided simple versions of them inside mkoctfile.in.cc.

This approach works OK since we are typically building the cross-compiler aware version of mkoctfile on a modern Linux system that shouldn't need to have gnulib to fix POSIX portability problems.

I'll fix.

John W. Eaton <jwe>
Group administrator
Tue 26 Jun 2018 01:39:56 PM UTC, comment #4: 

After that change, cross-building for Windows with MXE Octave fails with the following error:

src/x86_64-w64-mingw32-mkoctfile.cc: In function ‘int octave_mkostemps_wrapper(char*, int)’:
src/x86_64-w64-mingw32-mkoctfile.cc:76:38: error: ‘O_BINARY’ was not declared in this scope
   return mkostemps (tmpl, suffixlen, O_BINARY);
src/x86_64-w64-mingw32-mkoctfile.cc:76:38: note: suggested alternative: ‘L_INCR’
   return mkostemps (tmpl, suffixlen, O_BINARY);
Makefile:27762: recipe for target 'src/x86_64-w64-mingw32-mkoctfile' failed

Gnulib's fcntl.h defines O_BINARY for that platform. [1]
Do we want to include gnulib headers when building mkoctfile?  I don't know the background for not using our wrappers when cross-compiling.

[1]: https://www.gnu.org/software/gnulib/manual/html_node/fcntl_002eh.html

Markus Mützel <mmuetzel>
Group administrator
Mon 25 Jun 2018 08:55:29 PM UTC, comment #3: 

Yes, we should include mkostemps in the list of gnulib modules we use.  I mistakenly thought it came along with the mkostemp function that we were already using.  Added here:


John W. Eaton <jwe>
Group administrator
Mon 25 Jun 2018 08:32:19 PM UTC, comment #2: 

Wow.  Pulled on a thread and the whole sweater came undone.

It all seems to work though.  I had to install the generated version of Octave in order for the correct mkoctfile to be picked up.  After that testing worked fine.

Shouldn't "mkostemps" be added as a module in bootstrap.conf if we are using it from gnulib?  See https://www.gnu.org/software/gnulib/manual/html_node/mkostemps.html#mkostemps

Rik <rik5>
Group administrator
Mon 25 Jun 2018 07:35:52 PM UTC, comment #1: 

I checked in a several changes:

We were also allowing -c and -o to be used when there were multiple source files but shouldn't:


Then I noticed a crash on string indexing:


I made this one separate just for clarity, but it is needed by the last change below:


This is the real fix and so is the only one I tagged with this bug report number:


John W. Eaton <jwe>
Group administrator
Mon 25 Jun 2018 05:56:37 PM UTC, original submission:  

When running the test suite multiple .o object files are created at the top-level directory during testing of the MEX interface.

The root cause is that 'mkoctfile --mex' generates not only the output .mex file, but also the intermediate .o file.

This is not how the analogous gcc command works. 'gcc hello.c' produces only 'a.out'.  The intermediates are removed/suppressed.  If you want to only perform compilation, but prevent the linker from running, you need to specifically give the option '-c'.

Octave should change its interface to do something similar and only preserve the object files when specifically requested.

Rik <rik5>
Group administrator


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

Attach Files:

No files currently attached


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 jwe (Posted a comment)
  • -email is unavailable- added by rik5 (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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-06-27 rik5 StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2018-06-26 mmuetzel StatusFixed In Progress
        Open/ClosedClosed Open
    2018-06-25 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2018-06-25 jwe StatusConfirmed Ready For Test

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code