bugGNU Octave - Bugs: bug #48671, Windows mkoctfile does not...

 
 

bug #48671: Windows mkoctfile does not substitute Octave installation path correctly

Submitter:  None
Submitted:  Mon 01 Aug 2016 08:49:16 AM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Ready For Test Assigned to:  None
Originator Name:  michaelquellmalz Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 4.0.3
Operating System:  * Microsoft Windows Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 05 Jan 2017 06:28:17 PM UTC, comment #9: 

I applied this change to stable and merged with default.


John W. Eaton <jwe>
Group administrator
Thu 05 Jan 2017 02:57:54 PM UTC, comment #8: 

Found the issue in w32_get_octave_home in shared-fcns.h:

For Windows, if the OCTAVE_HOME env string is not set, It is getting a list of running modules and looking to see which one has octave in its name and using its module path.

For mkoctfile of course, the name isn't 'octave'.

How about using the running modules full path/name using GetModuleFileName [1] and extracting the path ?


Patch attached.

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms683197(v=vs.85).aspx


(file #39369)

John Donoghue <lostbard>
Group Member
Tue 02 Aug 2016 03:44:16 PM UTC, comment #7: 

@mtmiller: I use the shell of MSYS2 (which is based on mintty) and started it from the link created by the msys2 installation.
Setting the environment variable OCTAVE_HOME changes the result of mkoctfile, but after unsetting it returns the wrong path again.

$ export OCTAVE_HOME="D:\Octave-4.0.3"
$ /d/Octave-4.0.3/bin/mkoctfile -p OCTAVE_HOME
D:\Octave-4.0.3
$ /d/Octave-4.0.3/bin/mkoctfile -p OCTLIBDIR
D:\Octave-4.0.3\lib\octave\4.0.3

$ export OCTAVE_HOME=
$ /d/Octave-4.0.3/bin/mkoctfile -p OCTAVE_HOME
/scratch/jwe/mxe-octave/usr/i686-w64-mingw32


Anonymous
Tue 02 Aug 2016 03:42:28 PM UTC, comment #6: 

@jwe: yes - OCTAVE_HOME gets sets via the cmdshell.bat when using the installer bashshell shortcut.

modifying the script to not set OCTAVE_HOME,  I can then see similar displays as the original comment.




John Donoghue <lostbard>
Group Member
Tue 02 Aug 2016 03:02:30 PM UTC, comment #5: 

anonymous: it looks like you are running mkoctfile and octave-config from a bash shell, what kind of shell is this and how did you start it? Set and unset OCTAVE_HOME like any other environment variable. Is it already in your environment? Does setting it or unsetting it change anything?

Mike Miller <mtmiller>
Group Member
Tue 02 Aug 2016 02:05:47 PM UTC, comment #4: 

John:  Is OCTAVE_HOME set in the bash environment?

If not, then the programs appear to be working correctly on your system.  On Windows systems, they are supposed to determine the value of OCTAVE_HOME from the location where they are installed.

John W. Eaton <jwe>
Group administrator
Tue 02 Aug 2016 01:55:53 PM UTC, comment #3: 

On my win10 box with official 4.0.3 installer installed, using the bash shell:


bash-3.1$ mkoctfile -p OCTAVE_HOME
C:\Octave\Octave-4.0.3\
bash-3.1$ mkoctfile -p OCTLIBDIR
C:\Octave\Octave-4.0.3\\lib\octave\4.0.3
bash-3.1$ octave-config -p OCTAVE_HOME
C:\Octave\Octave-4.0.3\
bash-3.1$



John Donoghue <lostbard>
Group Member
Tue 02 Aug 2016 08:33:07 AM UTC, comment #2: 

Thank you for your response. After deleting liboctave.la and liboctinterp.la the external project NFFT compiles.

Where should I set OCTAVE_HOME? Calling it in Octave itself, it returns the right directory

>> OCTAVE_HOME
ans = D:\octave-4.0.3

And also OCTAVE_HOME is different for octave-config and mkoctfile

$ /d/Octave-4.0.3/bin/octave-config -p OCTAVE_HOME
D:\Octave-4.0.3

$ /d/Octave-4.0.3/bin/mkoctfile -p OCTAVE_HOME
/scratch/jwe/mxe-octave/usr/i686-w64-mingw32


Anonymous
Mon 01 Aug 2016 05:37:18 PM UTC, comment #1: 

Thank you for your bug report. The existence of strings referring to these invalid paths is not in itself a bug. Octave is cross-compiled, and as far as I can tell it will continue to have these references embedded in it as long as it is built this way. However, as long as the OCTAVE_HOME environment variable is set correctly, most things should work.

Does deleting the .la files allow the build of your external project to work? Maybe they should be deleted from the installer.

The difference between octave-config and mkoctfile is curious, they should both be substituting the path to where Octave is installed, if I'm reading the code correctly. Does setting OCTAVE_HOME fix mkoctfile? Is OCTAVE_HOME set when you call one but not the other?

Mike Miller <mtmiller>
Group Member
Mon 01 Aug 2016 08:49:16 AM UTC, original submission:  

The official Windows builds for Octave 4.0.2 and 4.0.3 contain some references to invalid paths that only exist in Linux. For example the call of mkoctfile

$ /d/Octave-4.0.3/bin/mkoctfile -p OCTLIBDIR
\scratch\jwe\mxe-octave\usr\i686-w64-mingw32\lib\octave\4.0.3

returns an invalid path.

However, octave-config gives the correct path

$ /d/Octave-4.0.3/bin/octave-config -p OCTLIBDIR
D:\Octave-4.0.3\lib\octave\4.0.3


Furthermore, the .la files in lib/octave/4.0.3 contain invalid references. For example liboctave.la contains the lines

# Libraries that this one depends upon.
dependency_libs=''
# -R/usr/lib -L/usr/lib /usr/lib/libcurl.la /usr/lib/libidn.la /usr/lib/libssh2.la /usr/lib/libgcrypt.la /usr/lib/libgpg-error.la /usr/lib/libgnutls.la -lnettle -lhogweed /usr/lib/libgmp.la -lcrypt32 /usr/lib/libintl.la /usr/lib/libiconv.la /usr/lib/libpcreposix.la -lwldap32 -lz -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd -lcxsparse -larpack /usr/lib/libqrupdate.la /usr/lib/libfftw3.la /usr/lib/libfftw3f.la -llapack -lblas -lreadline -ltermcap /usr/lib/libpcre.la /usr/lib/gcc/i686-w64-mingw32/4.9.3/libgfortran.la -L/usr/mingw/lib /usr/lib/gcc/i686-w64-mingw32/4.9.3/libquadmath.la -lgdi32 -lws2_32 /usr/lib/gcc/i686-w64-mingw32/4.9.3/libstdc++.la'

which makes the compilation of some third-party tools crash like we found out for NFFT.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #39369:  bug48671.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 siko1056 (Updated the item)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by None (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 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-03 mtmiller Carbon-CopyRemoved 80942 -
    2017-02-24 siko1056 Open/ClosedOpen Closed
    2017-01-18 jwe StatusPatch Submitted Ready For Test
    2017-01-05 lostbard StatusConfirmed Patch Submitted
    2017-01-05 lostbard Attached File- Added bug48671.patch, #39369
    2016-08-02 mtmiller StatusNeed Info Confirmed
        SummaryWindows builds contain references to invalid paths Windows mkoctfile does not substitute Octave installation path correctly
    2016-08-01 mtmiller CategoryNone Configuration and Build System
        Item GroupNone Incorrect Result
        StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code