bugGNU Octave - Bugs: bug #58524, [MXE] libsndfile build error

 
 

bug #58524: [MXE] libsndfile build error

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Sun 07 Jun 2020 08:20:12 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Build Failure
Status:  Fixed Assigned to:  None
Originator Name:  philipnienhuis Open/Closed:  * Closed
Release:  * dev Release: 
Operating System:  * Other Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 14 Jun 2020 06:18:34 PM UTC, comment #12: 

This should no longer be occurring with current MXE Octave.
John D removed commenting out that line in io.h here:
https://hg.octave.org/mxe-octave/rev/8999910050be

And Alois Schlögl accepted an alternative patch upstream in libbiosig:
https://sourceforge.net/p/biosig/code/ci/e13052c771dd45f2d5045c2f01c6b5fc1784ca0b/

Until that change is released (and libbiosig is updated in Octave), we use a similar patch for libbiosig in MXE Octave:
https://hg.octave.org/mxe-octave/rev/53c3c929c037

Closing as fixed.

Markus Mützel <mmuetzel>
Group administrator
Sun 14 Jun 2020 04:03:31 AM UTC, comment #11: 

I have seen this problem also this problem in the compilation of cairo.
The error lines are:


_mingw_bos_extern_ovr
//int sopen(const char * __filename, int __flags, int __share, ...)
{
  return _sopen(__filename, __flags, __share, __builtin_va_arg_pack());
}


lines around 476 in mxe-octave/usr/x86_64-w64-mingw32/include/io.h

manually deleting the // in the int sopen line fixed the problem.

But maybe all the lines should be commented out.

Avinoam Kalma <avinoam>
Group Member
Thu 11 Jun 2020 07:23:54 AM UTC, comment #10: 

Thx for the detective work :-)
Do I understand well that (standard out-of-the-box) libbiosig modifies a standard system-wide header file?

Philip Nienhuis <philipnienhuis>
Group Member
Thu 11 Jun 2020 12:30:07 AM UTC, comment #9: 

Found the actual issue, the makefile for libbiosig modifies io.h, which then breaks it when its used with secure calls like sopen.

On a clean build, biosig gets built after most other packages so doesn't cause the error, but on a rebuild of certain packages afterward, there is the potential to use the now broken function calls.

Ill see if can fix that

John Donoghue <lostbard>
Group Member
Tue 09 Jun 2020 10:14:37 AM UTC, comment #8: 

OK, a complete rebuild of mxe-octave went well. __run_test_suite__ tests run fine on Windows.

I saw that cmake (for native builds on Windows) was built as one of the last packages.

What shall we do with this report:

  • Close with "invalid"

-or-

  • Leave open, but retitle to s/th along the lines of "mxe-octave package dependencies need update'?
Philip Nienhuis <philipnienhuis>
Group Member
Mon 08 Jun 2020 08:13:00 PM UTC, comment #7: 

All the build-* packages get built before anything else.


John Donoghue <lostbard>
Group Member
Mon 08 Jun 2020 07:47:51 PM UTC, comment #6: 

@JohnD:
Like you say, if standard headers are involved there's a serious issue in dependencies.
What might help is observing the order in which packages get built for a brand new mxe-octave check-out. What I see is that build-cmake and the CMake toolchain appear quite early in the process.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 08 Jun 2020 07:41:56 PM UTC, comment #5: 

[OT] @Markus:
Thx, I thought of that, but the combined workload comprising a VM for building, plus a VM (VMware) for working remotely (mainly MS-Office stuff), plus local CPU/RAM-intensive programs needed to get Real Work done (GIS, databases, modeling SW, indeed: Octave) is too much for my HW (both meager core-i5 + 8 GB RAM machines).

Philip Nienhuis <philipnienhuis>
Group Member
Mon 08 Jun 2020 07:16:28 PM UTC, comment #4: 

@Philip: Off-topic - You could use a VM to build Octave in the background while still being able to use the computer for Windows-y work stuff. I'm using an Ubuntu from osboxes.org on a VMWare Player since a few years now. And it served me well so far...

Markus Mützel <mmuetzel>
Group administrator
Mon 08 Jun 2020 07:06:29 PM UTC, comment #3: 

Yeah is its complaining with issues in standard headers, I would say a definate rebuild.

I guess will see on the next cmake update whether it breaks again or not :)

I have been meaning on going through the  the packages and verify the dependancies are still valid/complete which may help.

John Donoghue <lostbard>
Group Member
Mon 08 Jun 2020 06:16:03 PM UTC, comment #2: 

--enable-octave=default --enable-64 --enable-fortran-int64  --enable-devel-tools --enable-binary-packages --with-ccache --disable-system-opengl

I uncommented L. 476 in io.h, only to find out that after restarting the build it broke a few lines later in io.h.

My conclusion is that I have to rebuild the entire mxe-octave tree, right?
For me that is a bit of a bummer, on my laptop that's about 20 hours, on my desktop about 8 hours and both are needed for work from home these days.

Ah well, that's the price for living on the edge ... :-)

Let's leave this report open until I have a complete fresh mxe-octave build (which might be interrupted if not ready by tomorrow morning)

Philip Nienhuis <philipnienhuis>
Group Member
Mon 08 Jun 2020 05:19:07 PM UTC, comment #1: 

what mxe config settings are you using for building?

The problem with many of these is probably more like that the dependancies for each 'package' isnt always 100% and something that should have been rebuilt on an update may not have been.

Previously the update of mingw to v7 was probally the culprit as at that point probally everything else needs to be rebuilt as build-gcc would have been rebuilt, but none of the packages depend on the build tools.

 


John Donoghue <lostbard>
Group Member
Sun 07 Jun 2020 08:20:12 PM UTC, original submission:  

After updating the mxe-octave build tree, libsndfile won't get cross-built:

make[4]: Entering directory '/home/philip/devel/octdev/mxe/mxe_64w_20200603L/tmp-libsndfile/libsndfile-
1.0.28/src'
  CC       libsndfile_la-sndfile.lo
  CC       libsndfile_la-aiff.lo
  CC       libsndfile_la-au.lo
  CC       libsndfile_la-avr.lo
In file included from /home/philip/devel/octdev/mxe/mxe_64w_20200603L/usr/x86_64-w64-mingw32/include/fcntl.h:8,
                 from au.c:22:
/home/philip/devel/octdev/mxe/mxe_64w_20200603L/usr/x86_64-w64-mingw32/include/io.h:477:1: error: expected identifier or '(' before '{' token
  477 | {
      | ^


I noted that during the mxe-octave update also cmake got updated. Is this related? (see bug #58466 where AFAICU cmake was also involved)

Philip Nienhuis <philipnienhuis>
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 avinoam (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by philipnienhuis (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-06-14 mmuetzel StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2020-06-14 avinoam StatusNone Confirmed

    Back to the top

    Powered by Savane 3.15-e6e5.
    Corresponding source code