User talk:Genuinelucifer: Difference between revisions

Line 89: Line 89:
=== Using Msys2 ===
=== Using Msys2 ===


Tatsuro told to use [https://msys2.github.io/ msys2] for the job. He also suggested to use octave-4.0.2 as octave-4.0.0 was buggy on windows.   
Tatsuro told to use [https://msys2.github.io/ msys2], which aims to provide support to facilitate using the bash shell, autotools, revision control systems and the like for building native Windows applications using MinGW-w64 toolchains, for the job. He also suggested to use octave-4.0.2 as octave-4.0.0 was buggy on windows.   
Later on he provided development version of octave that he built using octave itself (along with msys2). I started using that development version (4.1.0+) of octave. He also suggested the following steps after installing msys2 for the setup:   
Later on he provided development version of octave that he built using octave itself (along with msys2). I started using that development version (4.1.0+) of octave. He also suggested the following steps after installing msys2 for the setup:   
# [https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/ Install Msys2 and update core and basics packages]
# [https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/ Install Msys2 and update core and basics packages]
Line 107: Line 107:
After installing boost too, the build was failing with errors related to boost libraries. I saw that the *.a and *.dll files  had '-mt' appended to their name and didn't work because of that... Once I renamed them to remove the '-mt' then the configure could find the libs and finally the ''configure'' steps was successful with just one warning that 'uselocale' was not supported!
After installing boost too, the build was failing with errors related to boost libraries. I saw that the *.a and *.dll files  had '-mt' appended to their name and didn't work because of that... Once I renamed them to remove the '-mt' then the configure could find the libs and finally the ''configure'' steps was successful with just one warning that 'uselocale' was not supported!


Now when I ran ''make'' then ''libtool'' weirdly escaped all the '\' characters in the paths for libraries found during the configure step. Ex "-IE:\octave_dev\include\octave-4.1.0+ -IE:\octave_dev\include\octave-4.1.0+/octave" was passed as "-IE:octave_devincludeoctave-4.1.0+ -IE:octave_devincludeoctave-4.1.0+/octave". I have no knowledge of how exactly the configure and m4 scripts co-ordinate the tasks and hence it was dificult for me to find the cause for this. I tried to see how to change the default path separator but it didn't work.
Now when I ran ''make'' then ''libtool'' weirdly escaped all the '\' characters in the paths for libraries found during the configure step. Ex "-IE:\octave_dev\include\octave-4.1.0+ -IE:\octave_dev\include\octave-4.1.0+/octave" was passed as "-IE:octave_devincludeoctave-4.1.0+ -IE:octave_devincludeoctave-4.1.0+/octave". I have no knowledge of how exactly the configure and m4 scripts co-ordinate the tasks and hence it was difficult for me to find the cause for this. I tried to see how to change the default path separator but it didn't work.
Tatsuro told to use 'CPPFLAGS' to pass these directories during configure only. This worked and the ''make'' step moved past that point.
Tatsuro told to use 'CPPFLAGS' to pass these directories during configure only. This worked and the ''make'' step moved past that point.


Now a new error arised, the Makefile was calling 'grep/sed' at some point which showed that the library file have been moved (which was present in /e/octave_dev/lib/octave/4.1.0+/) And then the script tries to use it from /usr/lib/octave/4.1.0+. But the library files were actually present in the previous directory only and not in /usr/lib. So, we passed 'LDFLAGS' along with 'CPPFLAGS' during configure. But the error persisted. Editing the last parte of liboct*.la files to change the 'libdir' didn't work as well.
Now a new error arised, the Makefile was calling 'grep/sed' at some point which showed that the library file have been moved (which was present in /e/octave_dev/lib/octave/4.1.0+/) And then the script tries to use it from /usr/lib/octave/4.1.0+. But the library files were actually present in the previous directory only and not in /usr/lib. So, we passed 'LDFLAGS' along with 'CPPFLAGS' during configure. But the error persisted. Editing the last part of liboct*.la files to change the 'libdir' didn't work as well.
As per Mike's suggestion deleting the liboct*.la files helped and the ''make'' step moved even furthur. Now the errors showed some missing libraries (lapack, GraphickMagik, ...)
As per Mike's suggestion deleting the liboct*.la files helped and the ''make'' step moved even furthur. Now the errors showed some missing libraries (lapack, GraphickMagik, ...)
Since all these libraries were present along with octave so we added "/e/octave_dev/lib" to LDFLAGS too. Now the build went even furthur. This time there were some C++11 errors. As per Mike's and Tatsuro's suggestions Octave uses 4.9.3 gcc on windows and gcc changed the library around version 5. Msys2 had GCC 5.4 which caused the errors. So, either pass all the gcc tools in octave_dev/bin to configure on MSYS2 or use octave's shell with MSYS2 on top of it.
Since all these libraries were present along with octave so we added "/e/octave_dev/lib" to LDFLAGS too. Now the build went even further. This time there were some C++11 errors. As per Mike's and Tatsuro's suggestions Octave uses 4.9.3 gcc on windows and gcc changed the library around version 5. Msys2 had GCC 5.4 which caused the errors. So, either pass all the gcc tools in octave_dev/bin to configure on MSYS2 or use octave's shell with MSYS2 on top of it.
At this point, I switched to using the bash shell present with octave.
At this point, I switched to using the bash shell present with octave.


39

edits