java package and MacOS

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

java package and MacOS

bpabbott
Administrator
Adding the Octave Forge java package to core Octave breaks building Octave on MacOS X.

        http://hg.savannah.gnu.org/hgweb/octave/rev/acf0addfc610

libtool: link: /opt/local/bin/g++-mp-4.5  -o dldfcn/.libs/__java__.so -bundle  dldfcn/.libs/dldfcn___java___la-__java__.o   -L/opt/local/lib ./.libs/liboctinterp.dylib -L/opt/local/libexec/llvm-3.1/lib -L/opt/local/lib/gcc45/gcc/x86_64-apple-darwin11/4.5.4 -L/opt/local/lib/gcc45/gcc/x86_64-apple-darwin11/4.5.4/../../.. -L/opt/local/lib/gcc45 /Users/bpabbott/Development/mercurial/default/sources/liboctave/.libs/liboctave.dylib -lfltk_gl -lfltk -lpthread /opt/local/lib/libhdf5.dylib /opt/local/lib/libfontconfig.dylib /opt/local/lib/libiconv.dylib /opt/local/lib/libfreetype.dylib -lz -lbz2 /opt/local/lib/libexpat.dylib /opt/local/lib/libX11.dylib /opt/local/lib/libxcb.dylib /opt/local/lib/libXau.dylib /opt/local/lib/libXdmcp.dylib -lLLVMAsmParser -lLLVMInstrumentation -lLLVMLinker -lLLVMArchive -lLLVMBitReader -lLLVMDebugInfo -lLLVMJIT -lLLVMipo -lLLVMVectorize -lLLVMBitWriter -lLLVMTableGen -lLLVMHexagonCodeGen -lLLVMHexagonAsmPrinter -lLLVMHexagonDesc -lLLVMHexagonInfo -lLLVMPTXCodeGen -lLLVMPTXDesc -lLLVMPTXInfo -lLLVMPTXAsmPrinter -lLLVMMBlazeDisassembler -lLLVMMBlazeAsmParser -lLLVMMBlazeCodeGen -lLLVMMBlazeDesc -lLLVMMBlazeInfo -lLLVMMBlazeAsmPrinter -lLLVMCppBackendCodeGen -lLLVMCppBackendInfo -lLLVMMSP430CodeGen -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMSP430AsmPrinter -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMCellSPUCodeGen -lLLVMCellSPUDesc -lLLVMCellSPUInfo -lLLVMMipsDisassembler -lLLVMMipsAsmParser -lLLVMMipsCodeGen -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMMipsAsmPrinter -lLLVMARMDisassembler -lLLVMARMAsmParser -lLLVMARMCodeGen -lLLVMARMDesc -lLLVMARMInfo -lLLVMARMAsmPrinter -lLLVMPowerPCCodeGen -lLLVMPowerPCDesc -lLLVMPowerPCAsmPrinter -lLLVMPowerPCInfo -lLLVMSparcCodeGen -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMX86AsmParser -lLLVMX86Disassembler -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCDisassembler -lLLVMMCParser -lLLVMInterpreter -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMMCJIT -lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMTarget -lLLVMMC -lLLVMObject -lLLVMCore -lLLVMSupport ../liboctave/.libs/liboctave.dylib -lstdc++ -lcholmod -lmetis -lumfpack -lsuitesparseconfig -lamd -lcamd -lcolamd -lccolamd -lcxsparse /opt/local/lib/libarpack.dylib -ltatlas -lqrupdate /opt/local/lib/libfftw3.dylib /opt/local/lib/libfftw3f.dylib -llapack -lcblas -lf77blas -latlas -lreadline -lncurses /opt/local/lib/libpcre.dylib -ldl /opt/local/lib/gcc45/libgfortran.dylib -lm  -O0 -m64 -pthread -Wl,-dylib_file -Wl,/usr/fubar/lib/octave/3.7.0+/liboctave.1.dylib:/Users/bpabbott/Development/mercurial/default/sources/liboctave/.libs/liboctave.dylib   -pthread -framework AGL -framework OpenGL -framework ApplicationServices -framework Cocoa
Undefined symbols for architecture x86_64:
  "_JNI_CreateJavaVM", referenced from:
      initialize_jvm()      in dldfcn___java___la-__java__.o
  "_JNI_GetCreatedJavaVMs", referenced from:
      initialize_jvm()      in dldfcn___java___la-__java__.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make[3]: *** [dldfcn/__java__.la] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Looking at config.log, I have the follow defined.

#define JAVA_ARCH ""
#define JAVA_HOME ""
ac_cv_prog_JAVA=java
ac_cv_prog_JAVAC=javac
JAVA='java'
JAVAC='javac'
JAVA_CPPFLAGS=''
JAVA_LIBS=''

Ben
Reply | Threaded
Open this post in threaded view
|

Re: java package and MacOS

Alexander Hansen-2
On 11/25/12 12:37 PM, Ben Abbott wrote:
> Adding the Octave Forge java package to core Octave breaks building Octave on MacOS X.
>
> http://hg.savannah.gnu.org/hgweb/octave/rev/acf0addfc610
>
> libtool: link: /opt/local/bin/g++-mp-4.5  -o dldfcn/.libs/__java__.so -bundle  dldfcn/.libs/dldfcn___java___la-__java__.o   -L/opt/local/lib ./.libs/liboctinterp.dylib -L/opt/local/libexec/llvm-3.1/lib -L/opt/local/lib/gcc45/gcc/x86_64-apple-darwin11/4.5.4 -L/opt/local/lib/gcc45/gcc/x86_64-apple-darwin11/4.5.4/../../.. -L/opt/local/lib/gcc45 /Users/bpabbott/Development/mercurial/default/sources/liboctave/.libs/liboctave.dylib -lfltk_gl -lfltk -lpthread /opt/local/lib/libhdf5.dylib /opt/local/lib/libfontconfig.dylib /opt/local/lib/libiconv.dylib /opt/local/lib/libfreetype.dylib -lz -lbz2 /opt/local/lib/libexpat.dylib /opt/local/lib/libX11.dylib /opt/local/lib/libxcb.dylib /opt/local/lib/libXau.dylib /opt/local/lib/libXdmcp.dylib -lLLVMAsmParser -lLLVMInstrumentation -lLLVMLinker -lLLVMArchive -lLLVMBitReader -lLLVMDebugInfo -lLLVMJIT -lLLVMipo -lLLVMVectorize -lLLVMBitWriter -lLLVMTableGen -lLLVMHexagonCodeGen -lLLVMHexagonAsmPrinter -lLLVMHexagonDesc -lLLVMHexagonInfo -lLL!
 VMPTXCodeG
en -lLLVMPTXDesc -lLLVMPTXInfo -lLLVMPTXAsmPrinter -lLLVMMBlazeDisassembler -lLLVMMBlazeAsmParser -lLLVMMBlazeCodeGen -lLLVMMBlazeDesc -lLLVMMBlazeInfo -lLLVMMBlazeAsmPrinter -lLLVMCppBackendCodeGen -lLLVMCppBackendInfo -lLLVMMSP430CodeGen -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMSP430AsmPrinter -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMCellSPUCodeGen -lLLVMCellSPUDesc -lLLVMCellSPUInfo -lLLVMMipsDisassembler -lLLVMMipsAsmParser -lLLVMMipsCodeGen -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMMipsAsmPrinter -lLLVMARMDisassembler -lLLVMARMAsmParser -lLLVMARMCodeGen -lLLVMARMDesc -lLLVMARMInfo -lLLVMARMAsmPrinter -lLLVMPowerPCCodeGen -lLLVMPowerPCDesc -lLLVMPowerPCAsmPrinter -lLLVMPowerPCInfo -lLLVMSparcCodeGen -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMX86AsmParser -lLLVMX86Disassembler -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCDisassembler -lLLVMMCParser -lLLVMInterpreter -lLLVMCodeGen -lLLVMSca!
 larOpts -l
LLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMMCJIT -lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMTarget -lLLVMMC -lLLVMObject -lLLVMCore -lLLVMSupport ../liboctave/.libs/liboctave.dylib -lstdc++ -lcholmod -lmetis -lumfpack -lsuitesparseconfig -lamd -lcamd -lcolamd -lccolamd -lcxsparse /opt/local/lib/libarpack.dylib -ltatlas -lqrupdate /opt/local/lib/libfftw3.dylib /opt/local/lib/libfftw3f.dylib -llapack -lcblas -lf77blas -latlas -lreadline -lncurses /opt/local/lib/libpcre.dylib -ldl /opt/local/lib/gcc45/libgfortran.dylib -lm  -O0 -m64 -pthread -Wl,-dylib_file -Wl,/usr/fubar/lib/octave/3.7.0+/liboctave.1.dylib:/Users/bpabbott/Development/mercurial/default/sources/liboctave/.libs/liboctave.dylib   -pthread -framework AGL -framework OpenGL -framework ApplicationServices -framework Cocoa

> Undefined symbols for architecture x86_64:
>   "_JNI_CreateJavaVM", referenced from:
>       initialize_jvm()      in dldfcn___java___la-__java__.o
>   "_JNI_GetCreatedJavaVMs", referenced from:
>       initialize_jvm()      in dldfcn___java___la-__java__.o
> ld: symbol(s) not found for architecture x86_64
> collect2: ld returned 1 exit status
> make[3]: *** [dldfcn/__java__.la] Error 1
> make[2]: *** [all] Error 2
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
>
> Looking at config.log, I have the follow defined.
>
> #define JAVA_ARCH ""
> #define JAVA_HOME ""
> ac_cv_prog_JAVA=java
> ac_cv_prog_JAVAC=javac
> JAVA='java'
> JAVAC='javac'
> JAVA_CPPFLAGS=''
> JAVA_LIBS=''
>
> Ben
>

Unless I missed seeing it, I didn't notice anything referencing a Java
library in that linker line, so that would indeed result in missing
symbols. :-)

What happens if you set JAVA_HOME before configuring, e.g. by

export JAVA_HOME=`/usr/libexec/java_home`

?
--
Alexander Hansen, Ph.D.
Fink User Liaison
My package updates: http://finkakh.wordpress.com/
Reply | Threaded
Open this post in threaded view
|

Re: java package and MacOS

bpabbott
Administrator

On Nov 25, 2012, at 3:29 PM, Alexander Hansen wrote:

> On 11/25/12 12:37 PM, Ben Abbott wrote:
>> Adding the Octave Forge java package to core Octave breaks building Octave on MacOS X.
>>
>> http://hg.savannah.gnu.org/hgweb/octave/rev/acf0addfc610
>>
>> libtool: link: /opt/local/bin/g++-mp-4.5  -o dldfcn/.libs/__java__.so -bundle  dldfcn/.libs/dldfcn___java___la-__java__.o   -L/opt/local/lib ./.libs/liboctinterp.dylib -L/opt/local/libexec/llvm-3.1/lib -L/opt/local/lib/gcc45/gcc/x86_64-apple-darwin11/4.5.4 -L/opt/local/lib/gcc45/gcc/x86_64-apple-darwin11/4.5.4/../../.. -L/opt/local/lib/gcc45 /Users/bpabbott/Development/mercurial/default/sources/liboctave/.libs/liboctave.dylib -lfltk_gl -lfltk -lpthread /opt/local/lib/libhdf5.dylib /opt/local/lib/libfontconfig.dylib /opt/local/lib/libiconv.dylib /opt/local/lib/libfreetype.dylib -lz -lbz2 /opt/local/lib/libexpat.dylib /opt/local/lib/libX11.dylib /opt/local/lib/libxcb.dylib /opt/local/lib/libXau.dylib /opt/local/lib/libXdmcp.dylib -lLLVMAsmParser -lLLVMInstrumentation -lLLVMLinker -lLLVMArchive -lLLVMBitReader -lLLVMDebugInfo -lLLVMJIT -lLLVMipo -lLLVMVectorize -lLLVMBitWriter -lLLVMTableGen -lLLVMHexagonCodeGen -lLLVMHexagonAsmPrinter -lLLVMHexagonDesc -lLLVMHexagonInfo
> -lLLVMPTXCodeG
> en -lLLVMPTXDesc -lLLVMPTXInfo -lLLVMPTXAsmPrinter -lLLVMMBlazeDisassembler -lLLVMMBlazeAsmParser -lLLVMMBlazeCodeGen -lLLVMMBlazeDesc -lLLVMMBlazeInfo -lLLVMMBlazeAsmPrinter -lLLVMCppBackendCodeGen -lLLVMCppBackendInfo -lLLVMMSP430CodeGen -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMSP430AsmPrinter -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMCellSPUCodeGen -lLLVMCellSPUDesc -lLLVMCellSPUInfo -lLLVMMipsDisassembler -lLLVMMipsAsmParser -lLLVMMipsCodeGen -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMMipsAsmPrinter -lLLVMARMDisassembler -lLLVMARMAsmParser -lLLVMARMCodeGen -lLLVMARMDesc -lLLVMARMInfo -lLLVMARMAsmPrinter -lLLVMPowerPCCodeGen -lLLVMPowerPCDesc -lLLVMPowerPCAsmPrinter -lLLVMPowerPCInfo -lLLVMSparcCodeGen -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMX86AsmParser -lLLVMX86Disassembler -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCDisassembler -lLLVMMCParser -lLLVMInterpreter -lLLVMCodeGen -lLLVMScalarOpts
> -l
> LLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMMCJIT -lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMTarget -lLLVMMC -lLLVMObject -lLLVMCore -lLLVMSupport ../liboctave/.libs/liboctave.dylib -lstdc++ -lcholmod -lmetis -lumfpack -lsuitesparseconfig -lamd -lcamd -lcolamd -lccolamd -lcxsparse /opt/local/lib/libarpack.dylib -ltatlas -lqrupdate /opt/local/lib/libfftw3.dylib /opt/local/lib/libfftw3f.dylib -llapack -lcblas -lf77blas -latlas -lreadline -lncurses /opt/local/lib/libpcre.dylib -ldl /opt/local/lib/gcc45/libgfortran.dylib -lm  -O0 -m64 -pthread -Wl,-dylib_file -Wl,/usr/fubar/lib/octave/3.7.0+/liboctave.1.dylib:/Users/bpabbott/Development/mercurial/default/sources/liboctave/.libs/liboctave.dylib   -pthread -framework AGL -framework OpenGL -framework ApplicationServices -framework Cocoa
>> Undefined symbols for architecture x86_64:
>>  "_JNI_CreateJavaVM", referenced from:
>>      initialize_jvm()      in dldfcn___java___la-__java__.o
>>  "_JNI_GetCreatedJavaVMs", referenced from:
>>      initialize_jvm()      in dldfcn___java___la-__java__.o
>> ld: symbol(s) not found for architecture x86_64
>> collect2: ld returned 1 exit status
>> make[3]: *** [dldfcn/__java__.la] Error 1
>> make[2]: *** [all] Error 2
>> make[1]: *** [all-recursive] Error 1
>> make: *** [all] Error 2
>>
>> Looking at config.log, I have the follow defined.
>>
>> #define JAVA_ARCH ""
>> #define JAVA_HOME ""
>> ac_cv_prog_JAVA=java
>> ac_cv_prog_JAVAC=javac
>> JAVA='java'
>> JAVAC='javac'
>> JAVA_CPPFLAGS=''
>> JAVA_LIBS=''
>>
>> Ben
>>
>
> Unless I missed seeing it, I didn't notice anything referencing a Java
> library in that linker line, so that would indeed result in missing
> symbols. :-)
>
> What happens if you set JAVA_HOME before configuring, e.g. by
>
> export JAVA_HOME=`/usr/libexec/java_home`
>
> ?

I haven't tried JAVA_HOME, but setting JAVA_LIBS allowed the build to complete.

        export JAVA_LIBS="-framework JavaVM"

Maybe this should be set in configure.ac for MacOS?

Ben


Reply | Threaded
Open this post in threaded view
|

Re: java package and MacOS

bpabbott
Administrator
On Nov 25, 2012, at 6:27 PM, Ben Abbott wrote:

> On Nov 25, 2012, at 3:29 PM, Alexander Hansen wrote:
>
>> On 11/25/12 12:37 PM, Ben Abbott wrote:
>>> Adding the Octave Forge java package to core Octave breaks building Octave on MacOS X.
>>>
>>> http://hg.savannah.gnu.org/hgweb/octave/rev/acf0addfc610
>>>
>>> libtool: link: /opt/local/bin/g++-mp-4.5  -o dldfcn/.libs/__java__.so -bundle  dldfcn/.libs/dldfcn___java___la-__java__.o   -L/opt/local/lib ./.libs/liboctinterp.dylib -L/opt/local/libexec/llvm-3.1/lib -L/opt/local/lib/gcc45/gcc/x86_64-apple-darwin11/4.5.4 -L/opt/local/lib/gcc45/gcc/x86_64-apple-darwin11/4.5.4/../../.. -L/opt/local/lib/gcc45 /Users/bpabbott/Development/mercurial/default/sources/liboctave/.libs/liboctave.dylib -lfltk_gl -lfltk -lpthread /opt/local/lib/libhdf5.dylib /opt/local/lib/libfontconfig.dylib /opt/local/lib/libiconv.dylib /opt/local/lib/libfreetype.dylib -lz -lbz2 /opt/local/lib/libexpat.dylib /opt/local/lib/libX11.dylib /opt/local/lib/libxcb.dylib /opt/local/lib/libXau.dylib /opt/local/lib/libXdmcp.dylib -lLLVMAsmParser -lLLVMInstrumentation -lLLVMLinker -lLLVMArchive -lLLVMBitReader -lLLVMDebugInfo -lLLVMJIT -lLLVMipo -lLLVMVectorize -lLLVMBitWriter -lLLVMTableGen -lLLVMHexagonCodeGen -lLLVMHexagonAsmPrinter -lLLVMHexagonDesc -lLLVMHexagonInfo
>> -lLLVMPTXCodeG
>> en -lLLVMPTXDesc -lLLVMPTXInfo -lLLVMPTXAsmPrinter -lLLVMMBlazeDisassembler -lLLVMMBlazeAsmParser -lLLVMMBlazeCodeGen -lLLVMMBlazeDesc -lLLVMMBlazeInfo -lLLVMMBlazeAsmPrinter -lLLVMCppBackendCodeGen -lLLVMCppBackendInfo -lLLVMMSP430CodeGen -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMSP430AsmPrinter -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMCellSPUCodeGen -lLLVMCellSPUDesc -lLLVMCellSPUInfo -lLLVMMipsDisassembler -lLLVMMipsAsmParser -lLLVMMipsCodeGen -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMMipsAsmPrinter -lLLVMARMDisassembler -lLLVMARMAsmParser -lLLVMARMCodeGen -lLLVMARMDesc -lLLVMARMInfo -lLLVMARMAsmPrinter -lLLVMPowerPCCodeGen -lLLVMPowerPCDesc -lLLVMPowerPCAsmPrinter -lLLVMPowerPCInfo -lLLVMSparcCodeGen -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMX86AsmParser -lLLVMX86Disassembler -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCDisassembler -lLLVMMCParser -lLLVMInterpreter -lLLVMCodeGen -lLLVMScalarOpts
>> -l
>> LLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMMCJIT -lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMTarget -lLLVMMC -lLLVMObject -lLLVMCore -lLLVMSupport ../liboctave/.libs/liboctave.dylib -lstdc++ -lcholmod -lmetis -lumfpack -lsuitesparseconfig -lamd -lcamd -lcolamd -lccolamd -lcxsparse /opt/local/lib/libarpack.dylib -ltatlas -lqrupdate /opt/local/lib/libfftw3.dylib /opt/local/lib/libfftw3f.dylib -llapack -lcblas -lf77blas -latlas -lreadline -lncurses /opt/local/lib/libpcre.dylib -ldl /opt/local/lib/gcc45/libgfortran.dylib -lm  -O0 -m64 -pthread -Wl,-dylib_file -Wl,/usr/fubar/lib/octave/3.7.0+/liboctave.1.dylib:/Users/bpabbott/Development/mercurial/default/sources/liboctave/.libs/liboctave.dylib   -pthread -framework AGL -framework OpenGL -framework ApplicationServices -framework Cocoa
>>> Undefined symbols for architecture x86_64:
>>> "_JNI_CreateJavaVM", referenced from:
>>>     initialize_jvm()      in dldfcn___java___la-__java__.o
>>> "_JNI_GetCreatedJavaVMs", referenced from:
>>>     initialize_jvm()      in dldfcn___java___la-__java__.o
>>> ld: symbol(s) not found for architecture x86_64
>>> collect2: ld returned 1 exit status
>>> make[3]: *** [dldfcn/__java__.la] Error 1
>>> make[2]: *** [all] Error 2
>>> make[1]: *** [all-recursive] Error 1
>>> make: *** [all] Error 2
>>>
>>> Looking at config.log, I have the follow defined.
>>>
>>> #define JAVA_ARCH ""
>>> #define JAVA_HOME ""
>>> ac_cv_prog_JAVA=java
>>> ac_cv_prog_JAVAC=javac
>>> JAVA='java'
>>> JAVAC='javac'
>>> JAVA_CPPFLAGS=''
>>> JAVA_LIBS=''
>>>
>>> Ben
>>>
>>
>> Unless I missed seeing it, I didn't notice anything referencing a Java
>> library in that linker line, so that would indeed result in missing
>> symbols. :-)
>>
>> What happens if you set JAVA_HOME before configuring, e.g. by
>>
>> export JAVA_HOME=`/usr/libexec/java_home`
>>
>> ?
>
> I haven't tried JAVA_HOME, but setting JAVA_LIBS allowed the build to complete.
>
> export JAVA_LIBS="-framework JavaVM"
>
> Maybe this should be set in configure.ac for MacOS?
>
> Ben

Carlo's change to configure.ac works for me.

http://octave.1599824.n4.nabble.com/changeset-for-configuring-with-Java-on-OSX-tt4647251.html

When I try "dlgtest(0)" I get ...

        Java JDK home directory  does not exist.
        Please adapt java_home in dlgtest.m.

Setting JAVA_HOME to that used during the build gives ...

        setenv JAVA_HOME "/System/Library/Frameworks/JavaVM.framework/Home"

Now "dlgtest(0)" results in ...

        0 ... STOP
        1 ... listdlg tests
        2 ... errordlg tests
        3 ... warndlg tests
        4 ... helpdlg tests
        5 ... inputdlg tests
        6 ... TeX code tests
        Run which test?   [0] >

Is this the expected result?

Ben




Reply | Threaded
Open this post in threaded view
|

Re: java package and MacOS

Daniel Sebald
On 11/27/2012 02:58 PM, Ben Abbott wrote:

> On Nov 25, 2012, at 6:27 PM, Ben Abbott wrote:
>
>> On Nov 25, 2012, at 3:29 PM, Alexander Hansen wrote:
>>
>>> On 11/25/12 12:37 PM, Ben Abbott wrote:
>>>> Adding the Octave Forge java package to core Octave breaks building Octave on MacOS X.
>>>>
>>>> http://hg.savannah.gnu.org/hgweb/octave/rev/acf0addfc610
>>>>
>>>> libtool: link: /opt/local/bin/g++-mp-4.5  -o dldfcn/.libs/__java__.so -bundle  dldfcn/.libs/dldfcn___java___la-__java__.o   -L/opt/local/lib ./.libs/liboctinterp.dylib -L/opt/local/libexec/llvm-3.1/lib -L/opt/local/lib/gcc45/gcc/x86_64-apple-darwin11/4.5.4 -L/opt/local/lib/gcc45/gcc/x86_64-apple-darwin11/4.5.4/../../.. -L/opt/local/lib/gcc45 /Users/bpabbott/Development/mercurial/default/sources/liboctave/.libs/liboctave.dylib -lfltk_gl -lfltk -lpthread /opt/local/lib/libhdf5.dylib /opt/local/lib/libfontconfig.dylib /opt/local/lib/libiconv.dylib /opt/local/lib/libfreetype.dylib -lz -lbz2 /opt/local/lib/libexpat.dylib /opt/local/lib/libX11.dylib /opt/local/lib/libxcb.dylib /opt/local/lib/libXau.dylib /opt/local/lib/libXdmcp.dylib -lLLVMAsmParser -lLLVMInstrumentation -lLLVMLinker -lLLVMArchive -lLLVMBitReader -lLLVMDebugInfo -lLLVMJIT -lLLVMipo -lLLVMVectorize -lLLVMBitWriter -lLLVMTableGen -lLLVMHexagonCodeGen -lLLVMHexagonAsmPrinter -lLLVMHexagonDesc -lLLVMHexagonInfo
>>> -lLLVMPTXCodeG
>>> en -lLLVMPTXDesc -lLLVMPTXInfo -lLLVMPTXAsmPrinter -lLLVMMBlazeDisassembler -lLLVMMBlazeAsmParser -lLLVMMBlazeCodeGen -lLLVMMBlazeDesc -lLLVMMBlazeInfo -lLLVMMBlazeAsmPrinter -lLLVMCppBackendCodeGen -lLLVMCppBackendInfo -lLLVMMSP430CodeGen -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMSP430AsmPrinter -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMCellSPUCodeGen -lLLVMCellSPUDesc -lLLVMCellSPUInfo -lLLVMMipsDisassembler -lLLVMMipsAsmParser -lLLVMMipsCodeGen -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMMipsAsmPrinter -lLLVMARMDisassembler -lLLVMARMAsmParser -lLLVMARMCodeGen -lLLVMARMDesc -lLLVMARMInfo -lLLVMARMAsmPrinter -lLLVMPowerPCCodeGen -lLLVMPowerPCDesc -lLLVMPowerPCAsmPrinter -lLLVMPowerPCInfo -lLLVMSparcCodeGen -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMX86AsmParser -lLLVMX86Disassembler -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCDisassembler -lLLVMMCParser -lLLVMInterpreter -lLLVMCodeGen -lLLVM
ScalarOpts

>>> -l
>>> LLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMMCJIT -lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMTarget -lLLVMMC -lLLVMObject -lLLVMCore -lLLVMSupport ../liboctave/.libs/liboctave.dylib -lstdc++ -lcholmod -lmetis -lumfpack -lsuitesparseconfig -lamd -lcamd -lcolamd -lccolamd -lcxsparse /opt/local/lib/libarpack.dylib -ltatlas -lqrupdate /opt/local/lib/libfftw3.dylib /opt/local/lib/libfftw3f.dylib -llapack -lcblas -lf77blas -latlas -lreadline -lncurses /opt/local/lib/libpcre.dylib -ldl /opt/local/lib/gcc45/libgfortran.dylib -lm  -O0 -m64 -pthread -Wl,-dylib_file -Wl,/usr/fubar/lib/octave/3.7.0+/liboctave.1.dylib:/Users/bpabbott/Development/mercurial/default/sources/liboctave/.libs/liboctave.dylib   -pthread -framework AGL -framework OpenGL -framework ApplicationServices -framework Cocoa
>>>> Undefined symbols for architecture x86_64:
>>>> "_JNI_CreateJavaVM", referenced from:
>>>>      initialize_jvm()      in dldfcn___java___la-__java__.o
>>>> "_JNI_GetCreatedJavaVMs", referenced from:
>>>>      initialize_jvm()      in dldfcn___java___la-__java__.o
>>>> ld: symbol(s) not found for architecture x86_64
>>>> collect2: ld returned 1 exit status
>>>> make[3]: *** [dldfcn/__java__.la] Error 1
>>>> make[2]: *** [all] Error 2
>>>> make[1]: *** [all-recursive] Error 1
>>>> make: *** [all] Error 2
>>>>
>>>> Looking at config.log, I have the follow defined.
>>>>
>>>> #define JAVA_ARCH ""
>>>> #define JAVA_HOME ""
>>>> ac_cv_prog_JAVA=java
>>>> ac_cv_prog_JAVAC=javac
>>>> JAVA='java'
>>>> JAVAC='javac'
>>>> JAVA_CPPFLAGS=''
>>>> JAVA_LIBS=''
>>>>
>>>> Ben
>>>>
>>>
>>> Unless I missed seeing it, I didn't notice anything referencing a Java
>>> library in that linker line, so that would indeed result in missing
>>> symbols. :-)
>>>
>>> What happens if you set JAVA_HOME before configuring, e.g. by
>>>
>>> export JAVA_HOME=`/usr/libexec/java_home`
>>>
>>> ?
>>
>> I haven't tried JAVA_HOME, but setting JAVA_LIBS allowed the build to complete.
>>
>> export JAVA_LIBS="-framework JavaVM"
>>
>> Maybe this should be set in configure.ac for MacOS?
>>
>> Ben
>
> Carlo's change to configure.ac works for me.
>
> http://octave.1599824.n4.nabble.com/changeset-for-configuring-with-Java-on-OSX-tt4647251.html
>
> When I try "dlgtest(0)" I get ...
>
> Java JDK home directory  does not exist.
> Please adapt java_home in dlgtest.m.
>
> Setting JAVA_HOME to that used during the build gives ...
>
> setenv JAVA_HOME "/System/Library/Frameworks/JavaVM.framework/Home"
>
> Now "dlgtest(0)" results in ...
>
> 0 ... STOP
> 1 ... listdlg tests
> 2 ... errordlg tests
> 3 ... warndlg tests
> 4 ... helpdlg tests
> 5 ... inputdlg tests
> 6 ... TeX code tests
> Run which test?   [0]>
>
> Is this the expected result?
>
> Ben

Yes.  When you run one of those tests there should be some dialog boxes
appear on the screen if Java is working properly.

BTW, I've just altered dlgtest on my local copy so that it doesn't
return if the JAVA_HOME variable isn't defined.  Instead, it issues the
current warning and continues on.  When unsetting the JAVA_HOME variable
with

export -n JAVA_HOME

the Java demo seems to still work properly.  I think this conditional
can be removed.  It isn't clear to me where/why JAVA_HOME definition is
required.  I'm guessing it is interior to Octave java support somewhere
and dlgtest() is assuming something about its requirement, but I keep
thinking Octave should just fall back on "java" and "javac" as set up by
the shell if nothing else.

As an aside, the function "getenv" doesn't seem to make a distinction
between an environment variable not being set and an environment
variable set to nothing.  Both those cases result in an empty string.
Is it worth making a distinction here, either returning a different
result or a new routine "isenv()"?

Dan
Reply | Threaded
Open this post in threaded view
|

Re: java package and MacOS

bpabbott
Administrator

On Nov 27, 2012, at 4:30 PM, Daniel J Sebald wrote:

> On 11/27/2012 02:58 PM, Ben Abbott wrote:
>> On Nov 25, 2012, at 6:27 PM, Ben Abbott wrote:
>>
>>> On Nov 25, 2012, at 3:29 PM, Alexander Hansen wrote:
>>>
>>>> On 11/25/12 12:37 PM, Ben Abbott wrote:
>>>>> Adding the Octave Forge java package to core Octave breaks building Octave on MacOS X.
>>>>>
>>>>> http://hg.savannah.gnu.org/hgweb/octave/rev/acf0addfc610
>>>>>
>>>>> libtool: link: /opt/local/bin/g++-mp-4.5  -o dldfcn/.libs/__java__.so -bundle  dldfcn/.libs/dldfcn___java___la-__java__.o   -L/opt/local/lib ./.libs/liboctinterp.dylib -L/opt/local/libexec/llvm-3.1/lib -L/opt/local/lib/gcc45/gcc/x86_64-apple-darwin11/4.5.4 -L/opt/local/lib/gcc45/gcc/x86_64-apple-darwin11/4.5.4/../../.. -L/opt/local/lib/gcc45 /Users/bpabbott/Development/mercurial/default/sources/liboctave/.libs/liboctave.dylib -lfltk_gl -lfltk -lpthread /opt/local/lib/libhdf5.dylib /opt/local/lib/libfontconfig.dylib /opt/local/lib/libiconv.dylib /opt/local/lib/libfreetype.dylib -lz -lbz2 /opt/local/lib/libexpat.dylib /opt/local/lib/libX11.dylib /opt/local/lib/libxcb.dylib /opt/local/lib/libXau.dylib /opt/local/lib/libXdmcp.dylib -lLLVMAsmParser -lLLVMInstrumentation -lLLVMLinker -lLLVMArchive -lLLVMBitReader -lLLVMDebugInfo -lLLVMJIT -lLLVMipo -lLLVMVectorize -lLLVMBitWriter -lLLVMTableGen -lLLVMHexagonCodeGen -lLLVMHexagonAsmPrinter -lLLVMHexagonDesc -lLLVMHexagonInfo
>>>> -lLLVMPTXCodeG
>>>> en -lLLVMPTXDesc -lLLVMPTXInfo -lLLVMPTXAsmPrinter -lLLVMMBlazeDisassembler -lLLVMMBlazeAsmParser -lLLVMMBlazeCodeGen -lLLVMMBlazeDesc -lLLVMMBlazeInfo -lLLVMMBlazeAsmPrinter -lLLVMCppBackendCodeGen -lLLVMCppBackendInfo -lLLVMMSP430CodeGen -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMSP430AsmPrinter -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMCellSPUCodeGen -lLLVMCellSPUDesc -lLLVMCellSPUInfo -lLLVMMipsDisassembler -lLLVMMipsAsmParser -lLLVMMipsCodeGen -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMMipsAsmPrinter -lLLVMARMDisassembler -lLLVMARMAsmParser -lLLVMARMCodeGen -lLLVMARMDesc -lLLVMARMInfo -lLLVMARMAsmPrinter -lLLVMPowerPCCodeGen -lLLVMPowerPCDesc -lLLVMPowerPCAsmPrinter -lLLVMPowerPCInfo -lLLVMSparcCodeGen -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMX86AsmParser -lLLVMX86Disassembler -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCDisassembler -lLLVMMCParser -lLLVMInterpreter -lLLVMCodeGen -lLL!
 VM

> ScalarOpts
>>>> -l
>>>> LLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMMCJIT -lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMTarget -lLLVMMC -lLLVMObject -lLLVMCore -lLLVMSupport ../liboctave/.libs/liboctave.dylib -lstdc++ -lcholmod -lmetis -lumfpack -lsuitesparseconfig -lamd -lcamd -lcolamd -lccolamd -lcxsparse /opt/local/lib/libarpack.dylib -ltatlas -lqrupdate /opt/local/lib/libfftw3.dylib /opt/local/lib/libfftw3f.dylib -llapack -lcblas -lf77blas -latlas -lreadline -lncurses /opt/local/lib/libpcre.dylib -ldl /opt/local/lib/gcc45/libgfortran.dylib -lm  -O0 -m64 -pthread -Wl,-dylib_file -Wl,/usr/fubar/lib/octave/3.7.0+/liboctave.1.dylib:/Users/bpabbott/Development/mercurial/default/sources/liboctave/.libs/liboctave.dylib   -pthread -framework AGL -framework OpenGL -framework ApplicationServices -framework Cocoa
>>>>> Undefined symbols for architecture x86_64:
>>>>> "_JNI_CreateJavaVM", referenced from:
>>>>>     initialize_jvm()      in dldfcn___java___la-__java__.o
>>>>> "_JNI_GetCreatedJavaVMs", referenced from:
>>>>>     initialize_jvm()      in dldfcn___java___la-__java__.o
>>>>> ld: symbol(s) not found for architecture x86_64
>>>>> collect2: ld returned 1 exit status
>>>>> make[3]: *** [dldfcn/__java__.la] Error 1
>>>>> make[2]: *** [all] Error 2
>>>>> make[1]: *** [all-recursive] Error 1
>>>>> make: *** [all] Error 2
>>>>>
>>>>> Looking at config.log, I have the follow defined.
>>>>>
>>>>> #define JAVA_ARCH ""
>>>>> #define JAVA_HOME ""
>>>>> ac_cv_prog_JAVA=java
>>>>> ac_cv_prog_JAVAC=javac
>>>>> JAVA='java'
>>>>> JAVAC='javac'
>>>>> JAVA_CPPFLAGS=''
>>>>> JAVA_LIBS=''
>>>>>
>>>>> Ben
>>>>>
>>>>
>>>> Unless I missed seeing it, I didn't notice anything referencing a Java
>>>> library in that linker line, so that would indeed result in missing
>>>> symbols. :-)
>>>>
>>>> What happens if you set JAVA_HOME before configuring, e.g. by
>>>>
>>>> export JAVA_HOME=`/usr/libexec/java_home`
>>>>
>>>> ?
>>>
>>> I haven't tried JAVA_HOME, but setting JAVA_LIBS allowed the build to complete.
>>>
>>> export JAVA_LIBS="-framework JavaVM"
>>>
>>> Maybe this should be set in configure.ac for MacOS?
>>>
>>> Ben
>>
>> Carlo's change to configure.ac works for me.
>>
>> http://octave.1599824.n4.nabble.com/changeset-for-configuring-with-Java-on-OSX-tt4647251.html
>>
>> When I try "dlgtest(0)" I get ...
>>
>> Java JDK home directory  does not exist.
>> Please adapt java_home in dlgtest.m.
>>
>> Setting JAVA_HOME to that used during the build gives ...
>>
>> setenv JAVA_HOME "/System/Library/Frameworks/JavaVM.framework/Home"
>>
>> Now "dlgtest(0)" results in ...
>>
>> 0 ... STOP
>> 1 ... listdlg tests
>> 2 ... errordlg tests
>> 3 ... warndlg tests
>> 4 ... helpdlg tests
>> 5 ... inputdlg tests
>> 6 ... TeX code tests
>> Run which test?   [0]>
>>
>> Is this the expected result?
>>
>> Ben
>
> Yes.  When you run one of those tests there should be some dialog boxes appear on the screen if Java is working properly.
>
> BTW, I've just altered dlgtest on my local copy so that it doesn't return if the JAVA_HOME variable isn't defined.  Instead, it issues the current warning and continues on.  When unsetting the JAVA_HOME variable with
>
> export -n JAVA_HOME
>
> the Java demo seems to still work properly.  I think this conditional can be removed.  It isn't clear to me where/why JAVA_HOME definition is required.  I'm guessing it is interior to Octave java support somewhere and dlgtest() is assuming something about its requirement, but I keep thinking Octave should just fall back on "java" and "javac" as set up by the shell if nothing else.
>
> As an aside, the function "getenv" doesn't seem to make a distinction between an environment variable not being set and an environment variable set to nothing.  Both those cases result in an empty string. Is it worth making a distinction here, either returning a different result or a new routine "isenv()"?
>
> Dan

No dialog boxes appear for me.  I assume that is a confirmation that the Java stuff doesn't work on OSX.

Ben


Reply | Threaded
Open this post in threaded view
|

Re: java package and MacOS

Daniel Sebald
On 11/27/2012 04:55 PM, Ben Abbott wrote:

>
> On Nov 27, 2012, at 4:30 PM, Daniel J Sebald wrote:
>
>> On 11/27/2012 02:58 PM, Ben Abbott wrote:
>>> On Nov 25, 2012, at 6:27 PM, Ben Abbott wrote:
>>>
>>>> On Nov 25, 2012, at 3:29 PM, Alexander Hansen wrote:
>>>>
>>>>> On 11/25/12 12:37 PM, Ben Abbott wrote:
>>>>>> Adding the Octave Forge java package to core Octave breaks building Octave on MacOS X.
>>>>>>
>>>>>> http://hg.savannah.gnu.org/hgweb/octave/rev/acf0addfc610
>>>>>>
>>>>>> libtool: link: /opt/local/bin/g++-mp-4.5  -o dldfcn/.libs/__java__.so -bundle  dldfcn/.libs/dldfcn___java___la-__java__.o   -L/opt/local/lib ./.libs/liboctinterp.dylib -L/opt/local/libexec/llvm-3.1/lib -L/opt/local/lib/gcc45/gcc/x86_64-apple-darwin11/4.5.4 -L/opt/local/lib/gcc45/gcc/x86_64-apple-darwin11/4.5.4/../../.. -L/opt/local/lib/gcc45 /Users/bpabbott/Development/mercurial/default/sources/liboctave/.libs/liboctave.dylib -lfltk_gl -lfltk -lpthread /opt/local/lib/libhdf5.dylib /opt/local/lib/libfontconfig.dylib /opt/local/lib/libiconv.dylib /opt/local/lib/libfreetype.dylib -lz -lbz2 /opt/local/lib/libexpat.dylib /opt/local/lib/libX11.dylib /opt/local/lib/libxcb.dylib /opt/local/lib/libXau.dylib /opt/local/lib/libXdmcp.dylib -lLLVMAsmParser -lLLVMInstrumentation -lLLVMLinker -lLLVMArchive -lLLVMBitReader -lLLVMDebugInfo -lLLVMJIT -lLLVMipo -lLLVMVectorize -lLLVMBitWriter -lLLVMTableGen -lLLVMHexagonCodeGen -lLLVMHexagonAsmPrinter -lLLVMHexagonDesc -lLLVMHexagonInfo

>>>>> -lLLVMPTXCodeG
>>>>> en -lLLVMPTXDesc -lLLVMPTXInfo -lLLVMPTXAsmPrinter -lLLVMMBlazeDisassembler -lLLVMMBlazeAsmParser -lLLVMMBlazeCodeGen -lLLVMMBlazeDesc -lLLVMMBlazeInfo -lLLVMMBlazeAsmPrinter -lLLVMCppBackendCodeGen -lLLVMCppBackendInfo -lLLVMMSP430CodeGen -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMSP430AsmPrinter -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMCellSPUCodeGen -lLLVMCellSPUDesc -lLLVMCellSPUInfo -lLLVMMipsDisassembler -lLLVMMipsAsmParser -lLLVMMipsCodeGen -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMMipsAsmPrinter -lLLVMARMDisassembler -lLLVMARMAsmParser -lLLVMARMCodeGen -lLLVMARMDesc -lLLVMARMInfo -lLLVMARMAsmPrinter -lLLVMPowerPCCodeGen -lLLVMPowerPCDesc -lLLVMPowerPCAsmPrinter -lLLVMPowerPCInfo -lLLVMSparcCodeGen -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMX86AsmParser -lLLVMX86Disassembler -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCDisassembler -lLLVMMCParser -lLLVMInterpreter -lLLVMCodeGen -lLL
!

>   VM
>> ScalarOpts
>>>>> -l
>>>>> LLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMMCJIT -lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMTarget -lLLVMMC -lLLVMObject -lLLVMCore -lLLVMSupport ../liboctave/.libs/liboctave.dylib -lstdc++ -lcholmod -lmetis -lumfpack -lsuitesparseconfig -lamd -lcamd -lcolamd -lccolamd -lcxsparse /opt/local/lib/libarpack.dylib -ltatlas -lqrupdate /opt/local/lib/libfftw3.dylib /opt/local/lib/libfftw3f.dylib -llapack -lcblas -lf77blas -latlas -lreadline -lncurses /opt/local/lib/libpcre.dylib -ldl /opt/local/lib/gcc45/libgfortran.dylib -lm  -O0 -m64 -pthread -Wl,-dylib_file -Wl,/usr/fubar/lib/octave/3.7.0+/liboctave.1.dylib:/Users/bpabbott/Development/mercurial/default/sources/liboctave/.libs/liboctave.dylib   -pthread -framework AGL -framework OpenGL -framework ApplicationServices -framework Cocoa
>>>>>> Undefined symbols for architecture x86_64:
>>>>>> "_JNI_CreateJavaVM", referenced from:
>>>>>>      initialize_jvm()      in dldfcn___java___la-__java__.o
>>>>>> "_JNI_GetCreatedJavaVMs", referenced from:
>>>>>>      initialize_jvm()      in dldfcn___java___la-__java__.o
>>>>>> ld: symbol(s) not found for architecture x86_64
>>>>>> collect2: ld returned 1 exit status
>>>>>> make[3]: *** [dldfcn/__java__.la] Error 1
>>>>>> make[2]: *** [all] Error 2
>>>>>> make[1]: *** [all-recursive] Error 1
>>>>>> make: *** [all] Error 2
>>>>>>
>>>>>> Looking at config.log, I have the follow defined.
>>>>>>
>>>>>> #define JAVA_ARCH ""
>>>>>> #define JAVA_HOME ""
>>>>>> ac_cv_prog_JAVA=java
>>>>>> ac_cv_prog_JAVAC=javac
>>>>>> JAVA='java'
>>>>>> JAVAC='javac'
>>>>>> JAVA_CPPFLAGS=''
>>>>>> JAVA_LIBS=''
>>>>>>
>>>>>> Ben
>>>>>>
>>>>>
>>>>> Unless I missed seeing it, I didn't notice anything referencing a Java
>>>>> library in that linker line, so that would indeed result in missing
>>>>> symbols. :-)
>>>>>
>>>>> What happens if you set JAVA_HOME before configuring, e.g. by
>>>>>
>>>>> export JAVA_HOME=`/usr/libexec/java_home`
>>>>>
>>>>> ?
>>>>
>>>> I haven't tried JAVA_HOME, but setting JAVA_LIBS allowed the build to complete.
>>>>
>>>> export JAVA_LIBS="-framework JavaVM"
>>>>
>>>> Maybe this should be set in configure.ac for MacOS?
>>>>
>>>> Ben
>>>
>>> Carlo's change to configure.ac works for me.
>>>
>>> http://octave.1599824.n4.nabble.com/changeset-for-configuring-with-Java-on-OSX-tt4647251.html
>>>
>>> When I try "dlgtest(0)" I get ...
>>>
>>> Java JDK home directory  does not exist.
>>> Please adapt java_home in dlgtest.m.
>>>
>>> Setting JAVA_HOME to that used during the build gives ...
>>>
>>> setenv JAVA_HOME "/System/Library/Frameworks/JavaVM.framework/Home"
>>>
>>> Now "dlgtest(0)" results in ...
>>>
>>> 0 ... STOP
>>> 1 ... listdlg tests
>>> 2 ... errordlg tests
>>> 3 ... warndlg tests
>>> 4 ... helpdlg tests
>>> 5 ... inputdlg tests
>>> 6 ... TeX code tests
>>> Run which test?   [0]>
>>>
>>> Is this the expected result?
>>>
>>> Ben
>>
>> Yes.  When you run one of those tests there should be some dialog boxes appear on the screen if Java is working properly.
>>
>> BTW, I've just altered dlgtest on my local copy so that it doesn't return if the JAVA_HOME variable isn't defined.  Instead, it issues the current warning and continues on.  When unsetting the JAVA_HOME variable with
>>
>> export -n JAVA_HOME
>>
>> the Java demo seems to still work properly.  I think this conditional can be removed.  It isn't clear to me where/why JAVA_HOME definition is required.  I'm guessing it is interior to Octave java support somewhere and dlgtest() is assuming something about its requirement, but I keep thinking Octave should just fall back on "java" and "javac" as set up by the shell if nothing else.
>>
>> As an aside, the function "getenv" doesn't seem to make a distinction between an environment variable not being set and an environment variable set to nothing.  Both those cases result in an empty string. Is it worth making a distinction here, either returning a different result or a new routine "isenv()"?
>>
>> Dan
>
> No dialog boxes appear for me.  I assume that is a confirmation that the Java stuff doesn't work on OSX.
>
> Ben

Well, if you have Java on your system (which I assume is the case if you
do any web browsing...type "java" or "javac" at a shell command line to
confirm) then this should be a configuration issue (emphasis "should").
  Java is supposed to be a very portable environment.

Perhaps your definition of JAVA_HOME is wrong, but in my case I can set
JAVA_HOME to any valid directory and "dlgtest(0)" functions properly.

Dan
Reply | Threaded
Open this post in threaded view
|

dlgtest() no longer needs Octave package

Daniel Sebald
On 11/27/2012 05:14 PM, Daniel J Sebald wrote:

> Perhaps your definition of JAVA_HOME is wrong, but in my case I can set
> JAVA_HOME to any valid directory and "dlgtest(0)" functions properly.

dlgtest(1) is supposed to reinstall Java Octave package.  I presume that
is obsolete now:

    % Windows example paths
    if ispc()
       % NOTE: do NOT use backslashes as separator, only forward slashes!
       pkgpath = 'z:/java-1.2.8.tar.gz';
       java_home = getenv ("JAVA_HOME");
    elseif isunix()
       % Linux example paths
       pkgpath = '~/java-1.2.8.tar.gz';
       java_home = getenv ("JAVA_HOME");
    else
       pkgpath = 'unknown';
       java_home = 'unknown';
    end

Dan
Reply | Threaded
Open this post in threaded view
|

Re: dlgtest() no longer needs Octave package

Mike Miller
On Tue, Nov 27, 2012 at 05:42:13PM -0600, Daniel J Sebald wrote:
> On 11/27/2012 05:14 PM, Daniel J Sebald wrote:
>
> >Perhaps your definition of JAVA_HOME is wrong, but in my case I can set
> >JAVA_HOME to any valid directory and "dlgtest(0)" functions properly.
>
> dlgtest(1) is supposed to reinstall Java Octave package.  I presume
> that is obsolete now:

I'm catching up on all these Java developments, but I think so, yes.
That also means dlgtest has no need for JAVA_HOME.

Further, I suspect dlgtest will go away completely, its functionality
would be better expressed as proper demo blocks.

--
mike
Reply | Threaded
Open this post in threaded view
|

Re: dlgtest() no longer needs Octave package

Daniel Sebald
On 11/27/2012 06:14 PM, Mike Miller wrote:

> On Tue, Nov 27, 2012 at 05:42:13PM -0600, Daniel J Sebald wrote:
>> On 11/27/2012 05:14 PM, Daniel J Sebald wrote:
>>
>>> Perhaps your definition of JAVA_HOME is wrong, but in my case I can set
>>> JAVA_HOME to any valid directory and "dlgtest(0)" functions properly.
>>
>> dlgtest(1) is supposed to reinstall Java Octave package.  I presume
>> that is obsolete now:
>
> I'm catching up on all these Java developments, but I think so, yes.
> That also means dlgtest has no need for JAVA_HOME.

Why is that?  Please explain because I'm wondering what the roll of
JAVA_HOME is in configuration and once Octave is running.  How about the
compiled javaexac.c and javacomp.c that disable JAVA_HOME.  What's
happening there?


> Further, I suspect dlgtest will go away completely, its functionality
> would be better expressed as proper demo blocks.

Good point.

Dan
Reply | Threaded
Open this post in threaded view
|

Re: dlgtest() no longer needs Octave package

Mike Miller
On Tue, Nov 27, 2012 at 06:22:46PM -0600, Daniel J Sebald wrote:

> On 11/27/2012 06:14 PM, Mike Miller wrote:
> >On Tue, Nov 27, 2012 at 05:42:13PM -0600, Daniel J Sebald wrote:
> >>On 11/27/2012 05:14 PM, Daniel J Sebald wrote:
> >>
> >>>Perhaps your definition of JAVA_HOME is wrong, but in my case I can set
> >>>JAVA_HOME to any valid directory and "dlgtest(0)" functions properly.
> >>
> >>dlgtest(1) is supposed to reinstall Java Octave package.  I presume
> >>that is obsolete now:
> >
> >I'm catching up on all these Java developments, but I think so, yes.
> >That also means dlgtest has no need for JAVA_HOME.
>
> Why is that?  Please explain because I'm wondering what the roll of
> JAVA_HOME is in configuration and once Octave is running.  How about
> the compiled javaexac.c and javacomp.c that disable JAVA_HOME.
> What's happening there?

I don't see those files being used anywhere in the Octave build. They
are part of gnulib, but not a part that is currently used by Octave.

I do not have JAVA_HOME in my environment and Octave builds and runs
fine on my setup. I have to set it for dlgtest(0), but as you noticed,
it can be set to any directory, I set it to /tmp and the demos work just
fine for me.

--
mike
Reply | Threaded
Open this post in threaded view
|

Re: dlgtest() no longer needs Octave package

Daniel Sebald
On 11/27/2012 07:08 PM, Mike Miller wrote:

> On Tue, Nov 27, 2012 at 06:22:46PM -0600, Daniel J Sebald wrote:
>> On 11/27/2012 06:14 PM, Mike Miller wrote:
>>> On Tue, Nov 27, 2012 at 05:42:13PM -0600, Daniel J Sebald wrote:
>>>> On 11/27/2012 05:14 PM, Daniel J Sebald wrote:
>>>>
>>>>> Perhaps your definition of JAVA_HOME is wrong, but in my case I can set
>>>>> JAVA_HOME to any valid directory and "dlgtest(0)" functions properly.
>>>>
>>>> dlgtest(1) is supposed to reinstall Java Octave package.  I presume
>>>> that is obsolete now:
>>>
>>> I'm catching up on all these Java developments, but I think so, yes.
>>> That also means dlgtest has no need for JAVA_HOME.
>>
>> Why is that?  Please explain because I'm wondering what the roll of
>> JAVA_HOME is in configuration and once Octave is running.  How about
>> the compiled javaexac.c and javacomp.c that disable JAVA_HOME.
>> What's happening there?
>
> I don't see those files being used anywhere in the Octave build. They
> are part of gnulib, but not a part that is currently used by Octave.
>
> I do not have JAVA_HOME in my environment and Octave builds and runs
> fine on my setup. I have to set it for dlgtest(0), but as you noticed,
> it can be set to any directory, I set it to /tmp and the demos work just
> fine for me.

OK, thanks for clearing that up.

I did a bit of web search and JAVA_HOME is apparently some convention
for servers to find where Java is located:

http://stackoverflow.com/questions/2025290/what-is-java-home-how-does-jvm-will-find-the-javac-path-stored-in-java-home

...

Regarding some of the functions in the java package and directing to the
broader list, are the names "errordlg", "helpdlg", etc. language
standards?  If not, I wonder if their names should include "java" in
some way.  The reason I wonder is because if one launches Octave with
the new GUI/IDE then it seems to me that "errordlg", etc. would be nicer
as a Qt widget, not Java.  That way, it is the same look and feel and
uses just one software exterior.

I just tried creating some Java dialog boxes under the Octave IDE and it
crashes on my system.  Should we start entering bugs for Java in the
tracker, or wait a while?

Dan
Reply | Threaded
Open this post in threaded view
|

Re: dlgtest() no longer needs Octave package

Carnë Draug-2
On 28 November 2012 02:58, Daniel J Sebald <[hidden email]> wrote:

> Regarding some of the functions in the java package and directing to the
> broader list, are the names "errordlg", "helpdlg", etc. language standards?
> If not, I wonder if their names should include "java" in some way.  The
> reason I wonder is because if one launches Octave with the new GUI/IDE then
> it seems to me that "errordlg", etc. would be nicer as a Qt widget, not
> Java.  That way, it is the same look and feel and uses just one software
> exterior.
>
> I just tried creating some Java dialog boxes under the Octave IDE and it
> crashes on my system.  Should we start entering bugs for Java in the
> tracker, or wait a while?

You are right, this things would look better as Qt widgets, and my
understanding is that these functions are going to be rewritten that
way. There's no reason for them to be limited to use java.

Carnë
Reply | Threaded
Open this post in threaded view
|

Re: java package and MacOS

bpabbott
Administrator
In reply to this post by Daniel Sebald

On Nov 27, 2012, at 6:14 PM, Daniel J Sebald wrote:

> On 11/27/2012 04:55 PM, Ben Abbott wrote:
>>
>> On Nov 27, 2012, at 4:30 PM, Daniel J Sebald wrote:
>>
>>> On 11/27/2012 02:58 PM, Ben Abbott wrote:
>>>> On Nov 25, 2012, at 6:27 PM, Ben Abbott wrote:
>>>>
>>>>> On Nov 25, 2012, at 3:29 PM, Alexander Hansen wrote:
>>>>>
>>>>>> On 11/25/12 12:37 PM, Ben Abbott wrote:
>>>>>>> Adding the Octave Forge java package to core Octave breaks building Octave on MacOS X.
>>>>>>>
>>>>>>> http://hg.savannah.gnu.org/hgweb/octave/rev/acf0addfc610
>>>>>>>
>>>>>>> libtool: link: /opt/local/bin/g++-mp-4.5  -o dldfcn/.libs/__java__.so -bundle  dldfcn/.libs/dldfcn___java___la-__java__.o   -L/opt/local/lib ./.libs/liboctinterp.dylib -L/opt/local/libexec/llvm-3.1/lib -L/opt/local/lib/gcc45/gcc/x86_64-apple-darwin11/4.5.4 -L/opt/local/lib/gcc45/gcc/x86_64-apple-darwin11/4.5.4/../../.. -L/opt/local/lib/gcc45 /Users/bpabbott/Development/mercurial/default/sources/liboctave/.libs/liboctave.dylib -lfltk_gl -lfltk -lpthread /opt/local/lib/libhdf5.dylib /opt/local/lib/libfontconfig.dylib /opt/local/lib/libiconv.dylib /opt/local/lib/libfreetype.dylib -lz -lbz2 /opt/local/lib/libexpat.dylib /opt/local/lib/libX11.dylib /opt/local/lib/libxcb.dylib /opt/local/lib/libXau.dylib /opt/local/lib/libXdmcp.dylib -lLLVMAsmParser -lLLVMInstrumentation -lLLVMLinker -lLLVMArchive -lLLVMBitReader -lLLVMDebugInfo -lLLVMJIT -lLLVMipo -lLLVMVectorize -lLLVMBitWriter -lLLVMTableGen -lLLVMHexagonCodeGen -lLLVMHexagonAsmPrinter -lLLVMHexagonDesc -lLLVMHexagonInfo
>
>>>>>> -lLLVMPTXCodeG
>>>>>> en -lLLVMPTXDesc -lLLVMPTXInfo -lLLVMPTXAsmPrinter -lLLVMMBlazeDisassembler -lLLVMMBlazeAsmParser -lLLVMMBlazeCodeGen -lLLVMMBlazeDesc -lLLVMMBlazeInfo -lLLVMMBlazeAsmPrinter -lLLVMCppBackendCodeGen -lLLVMCppBackendInfo -lLLVMMSP430CodeGen -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMSP430AsmPrinter -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMCellSPUCodeGen -lLLVMCellSPUDesc -lLLVMCellSPUInfo -lLLVMMipsDisassembler -lLLVMMipsAsmParser -lLLVMMipsCodeGen -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMMipsAsmPrinter -lLLVMARMDisassembler -lLLVMARMAsmParser -lLLVMARMCodeGen -lLLVMARMDesc -lLLVMARMInfo -lLLVMARMAsmPrinter -lLLVMPowerPCCodeGen -lLLVMPowerPCDesc -lLLVMPowerPCAsmPrinter -lLLVMPowerPCInfo -lLLVMSparcCodeGen -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMX86AsmParser -lLLVMX86Disassembler -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCDisassembler -lLLVMMCParser -lLLVMInterpreter -lLLVMCodeGen -l!
 LL

> !
>>  VM
>>> ScalarOpts
>>>>>> -l
>>>>>> LLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMMCJIT -lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMTarget -lLLVMMC -lLLVMObject -lLLVMCore -lLLVMSupport ../liboctave/.libs/liboctave.dylib -lstdc++ -lcholmod -lmetis -lumfpack -lsuitesparseconfig -lamd -lcamd -lcolamd -lccolamd -lcxsparse /opt/local/lib/libarpack.dylib -ltatlas -lqrupdate /opt/local/lib/libfftw3.dylib /opt/local/lib/libfftw3f.dylib -llapack -lcblas -lf77blas -latlas -lreadline -lncurses /opt/local/lib/libpcre.dylib -ldl /opt/local/lib/gcc45/libgfortran.dylib -lm  -O0 -m64 -pthread -Wl,-dylib_file -Wl,/usr/fubar/lib/octave/3.7.0+/liboctave.1.dylib:/Users/bpabbott/Development/mercurial/default/sources/liboctave/.libs/liboctave.dylib   -pthread -framework AGL -framework OpenGL -framework ApplicationServices -framework Cocoa
>>>>>>> Undefined symbols for architecture x86_64:
>>>>>>> "_JNI_CreateJavaVM", referenced from:
>>>>>>>     initialize_jvm()      in dldfcn___java___la-__java__.o
>>>>>>> "_JNI_GetCreatedJavaVMs", referenced from:
>>>>>>>     initialize_jvm()      in dldfcn___java___la-__java__.o
>>>>>>> ld: symbol(s) not found for architecture x86_64
>>>>>>> collect2: ld returned 1 exit status
>>>>>>> make[3]: *** [dldfcn/__java__.la] Error 1
>>>>>>> make[2]: *** [all] Error 2
>>>>>>> make[1]: *** [all-recursive] Error 1
>>>>>>> make: *** [all] Error 2
>>>>>>>
>>>>>>> Looking at config.log, I have the follow defined.
>>>>>>>
>>>>>>> #define JAVA_ARCH ""
>>>>>>> #define JAVA_HOME ""
>>>>>>> ac_cv_prog_JAVA=java
>>>>>>> ac_cv_prog_JAVAC=javac
>>>>>>> JAVA='java'
>>>>>>> JAVAC='javac'
>>>>>>> JAVA_CPPFLAGS=''
>>>>>>> JAVA_LIBS=''
>>>>>>>
>>>>>>> Ben
>>>>>>>
>>>>>>
>>>>>> Unless I missed seeing it, I didn't notice anything referencing a Java
>>>>>> library in that linker line, so that would indeed result in missing
>>>>>> symbols. :-)
>>>>>>
>>>>>> What happens if you set JAVA_HOME before configuring, e.g. by
>>>>>>
>>>>>> export JAVA_HOME=`/usr/libexec/java_home`
>>>>>>
>>>>>> ?
>>>>>
>>>>> I haven't tried JAVA_HOME, but setting JAVA_LIBS allowed the build to complete.
>>>>>
>>>>> export JAVA_LIBS="-framework JavaVM"
>>>>>
>>>>> Maybe this should be set in configure.ac for MacOS?
>>>>>
>>>>> Ben
>>>>
>>>> Carlo's change to configure.ac works for me.
>>>>
>>>> http://octave.1599824.n4.nabble.com/changeset-for-configuring-with-Java-on-OSX-tt4647251.html
>>>>
>>>> When I try "dlgtest(0)" I get ...
>>>>
>>>> Java JDK home directory  does not exist.
>>>> Please adapt java_home in dlgtest.m.
>>>>
>>>> Setting JAVA_HOME to that used during the build gives ...
>>>>
>>>> setenv JAVA_HOME "/System/Library/Frameworks/JavaVM.framework/Home"
>>>>
>>>> Now "dlgtest(0)" results in ...
>>>>
>>>> 0 ... STOP
>>>> 1 ... listdlg tests
>>>> 2 ... errordlg tests
>>>> 3 ... warndlg tests
>>>> 4 ... helpdlg tests
>>>> 5 ... inputdlg tests
>>>> 6 ... TeX code tests
>>>> Run which test?   [0]>
>>>>
>>>> Is this the expected result?
>>>>
>>>> Ben
>>>
>>> Yes.  When you run one of those tests there should be some dialog boxes appear on the screen if Java is working properly.
>>>
>>> BTW, I've just altered dlgtest on my local copy so that it doesn't return if the JAVA_HOME variable isn't defined.  Instead, it issues the current warning and continues on.  When unsetting the JAVA_HOME variable with
>>>
>>> export -n JAVA_HOME
>>>
>>> the Java demo seems to still work properly.  I think this conditional can be removed.  It isn't clear to me where/why JAVA_HOME definition is required.  I'm guessing it is interior to Octave java support somewhere and dlgtest() is assuming something about its requirement, but I keep thinking Octave should just fall back on "java" and "javac" as set up by the shell if nothing else.
>>>
>>> As an aside, the function "getenv" doesn't seem to make a distinction between an environment variable not being set and an environment variable set to nothing.  Both those cases result in an empty string. Is it worth making a distinction here, either returning a different result or a new routine "isenv()"?
>>>
>>> Dan
>>
>> No dialog boxes appear for me.  I assume that is a confirmation that the Java stuff doesn't work on OSX.
>>
>> Ben
>
> Well, if you have Java on your system (which I assume is the case if you do any web browsing...type "java" or "javac" at a shell command line to confirm) then this should be a configuration issue (emphasis "should").  Java is supposed to be a very portable environment.
>
> Perhaps your definition of JAVA_HOME is wrong, but in my case I can set JAVA_HOME to any valid directory and "dlgtest(0)" functions properly.
>
> Dan

MacOS X has Java.  If I understand the problem correctly ,.. the problem is that for MacOS X, the GUI loop must be in the main program thread.  What I'm not sure of is if the GUI loop  can support both a Qt and Java (I suspect it can not, but don't know).

Ben


Reply | Threaded
Open this post in threaded view
|

Re: java package and MacOS

Daniel Sebald
On 11/27/2012 08:45 PM, Ben Abbott wrote:
>
> On Nov 27, 2012, at 6:14 PM, Daniel J Sebald wrote:
[snip]
>> Well, if you have Java on your system (which I assume is the case if you do any web browsing...type "java" or "javac" at a shell command line to confirm) then this should be a configuration issue (emphasis "should").  Java is supposed to be a very portable environment.
>>
>> Perhaps your definition of JAVA_HOME is wrong, but in my case I can set JAVA_HOME to any valid directory and "dlgtest(0)" functions properly.
>>
>> Dan
>
> MacOS X has Java.  If I understand the problem correctly ,.. the problem is that for MacOS X, the GUI loop must be in the main program thread.  What I'm not sure of is if the GUI loop  can support both a Qt and Java (I suspect it can not, but don't know).

Oh, you are running Octave as its GUI?  I think several of us have been
running with the --no-gui option.

I just found out a little while ago that running these Java commands
while inside the GUI doesn't work.  Nothing happens or it crashes.

Dan
Reply | Threaded
Open this post in threaded view
|

Re: dlgtest() no longer needs Octave package

Daniel Sebald
In reply to this post by Carnë Draug-2
On 11/27/2012 08:07 PM, Carnë Draug wrote:

> On 28 November 2012 02:58, Daniel J Sebald<[hidden email]>  wrote:
>> Regarding some of the functions in the java package and directing to the
>> broader list, are the names "errordlg", "helpdlg", etc. language standards?
>> If not, I wonder if their names should include "java" in some way.  The
>> reason I wonder is because if one launches Octave with the new GUI/IDE then
>> it seems to me that "errordlg", etc. would be nicer as a Qt widget, not
>> Java.  That way, it is the same look and feel and uses just one software
>> exterior.
>>
>> I just tried creating some Java dialog boxes under the Octave IDE and it
>> crashes on my system.  Should we start entering bugs for Java in the
>> tracker, or wait a while?
>
> You are right, this things would look better as Qt widgets, and my
> understanding is that these functions are going to be rewritten that
> way. There's no reason for them to be limited to use java.
>
> Carnë

It's probably not too difficult to create those dialog widgets if
written as internal routines; at least not the modal version.  Qt has a
number of similar routines, and they do handle non-modal as well as
modal versions.  But to do non-modal requires some organization in
Octave core for assigning callback routines, etc., i.e., something
similar to what was done with figures.

Dan
Reply | Threaded
Open this post in threaded view
|

Re: java package and MacOS

bpabbott
Administrator
In reply to this post by Daniel Sebald

On Nov 27, 2012, at 10:01 PM, Daniel J Sebald wrote:

> On 11/27/2012 08:45 PM, Ben Abbott wrote:
>>
>> On Nov 27, 2012, at 6:14 PM, Daniel J Sebald wrote:
> [snip]
>>> Well, if you have Java on your system (which I assume is the case if you do any web browsing...type "java" or "javac" at a shell command line to confirm) then this should be a configuration issue (emphasis "should").  Java is supposed to be a very portable environment.
>>>
>>> Perhaps your definition of JAVA_HOME is wrong, but in my case I can set JAVA_HOME to any valid directory and "dlgtest(0)" functions properly.
>>>
>>> Dan
>>
>> MacOS X has Java.  If I understand the problem correctly ,.. the problem is that for MacOS X, the GUI loop must be in the main program thread.  What I'm not sure of is if the GUI loop  can support both a Qt and Java (I suspect it can not, but don't know).
>
> Oh, you are running Octave as its GUI?  I think several of us have been running with the --no-gui option.
>
> I just found out a little while ago that running these Java commands while inside the GUI doesn't work.  Nothing happens or it crashes.
>
> Dan

No.  The gui does not work yet on MacOS X.

The problem with Qt is not the same as the problem for Java.  For the Qt GUI, the main thread includes the GUI loop (at least that is my understanding).  The problem for the gui on MacOS X has to do with forking.  I get the error below.

The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.

The problem with Java is that the GUI loop is not the main thread, but MacOS requires that the first thread spawned  be the main()/GUI thread (I'm not an expert in how Cocoa works, and am only repeating what I've read here and else were).

Ben

Reply | Threaded
Open this post in threaded view
|

Re: java package and MacOS

Michael Goffioul
On Tue, Nov 27, 2012 at 10:18 PM, Ben Abbott <[hidden email]> wrote:

On Nov 27, 2012, at 10:01 PM, Daniel J Sebald wrote:

> On 11/27/2012 08:45 PM, Ben Abbott wrote:
>>
>> On Nov 27, 2012, at 6:14 PM, Daniel J Sebald wrote:
> [snip]
>>> Well, if you have Java on your system (which I assume is the case if you do any web browsing...type "java" or "javac" at a shell command line to confirm) then this should be a configuration issue (emphasis "should").  Java is supposed to be a very portable environment.
>>>
>>> Perhaps your definition of JAVA_HOME is wrong, but in my case I can set JAVA_HOME to any valid directory and "dlgtest(0)" functions properly.
>>>
>>> Dan
>>
>> MacOS X has Java.  If I understand the problem correctly ,.. the problem is that for MacOS X, the GUI loop must be in the main program thread.  What I'm not sure of is if the GUI loop  can support both a Qt and Java (I suspect it can not, but don't know).
>
> Oh, you are running Octave as its GUI?  I think several of us have been running with the --no-gui option.
>
> I just found out a little while ago that running these Java commands while inside the GUI doesn't work.  Nothing happens or it crashes.
>
> Dan

No.  The gui does not work yet on MacOS X.

The problem with Qt is not the same as the problem for Java.  For the Qt GUI, the main thread includes the GUI loop (at least that is my understanding).  The problem for the gui on MacOS X has to do with forking.  I get the error below.

The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.

The problem with Java is that the GUI loop is not the main thread, but MacOS requires that the first thread spawned  be the main()/GUI thread (I'm not an expert in how Cocoa works, and am only repeating what I've read here and else were).

There you obviously have a problem, you can't have Qt and Java running their own GUI loop in the main thread (at least not in a trivial way).

Michael.

Reply | Threaded
Open this post in threaded view
|

Re: dlgtest() no longer needs Octave package

Michael Goffioul
In reply to this post by Daniel Sebald
On Tue, Nov 27, 2012 at 10:11 PM, Daniel J Sebald <[hidden email]> wrote:
On 11/27/2012 08:07 PM, Carnė Draug wrote:
On 28 November 2012 02:58, Daniel J Sebald<[hidden email]>  wrote:
Regarding some of the functions in the java package and directing to the
broader list, are the names "errordlg", "helpdlg", etc. language standards?
If not, I wonder if their names should include "java" in some way.  The
reason I wonder is because if one launches Octave with the new GUI/IDE then
it seems to me that "errordlg", etc. would be nicer as a Qt widget, not
Java.  That way, it is the same look and feel and uses just one software
exterior.

I just tried creating some Java dialog boxes under the Octave IDE and it
crashes on my system.  Should we start entering bugs for Java in the
tracker, or wait a while?

You are right, this things would look better as Qt widgets, and my
understanding is that these functions are going to be rewritten that
way. There's no reason for them to be limited to use java.

Carnė

It's probably not too difficult to create those dialog widgets if written as internal routines; at least not the modal version.  Qt has a number of similar routines, and they do handle non-modal as well as modal versions.  But to do non-modal requires some organization in Octave core for assigning callback routines, etc., i.e., something similar to what was done with figures.

A longer term solution would be to implement those simple dialogs using the uiXXX functions.

Michael.
 
Reply | Threaded
Open this post in threaded view
|

Re: java package and MacOS

bpabbott
Administrator
In reply to this post by bpabbott

On Nov 27, 2012, at 10:18 PM, Ben Abbott wrote:

>
> On Nov 27, 2012, at 10:01 PM, Daniel J Sebald wrote:
>
>> On 11/27/2012 08:45 PM, Ben Abbott wrote:
>>>
>>> On Nov 27, 2012, at 6:14 PM, Daniel J Sebald wrote:
>> [snip]
>>>> Well, if you have Java on your system (which I assume is the case if you do any web browsing...type "java" or "javac" at a shell command line to confirm) then this should be a configuration issue (emphasis "should").  Java is supposed to be a very portable environment.
>>>>
>>>> Perhaps your definition of JAVA_HOME is wrong, but in my case I can set JAVA_HOME to any valid directory and "dlgtest(0)" functions properly.
>>>>
>>>> Dan
>>>
>>> MacOS X has Java.  If I understand the problem correctly ,.. the problem is that for MacOS X, the GUI loop must be in the main program thread.  What I'm not sure of is if the GUI loop  can support both a Qt and Java (I suspect it can not, but don't know).
>>
>> Oh, you are running Octave as its GUI?  I think several of us have been running with the --no-gui option.
>>
>> I just found out a little while ago that running these Java commands while inside the GUI doesn't work.  Nothing happens or it crashes.
>>
>> Dan
>
> No.  The gui does not work yet on MacOS X.
>
> The problem with Qt is not the same as the problem for Java.  For the Qt GUI, the main thread includes the GUI loop (at least that is my understanding).  The problem for the gui on MacOS X has to do with forking.  I get the error below.
>
> The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
> Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.
>
> The problem with Java is that the GUI loop is not the main thread, but MacOS requires that the first thread spawned  be the main()/GUI thread (I'm not an expert in how Cocoa works, and am only repeating what I've read here and else were).
>
> Ben

After some time browsing and googling, I came across the discussion below.

        http://www.cocoabuilder.com/archive/cocoa/315103-why-is-the-threading-and-ui-updating-designed-to-be-done-only-on-main-thread.html

[Q] Why is the threading and UI updating designed to be done only on a main thread?


Ben



12