Otave deprecated fixes

[HinTak]

All the deprecated warnings against 4.x/5.x, except octave_main and clean_up_and_exit() . The warnings for those two just says "see manual for other options".

[HinTak]

@flatmax : ping - it has been a while. The last couple of warnings didn't look to have obvious replacements and I am unlikely to look into them any time soon, so this is okay to merge as is.

[flatmax]

Thanks for the ping, now merged.

[flatmax]

Nice work by the way!

[HinTak]

Thanks!

[flatmax]

Have you noticed that the test/OctaveTest.C executable fails at the moment ?

[HinTak]

Oh dear. I'll check.

[flatmax]

It may not be due to your patches.

[HinTak]

Hmm, on fedora 32, it fails at:

...
make[2]: Entering directory '/tmp/gtkiostream/test'
...
libtool: link: g++ -g -O2 -o OptionParserTest OptionParserTest.o ...
...
/usr/bin/ld: OptionParserTest.o: relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a PIE object; recompile with -fPIE
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:1650: OptionParserTest] Error 1
make[2]: Leaving directory '/tmp/gtkiostream/test'
make[1]: *** [Makefile:514: all-recursive] Error 1
make[1]: Leaving directory '/tmp/gtkiostream'
make: *** [Makefile:421: all] Error 2

But I see there is a mistake (not mine) in the compiling line, it is doing libtool: link: g++ -g -O2 -o OptionParserTest OptionParserTest.o ... -lgl2ps /usr/lib64/octave/5.2.0/liboctave.so -lcurl instead of libtool: link: g++ -g -O2 -o OptionParserTest OptionParserTest.o ... -lgl2ps -loctave -lcurl . This would have been something I did not see as I was doing the changes on a Pi / Raspbain (which has a much older octave, for better support of older versions). the -fPIE error is quite typical of x86_64. I'll see if I can quickly get around it and get further - you said it fails at the octave test (later)?

[flatmax]

Curious. It isn't failing currently on my operating system. The configure.ac for octave is messy ... perhaps octave has a more standard autotools.pc type of integration ?

…

On 3/9/20 9:49 am, HinTak wrote: Hmm, on fedora 32, it fails at: |... make[2]: Entering directory '/tmp/gtkiostream/test' ... libtool: link: g++ -g -O2 -o OptionParserTest OptionParserTest.o ... ... /usr/bin/ld: OptionParserTest.o: relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a PIE object; recompile with -fPIE collect2: error: ld returned 1 exit status make[2]: *** [Makefile:1650: OptionParserTest] Error 1 make[2]: Leaving directory '/tmp/gtkiostream/test' make[1]: *** [Makefile:514: all-recursive] Error 1 make[1]: Leaving directory '/tmp/gtkiostream' make: *** [Makefile:421: all] Error 2 | But I see there is a mistake (not mine) in the compiling line, it is doing |libtool: link: g++ -g -O2 -o OptionParserTest OptionParserTest.o ... -lgl2ps /usr/lib64/octave/5.2.0/liboctave.so -lcurl | instead of |libtool: link: g++ -g -O2 -o OptionParserTest OptionParserTest.o ... -lgl2ps -loctave -lcurl | . This would have been something I did not see as I was doing the changes on a Pi / Raspbain (which has a much older octave, for better support of older versions). the |-fPIE| error is quite typical of x86_64. I'll see if I can quickly get around it and get further - you said it fails at the octave test (later)? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#11 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFLUB26X2IMQKHAOOHWI3LSD3KYFANCNFSM4NDSUHOQ>.

[HinTak]

octave has a octave-config which works more or less like pkgconfig .

[flatmax]

Check how messy MKOCTFILE is with autotools ... https://github.com/flatmax/gtkiostream/blob/master/configure.ac#L231-L288 Perhaps octave-config will work better. Matt

…

On 3/9/20 10:07 am, HinTak wrote: octave has a |octave-config| which works more or less like |pkgconfig| . — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#11 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFLUBY3D6ZJC2KOUCSDGITSD3M3RANCNFSM4NDSUHOQ>.

[HinTak]

I did a fresh clone. Besides seeing #9 again (I need to hack at the Makefile to force gtk2, because it is detecting most my gtk3 stuff too), and the new -fPIE issue (which seems to be new - it is fairly generic but specific to x86_64 and only happens when things reaches a particular size, so it can suddenly appear when code sizes increases), I have finished compiling on fedora 32 against octave 5.2 .

The strange octiave library path I saiw seems to be a fedora mis-packaging - they shipped ./usr/lib64/octave/5.2.0/*.la, which seems to confuse libtool. I just moved them aside and it is fine.
.
So it seems to also compile and build fine here. I shall go and file the -fPIE issue now :-)

octave-config is unlikely to be an improvement on mkoctfile - since they must more-or-less give the same answers. I see their roles slightly different through - one is about how octave was built, the other is about how you like your (future) oct files to be built.