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

 
 

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

Submitted by:  Rik <rik5>
Submitted on:  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:  John W. Eaton <jwe>
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

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

I pushed one additional change:

http://hg.savannah.gnu.org/hgweb/octave/rev/2710440ea566

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>
Project AdministratorIn charge of this item.
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>
Project 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>
Project Member
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:

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>
Project Member
Wed 27 Jun 2018 02:20:33 AM UTC, comment #16:

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

Markus Mützel <mmuetzel>
Project Member
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

Rik <rik5>
Project 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.

Any ideas what is missing?

Rik <rik5>
Project 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>
Project Member
Tue 26 Jun 2018 06:17:38 PM UTC, comment #12:

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

http://hg.savannah.gnu.org/hgweb/octave/rev/b61f3500651f

Sorry for all the trouble.

John W. Eaton <jwe>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
Tue 26 Jun 2018 05:51:46 PM UTC, comment #10:

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

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>
Project Member
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>
Project Member
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:

http://hg.savannah.gnu.org/hgweb/octave/rev/ace13ff63b90

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>
Project AdministratorIn charge of this item.
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>
Project Member
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>
Project Member
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>
Project AdministratorIn charge of this item.
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:

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>
Project Member
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:

http://hg.savannah.gnu.org/hgweb/octave/rev/b1aefc73af6e

John W. Eaton <jwe>
Project AdministratorIn charge of this item.
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>
Project 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:

http://hg.savannah.gnu.org/hgweb/octave/rev/f35bd5cddedd

Then I noticed a crash on string indexing:

http://hg.savannah.gnu.org/hgweb/octave/rev/92a64cb5e475

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

http://hg.savannah.gnu.org/hgweb/octave/rev/01eb7f87eecd

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

http://hg.savannah.gnu.org/hgweb/octave/rev/18f5f91f7348

John W. Eaton <jwe>
Project AdministratorIn charge of this item.
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>
Project Administrator

 

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

Attach Files:
   
   
Comment:
   

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)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project 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.4