octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Building pytave on windows


From: Mike Miller
Subject: Re: Building pytave on windows
Date: Tue, 9 May 2017 22:40:58 -0700
User-agent: NeoMutt/20170113 (1.7.2)

On Wed, May 10, 2017 at 10:34:11 +0530, Abhinav Tripathi wrote:
> Undefining hypot didn't fix the problem. But, as suggested on the python's
> issue page, including cmath before Python.h did the trick.
> *The build completed successfully*!!

That's a good start.

> BUT, when I open octave and cd to pyatve's directory, it says that pycall,
> pyexec, pyeval all these are undefined!!
> Moreover, if instead of cding, if I just do addpath for pytave then I got a
> lot of warnings due to PKG_ADD.
> I do not have proper experience with oct files, but I tried the following,
> out of which nothing worked:
> .
> -- I saw that the files are named *.oct.exe while in PKG_ADD the names are
> only *.oct
>      So, I renamed the files to remove .exe from file names. Now, I added
> pytave to path in octave and there was no warning but still all the
> functions are undefined.
> -- I edited PKG_ADD to include .exe in the end of .oct but now I get syntax
> error in the .oct.exe file which can be seen here:
> ***********************************************************************
> >> addpath 'D:/repos/pytave'
> >> py.int
> parse error near line 1 of file D:/repos/pytave\pycall.oct.exe
> 
>   syntax error
> 
> >>> MZ�
>       ^
> 
> error: called from
>     subsref at line 49 column 9
> ***********************************************************************
> 
> I am guessing second approach is right but the problem is related to how
> oct files are created on windows. Again, I have no knowledge of how oct
> files are created/called so any insight is welcome...

No, I think the "MZ" error is because of the file name. I think that
when Octave looks for a file on its load path to match a function or
script name, if the name ends in exactly ".oct", then it is loaded as a
shared object, otherwise it is expected to be an m-file. Octave is
trying to run the compiled oct files as if they were m-files, and all
Windows executable files start with the bytes "MZ".

I am pretty sure that I set up the makefile to build the oct files
correctly but you might try comparing the mkoctfile command line against
installing a well tested package from Octave Forge, or against building
the hello oct file example from the user manual.

I'm not sure why .exe is appended to the output files, that might be a
side effect of wrapping mkoctfile in libtool. It's possible that libtool
is doing other unexpected things to the command line also.

Can you get a basic oct file to work, in a different directory, or in
the same directory? Is the D: volume removable or network storage? If
you exit Octave and start it again with the oct files already built, any
difference?

-- 
mike



reply via email to

[Prev in Thread] Current Thread [Next in Thread]