Opened 4 years ago

Closed 3 months ago

#254 closed defect (migrated)

Problems compiling jipopt on Windows 64bit

Reported by: RotateMe Owned by: ipopt-team
Priority: normal Component: Ipopt
Version: 3.11 Severity: normal
Keywords: jipopt 64 Cc:

Description

When compiling Ipopt and then the Java Interface I ran into the following problems:

  • As stated in Tickets #240 and #241 the types jint and jlong cause problems in some enviroments (since jint is initialized as a long in the jni_md.h of the latest windows jdks), and the file jipopt.cpp still contains a line where a jint* is initialized as an int* which still needs to be fixed.
  • Moreover (I don't know if this is only a problem with the latest jdk versions), the header file jni_md.h defines the type jlong as an _int64 which causes a compilation error using cygwin and gcc. This can be circumvented by manually adding "#include <inttypes.h>" and replacing _int64 by int64_t.

Having corrected this, the make produces no errors, but several warnings (since longs are converted to ints). One can get rid of these by replacing the typedef for jint by an int, however the problem below occurs in any case.

The output produced are the correct class files and the jipopt.dll, which was in my case named jipopt.dll.exe and I had to rename it.

However, after running "make test", I immediately get the following output and error:

0 [main] java 3272 sig_send: error sending signal 6, pid 3272, pipe handle 0x0, nb 0, packsize 176, Win32 error 6

The number after pid is always different and sometimes, but not always, this error is followed by either a long pause, or a Java Runtime Enviroment crashdump (which I will attach).

I found scarce information on errors like this related to cygwin, but neither the latest cygwin snapshots, nor deactivating anti-virus, nor switching machines worked.

As a minor note, maybe it would be nice to add a little reminder in the jipopt compilation instructions that (at least in Windows) you have to point your jdk to the path of the classes produced by the make, i.e. "export CLASSPATH = $IPOPTDIR/build/Ipopt/contrib/JavaInterface". This might be clear to many, but it took me some time to realize I don't have to change the Makefile to achieve this.

Attachments (1)

hs_err_pid3272.log (12.4 KB) - added by RotateMe 4 years ago.
CrashDump? of the JNI

Download all attachments as: .zip

Change History (4)

Changed 4 years ago by RotateMe

CrashDump? of the JNI

comment:1 in reply to: ↑ description ; follow-up: Changed 4 years ago by stefan

Replying to RotateMe:

When compiling Ipopt and then the Java Interface I ran into the following problems:

  • As stated in Tickets #240 and #241 the types jint and jlong cause problems in some enviroments (since jint is initialized as a long in the jni_md.h of the latest windows jdks), and the file jipopt.cpp still contains a line where a jint* is initialized as an int* which still needs to be fixed.

I had committed a fix to jipopt.cpp in r2513 3 weeks ago and now merged it to stable/3.11. Is this the one you refer to? Otherwise, please be more specific about the "line where a jint* is initialized as an int*".

  • Moreover (I don't know if this is only a problem with the latest jdk versions), the header file jni_md.h defines the type jlong as an _int64 which causes a compilation error using cygwin and gcc. This can be circumvented by manually adding "#include <inttypes.h>" and replacing _int64 by int64_t.

Sounds like a bug in the JNI headers to me. They should include the headers needed.

Having corrected this, the make produces no errors, but several warnings (since longs are converted to ints). One can get rid of these by replacing the typedef for jint by an int, however the problem below occurs in any case.

I don't think that replacing the typedef for jint is a good idea. If the warnings are only in code that isn't executed anyway (i.e., in a if(sizeof(jint)==sizeof(int)) block), then better ignore these warnings.

The output produced are the correct class files and the jipopt.dll, which was in my case named jipopt.dll.exe and I had to rename it.

However, after running "make test", I immediately get the following output and error:

0 [main] java 3272 sig_send: error sending signal 6, pid 3272, pipe handle 0x0, nb 0, packsize 176, Win32 error 6

The number after pid is always different and sometimes, but not always, this error is followed by either a long pause, or a Java Runtime Enviroment crashdump (which I will attach).

I found scarce information on errors like this related to cygwin, but neither the latest cygwin snapshots, nor deactivating anti-virus, nor switching machines worked.

The log doesn't tell me much. Try without modifying the typedef of jint.

As a minor note, maybe it would be nice to add a little reminder in the jipopt compilation instructions that (at least in Windows) you have to point your jdk to the path of the classes produced by the make, i.e. "export CLASSPATH = $IPOPTDIR/build/Ipopt/contrib/JavaInterface". This might be clear to many, but it took me some time to realize I don't have to change the Makefile to achieve this.

Will do.

Last edited 4 years ago by stefan (previous) (diff)

comment:2 in reply to: ↑ 1 Changed 4 years ago by RotateMe

Replying to stefan:

I had committed a fix to jipopt.cpp in r2513 3 weeks ago and now merged it to stable/3.11. Is this the one you refer to? Otherwise, please be more specific about the "line where a jint* is initialized as an int*".

Yes, this is exactly the line, sorry.

Sounds like a bug in the JNI headers to me. They should include the headers needed.

Maybe I wasn't clear enough, it's GCC that doesn't know the type _int64, so when using GCC to compile the JNI you need to include inttypes.h and use a different but equivalent type.

I don't think that replacing the typedef for jint is a good idea. If the warnings are only in code that isn't executed anyway (i.e., in a if (sizeof(jint)==sizeof(int)) block, then better ignore these warnings.

The log doesn't tell me much. Try without modifying the typedef of jint.

I tried it both ways (only fixing the problem with _int64 and replacing the typedefs altogether), the error was exactly the same, which is why I suspect it's not the cause for this problem.

comment:3 Changed 3 months ago by stefan

  • Resolution set to migrated
  • Status changed from new to closed

This ticket has been migrated to GitHub and will be followed up there: https://github.com/coin-or/Ipopt/issues/254

Note: See TracTickets for help on using tickets.