bugGNU Octave - Bugs: bug #51450, [octave forge] (database) 2.4.2...

 
 

bug #51450: [octave forge] (database) 2.4.2 fails to build in dev octave 4.3.0+

Submitted by:  John Donoghue <lostbard>
Submitted on:  Wed 12 Jul 2017 12:19:05 PM UTC  
 
Category:  Octave Forge Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Build Failure
Status:  Fixed Assigned to:  None
Originator Name:  JohnD 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)

Thu 20 Jul 2017 12:12:09 PM UTC, comment #12: 

yep - package now builds under windows octave 4.2.1 and 4.3.0+

John Donoghue <lostbard>
Project Member
Thu 20 Jul 2017 09:41:58 AM UTC, comment #11: 

Currently no effort is made to make building the extra docs work under Windows or while cross-building. The extra docs should be pre-built natively. This is also noted in a comment at the top of src/Makefile.in.

I checked in a patch which fixes pre-building the extra docs with the release: target of the toplevel Makefile. Is that enough for your needs?

Olaf Till <i7tiol>
Project Member
Wed 19 Jul 2017 05:48:02 PM UTC, comment #10: 

Which reminds me that in mxe-octave, in order to get it to cross compile, I assigned in the Makefile:

BUILD_CXX ?= gcc

and for the CXX in the doc rule to BUILD_CXX

John Donoghue <lostbard>
Project Member
Wed 19 Jul 2017 05:43:39 PM UTC, comment #9: 

I guess should be a new bug report, but attempting to compile under windows (using latest from the repo)

if grep -q DEFUN_DLD_REPLACEMENT_FOR_PACKAGE_DOCS pq_update_types.cc; then echo "The string 'DEFUN_DLD_REPLACEMENT_FOR_PACKAGE_DOCS' must not be present in source code, but is in pq_update_types.cc."; exit 1; fi
if grep -q DEFUNX_DLD_REPLACEMENT_FOR_PACKAGE_DOCS pq_update_types.cc; then echo "The string 'DEFUNX_DLD_REPLACEMENT_FOR_PACKAGE_DOCS' must not be present in source code, but is in pq_update_types.cc."; exit 1; fi
(echo "#include <stdio.h>"; echo "int main () {"; sed -e s/DEFUN_DLD/DEFUN_DLD_REPLACEMENT_FOR_PACKAGE_DOCS/g -e s/DEFUNX_DLD/DEFUNX_DLD_REPLACEMENT_FOR_PACKAGE_DOCS/g pq_update_types.cc | g++ -std=gnu++11 -E `mkoctfile -p INCFLAGS` -I`pg_config --includedir` -x c++ -iquote '.' -D'DEFUN_DLD_REPLACEMENT_FOR_PACKAGE_DOCS(name,args,nargout,doc)=DEFUN_DLD_REPLACEMENT_FOR_PACKAGE_DOCS(name,doc)' -D'DEFUNX_DLD_REPLACEMENT_FOR_PACKAGE_DOCS(name,fname,gname,args,nargout,doc)=DEFUN_DLD_REPLACEMENT_FOR_PACKAGE_DOCS(name,doc)' - | sed -e '/.*DEFUN_DLD_REPLACEMENT_FOR_PACKAGE_DOCS/!D'; echo "}";) | g++ -x c++ -D'DEFUN_DLD_REPLACEMENT_FOR_PACKAGE_DOCS(name,doc)=printf("%c" #name "\n@c " #name " pq_update_types.cc\n" doc "\n\n", 0x1D);' -o pq_update_types.bin -
(echo "### This file is generated automatically from the"; echo "### corresponding .cc file by a Makefile rule."; echo ""; ./pq_update_types.bin) > pq_update_types.cc.docstrings
/bin/sh: ./pq_update_types.bin: Bad file number
make: *** [pq_update_types.cc.docstrings] Error 126

Trying to run the pq_update_types.bin file afterwards gives same
'Bad file number' error

John Donoghue <lostbard>
Project Member
Tue 18 Jul 2017 07:06:36 PM UTC, comment #8: 

A fix is pushed, including a general frame to deal with simple symbol changes. I suggest to use this frame for similar cases, it'll be published at the OF website.

Deprecated symbols don't seem to be available long enough for my previous strategy to work.

As for filing bugs for build failures with dev, I can't suggest a general rule. In the packages which I maintain I think I would fix these even without reports, but in some cases not before dev is about to become the next major release. But your build fixes against dev for many packages are doubtless really useful.

On the other hand, maybe a development strategy for the Windows build could be devised in which you have more time to wait for (or produce...) build fixes of packages against dev ...? It's only because package development normally doesn't immediately parallel each change in Octave dev, except on Windows.

Olaf Till <i7tiol>
Project Member
Wed 12 Jul 2017 02:39:25 PM UTC, comment #7: 

I guess the question is really, should we post build failures of packages against dev as bugs?

In the mean time, I have a fix for building/testing

John Donoghue <lostbard>
Project Member
Wed 12 Jul 2017 02:37:00 PM UTC, comment #6: 

But it was with Octaves development version, which AFAIK is not near a release. So I'm not sure that I should take this failure as the trigger to switch from deprecated to modern.

Olaf Till <i7tiol>
Project Member
Wed 12 Jul 2017 02:29:37 PM UTC, comment #5: 

In this case, it was more than just a depreciated symbol - it wont compile. It does print out a number of other messages about depreciated functions as well - I was ignoring them

John Donoghue <lostbard>
Project Member
Wed 12 Jul 2017 12:54:29 PM UTC, comment #4: 

I didn't see your patch, it crossed with my last post. However, my current strategy with deprecated symbols in Octave is to use the deprecated ones as long as they are supported and then to unconditionally switch to the replacements. This spares testing for each single deprecated symbol and should (?) still provide compatibility with a certain range of Octave versions.

Olaf Till <i7tiol>
Project Member
Wed 12 Jul 2017 12:44:17 PM UTC, comment #3: 

Probally not - just for testing mxe-octave with dev octave.

John Donoghue <lostbard>
Project Member
Wed 12 Jul 2017 12:28:40 PM UTC, comment #2: 

I tend to adapt to Octaves API changes in the development branch only in greater chunks, preferably after some re-structuring of Octave is finished. Do you need this fixed already now for some reason?

Olaf Till <i7tiol>
Project Member
Wed 12 Jul 2017 12:25:30 PM UTC, comment #1: 

Patch checking for mach_info

(file #41190)

John Donoghue <lostbard>
Project Member
Wed 12 Jul 2017 12:19:05 PM UTC, original submission:  

With recent changes in name spaces in octave:

bytea2var.cc: In function 'octave_value_list Fbytea2var(const octave_value_list&, int)':
bytea2var.cc:97:22: error: 'flt_fmt_unknown' is not a member of 'oct_mach_info'
       if (flt_fmt == oct_mach_info::flt_fmt_unknown)
                      ^
Makefile:95: recipe for target 'bytea2var.o' failed

John Donoghue <lostbard>
Project Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #41190:  namespace.patch added by lostbard (2KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Updated the item)
  • -email is unavailable- added by mtmiller (Updated the item)
  • -email is unavailable- added by i7tiol (Posted a comment)
  • -email is unavailable- added by lostbard (Adding package maintainer)
  • -email is unavailable- added by lostbard (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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-07-02 jwe Summary[octave-forge] database 2.4.2 fails to build in dev octave 4.3.0+ => [octave forge] (database) 2.4.2 fails to build in dev octave 4.3.0+
    2017-07-20 mtmiller StatusNone => Fixed
        Open/ClosedOpen => Closed
    2017-07-12 lostbard Attached File- => Added namespace.patch, #41190
    2017-07-12 lostbard Carbon-Copy- => Added i7tiol@t-online.de

    Back to the top


    Powered by Savane 3.5