bugGNU Octave - Bugs: bug #54308, xerbla.c/xerbla.cc compilation...

 
 

bug #54308: xerbla.c/xerbla.cc compilation error

Submitter:  Dan Sebald <sebald>
Submitted:  Fri 13 Jul 2018 05:33:02 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  Invalid / Not an Octave Bug Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 13 Jul 2018 08:28:25 PM UTC, comment #9: 


> In that instance, the Plo files could be cleared before the configure is run.


I am sure you would find that that would only make things much worse in general.

If you want to keep discussing the Octave build system and GNU Autotools in general, that's fine, and I'm happy to help discuss ideas for improvements or answer questions or test changes.

I would also be happy to work on a blog post or FAQ about some of the workflow optimizations I have come up with over years of working with GNU Autotools in various projects.

But this bug report is not the place, this specific issue is resolved, I'm leaving it at that.

Mike Miller <mtmiller>
Group Member
Fri 13 Jul 2018 07:55:52 PM UTC, comment #8: 

make is also set up to check whether configure needs to be run on account of a bootstrap having been run.  In that instance, the Plo files could be cleared before the configure is run.

Dan Sebald <sebald>
Fri 13 Jul 2018 07:38:46 PM UTC, comment #7: 

Yes, sorry, "make" is what I meant.  Some entity that knows how to traverse the headers of C/C++ files has to generate the dependency files, so I suppose that would logically be the compiler.

Yeah, wipe clean always works.  It's just not something that immediately comes to mind.  But now that I know where the Plo files are, that will avoid the rebuild.

Dan Sebald <sebald>
Fri 13 Jul 2018 07:30:59 PM UTC, comment #6: 

The dependency files are generated by the compiler, but they are used by make.  They record the dependencies so that make ca knows what rules to execute when something changes.

I don't think you want configure to remove them if they exist.

Invalid dependency files are a rare occurrence.  Fixing this "problem" doesn't seem that important.  If there is a problem, wipe out your build tree and start fresh, beginning with bootstrap and use ccache to help speed things up.

John W. Eaton <jwe>
Group administrator
Fri 13 Jul 2018 07:29:46 PM UTC, comment #5: 

No, they have nothing to do with the compilation stage itself. They are an output of the compiler, not an input. They are an input to the make program.

The dependency files are there so that when you make an edit to, let's say symtab.h, all object files that come from a source file that include symtab.h will be recompiled automatically.

With this feature disabled, if you edit symtab.h and type 'make all', it's possible that nothing will get recompiled.

Mike Miller <mtmiller>
Group Member
Fri 13 Jul 2018 07:15:16 PM UTC, comment #4: 

Are the dependency files solely for the purpose of speeding up compilation (i.e., the compiler doesn't have to look through all the files and resolve dependencies with each new build)?  If the "./configure" were to automatically discard all the .dep/xyz.Plo files, would it only mean that the first build after a configure takes slightly longer?

BTW, it seems lately that debug-building has sped up a bit.  (By "debug-building" I mean make a little change and recompile...i.e., that first bit in the make process doesn't take so long anymore.)

Dan Sebald <sebald>
Fri 13 Jul 2018 06:54:30 PM UTC, comment #3: 

Not an error.

I encountered the same exact symptom on 'hg pull && hg up @ && make all'. This will happen any time a source file extension is changed and you are building in a partially or previously built directory.

For a complete understanding, you have to know a bit about the autotools build system.

As a side effect of compiling xerbla.c, GCC creates a dependency file, which is just a text file listing all of the include files that xerbla.c included during its compilation stage. This file is included in the makefile, so the build system knows if a particular .h file is updated, this one particular object file needs to be recompiled.

The dependency file is called 'liboctave/external/blas-xtra/.deps/liboctave_external_blas_xtra_libxerbla_la-xerbla.Plo'. Notice that the file name would be the same if it were a .c file, a .cc file, or a .cpp file.

So when you have an already-built tree, this dependency file has text basically saying that xerbla.o comes from xerbla.c.

The minimal amount of work you need to do to resolve this is to blank the contents of the dependency file snippet. I did this with


echo '#' > liboctave/external/blas-xtra/.deps/liboctave_external_blas_xtra_libxerbla_la-xerbla.Plo


and 'make all' ran fine after that.

If this kind of auto-magic logic bothers you, you can disable automatic dependency generation with './configure --disable-dependency-tracking'.

But that also means you can't simply touch a header file and expect that everything will be built that needs to be built, you'll probably have to do 'make clean && make all' more often.

Mike Miller <mtmiller>
Group Member
Fri 13 Jul 2018 06:30:25 PM UTC, comment #2: 

OK, that worked.  I searched for any xerbla.c; guess that wasn't enough.

Dan Sebald <sebald>
Fri 13 Jul 2018 06:00:39 PM UTC, comment #1: 

I had to do 'make maintainer-clean' followed by bootstrap, configure, make sequence.

Rik <rik5>
Group administrator
Fri 13 Jul 2018 05:33:02 PM UTC, original submission:  

After an "hg pull" followed by make, I'm seeing the following compilation error:


  GEN      libinterp/liboctinterp-build-info.cc
make[2]: *** No rule to make target '/home/sebald/octave/octave/octave/liboctave/external/blas-xtra/xerbla.c', needed by 'liboctave/external/blas-xtra/liboctave_external_blas_xtra_libxerbla_la-xerbla.lo'.  Stop.
make[2]: *** Waiting for unfinished jobs....


The "xerbla.c" doesn't exist on my system.  Instead, it is "xerbla.cc".

I'm re-running "configure"... still the error.

I'm re-running "bootstrap" followed by (automatic) "configure"... still the error.

Dan Sebald <sebald>

 

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

    Date Changed by Updated Field Previous Value => Replaced by
    2018-07-13 mtmiller StatusNone Invalid / Not an Octave Bug
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code