bugGNU Octave - Bugs: bug #42704, mkoctfile returns 0 if compile...

 
 

bug #42704: mkoctfile returns 0 if compile failed but linking succeeded

Submitter:  Andreas Weber <andy1978>
Submitted:  Tue 08 Jul 2014 10:55:47 AM UTC
   
 
Category:  Libraries Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 3.8.1 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 14 Jul 2014 04:21:08 AM UTC, comment #7: 

This was a two-part fix.  First, I stopped continuing on with the compilation and linking if one of the previous steps had failed.  See changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/3e4e2cfba186).  I then grafted jwe's fix for WEXITSTATUS from default back to stable.

Rik <rik5>
Group administrator
Wed 09 Jul 2014 03:25:05 AM UTC, comment #6: 

The fix will lie in mkoctfile.in.cc.  It seems pretty easy.  Either we can check the return code immediately after each call to run_command(), or we can add !result to all of the for loops so that they will immediately short-circuit and fall to the end of the function.

Rik <rik5>
Group administrator
Tue 08 Jul 2014 07:02:46 PM UTC, comment #5: 

Confirmed on default now. If hello.cc and hello.o both exist, and hello.cc fails to compile, hello.o is still linked to make hello.oct and mkoctfile returns 0.

Mike Miller <mtmiller>
Group Member
Tue 08 Jul 2014 04:38:16 PM UTC, comment #4: 

Oh I read this too quickly, this is a subtle difference from the earlier bug #42549. My mistake for forgetting that was already reported and taken care of.

Andy reports here that mkoctfile returns success if the compilation stage fails but it is able to link a previously-existing object file into an oct-file. I can confirm that with 3.8.1, no default to test with at the moment.

The previous shell script version of mkoctfile used to stop at the compilation error and exit with failure, leaving the old object file and oct-file around. So still a regression from 3.8.0.

Mike Miller <mtmiller>
Group Member
Tue 08 Jul 2014 04:02:09 PM UTC, comment #3: 

Hasn't it already been fixed on default?

http://hg.savannah.gnu.org/hgweb/octave/rev/5b7b18d603ae

I think this change should have been applied to stable instead.  I'd say transplant it now for 3.8.2.

John W. Eaton <jwe>
Group administrator
Tue 08 Jul 2014 03:15:36 PM UTC, comment #2: 

Yep, thanks for reporting. This is actually a regression on Linux/Unix/Mac systems between 3.8.0 and 3.8.1, where we moved from mkoctfile as a shell script to a compiled program. It would probably be best to fix on stable for 3.8.2. Did you have a patch when you brought this up on the mailing list before?

Mike Miller <mtmiller>
Group Member
Tue 08 Jul 2014 11:21:22 AM UTC, comment #1: 

hm, there seems to be a problem with savannah and I'll try to add the code again:

hello.cc:

#include <iostream>
int main()
{
  std::cout << "hello bug hunter..." << std::endl;
  return 0;
}


now compile with mkoctfile:

$ mkoctfile -v hello.cc

cmd = ccache g++ -c  -fPIC -I/usr/local/include/octave-4.1.0+/octave/..
-I/usr/local/include/octave-4.1.0+/octave -I/usr/local/include  -g -O2
-pthread    hello.cc -o hello.o
result = 0
cmd = ccache g++ -shared -Wl,-Bsymbolic  -o hello.oct  hello.o
-L/usr/local/lib/octave/4.1.0+ -L/usr/local/lib -loctinterp -loctave
result = 0


All went fine as expected. Now add a syntax error to hello.cc and run mkoctfile again:


$ mkoctfile -v hello.cc
cmd = ccache g++ -c  -fPIC -I/usr/local/include/octave-4.1.0+/octave/..
-I/usr/local/include/octave-4.1.0+/octave -I/usr/local/include  -g -O2
-pthread    hello.cc -o hello.o
hello.cc: In function ‘int main()’:
hello.cc:5:3: error: ‘xyz’ was not declared in this scope
   xyz
   ^
result = 256
cmd = ccache g++ -shared -Wl,-Bsymbolic  -o hello.oct  hello.o
-L/usr/local/lib/octave/4.1.0+ -L/usr/local/lib -loctinterp -loctave
result = 0

$ echo $?
0


As you can see g++ failed and returned 256 but mkoctfile nevertheless tries to link hello.o which succeeds and returns 0 therefore.

-- Andy

Andreas Weber <andy1978>
Group Member
Tue 08 Jul 2014 10:55:47 AM UTC, original submission:  

hg id 49961d67e4b9

mkoctfile returns 0 if compilation of file.cc fails but link succeeds because of already existent (from previous compilation) file.o.

I don't know exactly what the desired behavior for this is but I think mkoctfile should return the exit status immediatly and stop further execution if a command fails.

I've added debugging outputs "cmd =" and "result ="
in mkoctfile.in.cc:364 run_command (const std::string& cmd)

create a simple file hello.cc:

#include <iostream>
int main()
{
  std::cout << "hello bug hunter..." << std::endl;
  return 0;
}
-verbatim

now compile with mkoctfile:
$ mkoctfile -v hello.cc
+verbatim+
cmd = ccache g++ -c  -fPIC -I/usr/local/include/octave-4.1.0+/octave/.. -I/usr/local/include/octave-4.1.0+/octave -I/usr/local/include  -g -O2 -pthread    hello.cc -o hello.o
result = 0
cmd = ccache g++ -shared -Wl,-Bsymbolic  -o hello.oct  hello.o   -L/usr/local/lib/octave/4.1.0+ -L/usr/local/lib -loctinterp -loctave
result = 0


All went fine as expected. Now add a syntax error to hello.cc and run mkoctfile again:

$ mkoctfile -v hello.cc
cmd = ccache g++ -c  -fPIC -I/usr/local/include/octave-4.1.0+/octave/.. -I/usr/local/include/octave-4.1.0+/octave -I/usr/local/include  -g -O2 -pthread    hello.cc -o hello.o
hello.cc: In function ‘int main()’:
hello.cc:5:3: error: ‘xyz’ was not declared in this scope
   xyz
   ^
result = 256
cmd = ccache g++ -shared -Wl,-Bsymbolic  -o hello.oct  hello.o   -L/usr/local/lib/octave/4.1.0+ -L/usr/local/lib -loctinterp -loctave
result = 0

$ echo $?
0


As you can see g++ failed and returned 256 but mkoctfile nevertheless tries to link hello.o which succeeds and returns 0 therefore.

-- Andy

Andreas Weber <andy1978>
Group Member

 

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

    Date Changed by Updated Field Previous Value => Replaced by
    2014-07-14 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2014-07-08 mtmiller Item GroupIncorrect Result Regression
        StatusNone Confirmed
        Releasedev 3.8.1

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code