Attempting OpenJDK 7 build on Mavericks

[Scott Duensing]

After reading, poking around, and trying various things, this is as close as I can get.  It results in the following:

make: *** No rule to make target `/Users/scott/source/avian/avian-1.0.2/../openjdk-1.7.0-u60-unofficial-macosx-x86_64-src/share/native/common/check_code.c', needed by `build/darwin-x86_64-lzma-openjdk-src/openjdk/share/native/common/check_code-openjdk.o'.  Stop.

I've scripted my build to make this easy to reproduce.  I've also tried using avian-master (which results in a host of other problems).

Any ideas?   Thanks!

Scott

(Ok, so for some reason, I can't attach the script.  I apologize for the below paste.)

#!/bin/bash

AVIAN=1.0.2

OPENJDK=openjdk-1.7.0-u60-unofficial-macosx-x86_64

LZMA=920

[[ ! -e v${AVIAN}.zip ]] && wget https://github.com/ReadyTalk/avian/archive/v${AVIAN}.zip

[[ ! -e ${OPENJDK}-image.zip ]] && wget https://bitbucket.org/alexkasko/openjdk-unofficial-builds/downloads/${OPENJDK}-image.zip

[[ ! -e lzma${LZMA}.tar.bz2 ]] && wget wget http://downloads.sourceforge.net/sourceforge/sevenzip/lzma${LZMA}.tar.bz2

[[ ! -d avian-${AVIAN} ]] && unzip v${AVIAN}.zip

[[ ! -d ${OPENJDK}-image ]] && unzip ${OPENJDK}-image.zip

if [[ ! -d ${OPENJDK}-src ]]; then

mkdir ${OPENJDK}-src

pushd ${OPENJDK}-src

unzip ../${OPENJDK}-image/src.zip

popd

fi

if [[ ! -d lzma${LZMA} ]]; then

mkdir lzma${LZMA}

pushd lzma${LZMA}

tar xjf ../lzma${LZMA}.tar.bz2

popd

fi

pushd avian-${AVIAN}

export JAVA_HOME=$(/usr/libexec/java_home -v 1.7)

make clean

make use-clang=true lzma=$(pwd)/../lzma${LZMA} openjdk=$(pwd)/../${OPENJDK}-image openjdk-src=$(pwd)/../${OPENJDK}-src test

popd

[Joshua Warner]

On 13 July 2014 21:35, Scott Duensing <scott.d...@gmail.com> wrote:

make use-clang=true lzma=$(pwd)/../lzma${LZMA} openjdk=$(pwd)/../${OPENJDK}-image openjdk-src=$(pwd)/../${OPENJDK}-src

I looks like your problem is where you set the openjdk-src directory.  This needs to be the native code source, not just the java classpath source (which is typically all that's in the src.zip).  You'll have to download the source bundles linked from the unofficial-builds github page.

Also note that the openjdk-src variable needs to point at ${extracted_openjdk_source_dir}/jdk/src, not at just ${extracted_openjdk_source_dir}.

Hope this helps.

I'd also be interested in hearing about the problems you're seeing on master.

-Joshua

[Scott Duensing]

Thank you!  That got me farther along.  Now I run into the following...

Using avian-master (first error of many):

compiling build/macosx-x86_64-lzma-openjdk-src/classpath-openjdk.o

src/classpath-openjdk.cpp:824:41: error: no member named 'ClassLoaderType' in 'vm::Machine'; did you mean

      'vm::Gc::ClassLoaderType'?

    return (caller->class_() == type(t, Machine::ClassLoaderType)

                                        ^~~~~~~~~~~~~~~~~~~~~~~~

                                        vm::Gc::ClassLoaderType

Using avian-v1.0.2 (again, first of many):

patching file openjdk/java_props_macosx.c

Hunk #1 succeeded at 38 (offset 1 line).

In file included from build/darwin-x86_64-lzma-openjdk-src/openjdk/java_props_macosx.c:34:

In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:8:

/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:371:1: error: expected identifier or '('

@class NSString, Protocol;

^

Scott

[Joshua Warner]

Whoops!

Oversight in my recent refactor. Here, at least, is a fix for the large number of errors you were seeing on master: https://github.com/ReadyTalk/avian/pull/296

I don't think that'll help with the other errors, though.

-Joshua

--

You received this message because you are subscribed to the Google Groups "Avian" group.
To unsubscribe from this group and stop receiving emails from it, send an email to avian+un...@googlegroups.com.
To post to this group, send email to av...@googlegroups.com.
Visit this group at http://groups.google.com/group/avian.
For more options, visit https://groups.google.com/d/optout.

[Scott Duensing]

Closer!  Using the tree from https://github.com/ReadyTalk/avian/tree/4b7b3d2680ca7091435f697b4f220e611471a039 I get a lot farther.  But still:

compiling build/macosx-x86_64-lzma-openjdk-src/openjdk/solaris/native/java/io/UnixFileSystem_md-openjdk.o

build/macosx-x86_64-lzma-openjdk-src/openjdk/UnixFileSystem_md.c:293:18: error: invalid application of 'sizeof' to an incomplete

      type 'struct dirent64'

    ptr = malloc(sizeof(struct dirent64) + (PATH_MAX + 1));

                 ^     ~~~~~~~~~~~~~~~~~

And then more.  My latest build script attached.  Going to try on Linux as well.

Scott

[Scott Duensing]

Modified my script to also run on Ubuntu.  Worked perfectly there.  New script attached.

Scott

[Joel Dice]

Yeah, it looks to me like some of the OpenJDK .c files won't build on
recent versions of Xcode and the MacOS SDK, which isn't surprising since
even OpenJDK 8 can't be built with an Xcode more recent than 4.5.2. You
might want to install an older Xcode or else try to patch the problematic
files to work with a modern Xcode.

[Scott Duensing]

Thank you for the information.  I'll pull the 4.5.2 release and see what I can do with that.

[Scott Duensing]

Well, poo.  Xcode 4.5.2 chokes in the same place as 5.1.1.  Might be moving this project to Linux for now.  :-/

Scott

On Wednesday, July 16, 2014 2:36:02 PM UTC-5, Joel Dice wrote:

[Scott Duensing]

After digging through the make files for Avian, I may have found something...

In openjdk-src.mk (line 168 in my copy), there are some openjdk-cflags being set for the platform "darwin".  However, if you un-silence the main makefile and look at the compiler command line, these flags are not being set.  Hacking them into the source allows the build to proceed a bit farther but I'm wondering where in the makefile it's going sideways?

Scott

[Joel Dice]

On Thu, 17 Jul 2014, Scott Duensing wrote:

> After digging through the make files for Avian, I may have found
> something...
>
> In openjdk-src.mk (line 168 in my copy), there are some openjdk-cflags
> being set for the platform "darwin". However, if you un-silence the main
> makefile and look at the compiler command line, these flags are not being
> set. Hacking them into the source allows the build to proceed a bit
> farther but I'm wondering where in the makefile it's going sideways?

Does this help?

https://github.com/ReadyTalk/avian/pull/303

(be sure to do a "make clean" before re-running the build)

[benjami...@googlemail.com]

Stops after some time here:

compiling build/ios-i386-bootimage-openjdk-src/openjdk/solaris/native/java/lang/java_props_macosx-openjdk.o

patching file openjdk/java_props_macosx.c

Reversed (or previously applied) patch detected!  Assume -R? [n] y

Hunk #1 succeeded at 38 (offset 1 line).

build/ios-i386-bootimage-openjdk-src/openjdk/java_props_macosx.c:31:10: fatal error: 

      'Security/AuthSession.h' file not found

#include <Security/AuthSession.h>

         ^

1 error generated.

make[1]: *** [build/ios-i386-bootimage-openjdk-src/openjdk/solaris/native/java/lang/java_props_macosx-openjdk.o] Error 1

make: *** [make-vm] Error 2

Ben

[benjami...@googlemail.com]

I forgot to say x86_64 works for me, just iOS fails.

Ben

[Joel Dice]

On Tue, 22 Jul 2014, benjami...@googlemail.com wrote:

> Stops after some time here:
>
> compiling
> build/ios-i386-bootimage-openjdk-src/openjdk/solaris/native/java/lang/java_props_macosx-openjdk.o
>
> patching file openjdk/java_props_macosx.c
>
> Reversed (or previously applied) patch detected! Assume -R? [n] y
>
> Hunk #1 succeeded at 38 (offset 1 line).
>

> *build/ios-i386-bootimage-openjdk-src/openjdk/java_props_macosx.c:31:10: **fatal
> error: *
>
> * 'Security/AuthSession.h' file not found*
>
> #include <Security/AuthSession.h>
>
> * ^*

>
> 1 error generated.
>
> make[1]: ***
> [build/ios-i386-bootimage-openjdk-src/openjdk/solaris/native/java/lang/java_props_macosx-openjdk.o]
> Error 1
>
> make: *** [make-vm] Error 2

Thanks for pointing that out. Try
https://github.com/ReadyTalk/avian/pull/304.

Now I'm getting a failure when creating the boot image in the hello-ios
example; I'll look at that next.

[benjami...@googlemail.com]

Works!

Ben

[Joel Dice]

On Tue, 22 Jul 2014, Joel Dice wrote:

> Thanks for pointing that out. Try
> https://github.com/ReadyTalk/avian/pull/304.
>
> Now I'm getting a failure when creating the boot image in the hello-ios
> example; I'll look at that next.

Josh, when I try to build hello-ios using openjdk-src for ARM, I get a
crash due to an assertion failure at
https://github.com/ReadyTalk/avian/blob/master/src/codegen/compiler.cpp#L1222.
Any chance your recent refactoring might have something to do with it?

[Joshua Warner]

Josh, when I try to build hello-ios using openjdk-src for ARM, I get a crash due to an assertion failure at https://github.com/ReadyTalk/avian/blob/master/src/codegen/compiler.cpp#L1222. Any chance your recent refactoring might have something to do with it?

It's certainly the most likely candidate.  However, I can't reproduce that with either a "make platform=ios bootimage=true arch=arm" in avian or a "make" in hello-ios.  Both builds complete successfully.

-Joshua

[Joel Dice]

Are you using openjdk= and openjdk-src= options? That's how I'm
reproducing it.

[benjami...@googlemail.com]

Hello-ios is working for me without OpenJDK. With OpenJDK I get an error while creating the boot image:

bootimage-generator -cp build/stage2 -bootimage build/bootimage-bin.o \

-codeimage build/codeimage-bin.o

make: *** [build/bootimage-bin.o] Abort trap: 6

make: *** Deleting file `build/bootimage-bin.o'

It's maybe unrelated. But what is this caused by?

Starting server on 127.0.0.1:80

java/lang/NoSuchMethodError: getDefault ()Ljava/util/TimeZone; not found in java/util/TimeZone

  at org/eclipse/jetty/util/DateCache.<init> (line 88)

  at org/eclipse/jetty/util/log/StdErrLog.<clinit> (line 68)

  at org/eclipse/jetty/util/log/Log.initStandardLogging (line 185)

  at org/eclipse/jetty/util/log/Log.initialized (line 168)

  at org/eclipse/jetty/util/log/Log.getLogger (line 435)

  at org/eclipse/jetty/util/log/Log.getLogger (line 425)

  at org/eclipse/jetty/util/component/AbstractLifeCycle.<clinit> (line 33)

  at Hello.startServer (line 43)

  at Hello.<init> (line 29)

Ben

[Joshua Warner]

Are you using openjdk= and openjdk-src= options?  That's how I'm reproducing it.

*Facepalm*

Yep, looking into it. 

I'm having build trouble using the latest 7u60 builds and sources from https://github.com/alexkasko/openjdk-unofficial-builds:

In file included from build/ios-arm-bootimage-openjdk-src/openjdk/childproc.c:34:

/Users/joshua.warner/Code/avian/../openjdk/7/src/solaris/native/java/lang/childproc.h:32:10: fatal error: 'crt_externs.h' file not found

#include <crt_externs.h>

         ^

1 error generated.

make: *** [build/ios-arm-bootimage-openjdk-src/openjdk/solaris/native/java/lang/childproc-openjdk.o] Error 1

›~/C/avian 2↵ ╼ locate crt_externs.h

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk/usr/include/crt_externs.h

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/include/crt_externs.h

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/crt_externs.h

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.1.sdk/usr/include/crt_externs.h

/usr/include/crt_externs.h

[Joel Dice]

On Tue, 22 Jul 2014, Joshua Warner wrote:

> I'm having build trouble using the latest 7u60 builds and sources from
> https://github.com/alexkasko/openjdk-unofficial-builds:

Might want to stick with the 7u40 one -- that's what I'm using.

[benjami...@googlemail.com]

I'm using the latest jdk7u hg sources, in combination with an image from https://github.com/alexkasko/openjdk-unofficial-builds.

So something like:

- JAVA_HOME is set to "ALEXKASKO/openjdk-1.7.0-u60-unofficial-macosx-x86_64-debug-bundle/jdk1.7.0.jdk/Contents/Home 

- make openjdk-src="LatestOpenJDK7/jdk7u/jdk/src" openjdk="ALEXKASKO/openjdk-1.7.0-u60-unofficial-macosx-x86_64-debug-image"

I spent lots of time trying to compile OpenJDK 7 (which I had working once). After the many weird things I had to do (e.g. lipo going to endless loop, manually copied another lipo version which worked) I decided it is a bad idea to spoil my development machine. 

Will this have any side effects? I have no real project to test this setup. just seems to compile without trouble so far.

Ben

[Joel Dice]

On Tue, 22 Jul 2014, benjami...@googlemail.com wrote:

> I'm using the latest jdk7u hg sources, in combination with an image
> from https://github.com/alexkasko/openjdk-unofficial-builds.
>
> So something like:
> - JAVA_HOME is set to
> "ALEXKASKO/openjdk-1.7.0-u60-unofficial-macosx-x86_64-debug-bundle/jdk1.7.0.jdk/Contents/Home
> - make openjdk-src="LatestOpenJDK7/jdk7u/jdk/src"
> openjdk="ALEXKASKO/openjdk-1.7.0-u60-unofficial-macosx-x86_64-debug-image"
>
> I spent lots of time trying to compile OpenJDK 7 (which I had working
> once). After the many weird things I had to do (e.g. lipo going to endless
> loop, manually copied another lipo version which worked) I decided it is a
> bad idea to spoil my development machine.
>
> Will this have any side effects? I have no real project to test this setup.
> just seems to compile without trouble so far.

No side effects that I know of. In theory any version should work, but
there are so many possible compiler/JDK/SDK/Xcode combinations that I'm
sure some will work and some won't.

[benjami...@googlemail.com]

Good to know. This works best for me at the moment, since I can keep Xcode 5 + default command line tools. Trying to compile it with previous versions of Xcode on 10.9.4 (and I also tried various llvm-gcc 4.2 from brew) resulted in one error after another. 

[Scott Duensing]

Beautiful!  Built and mostly passed all the tests.  I got a "Processes: fail" but otherwise, it all seems quite happy.  The log says:

java/lang/RuntimeException: java.io.IOException: Cannot run program "sleep": error=0, spawn failed

  at Processes.main (line 28)

caused by: java/io/IOException: Cannot run program "sleep": error=0, spawn failed

  at java/lang/ProcessBuilder.start (line 1041)

  at java/lang/Runtime.exec (line 617)

  at java/lang/Runtime.exec (line 450)

  at java/lang/Runtime.exec (line 347)

  at Processes.main (line 7)

caused by: java/io/IOException: error=0, spawn failed

  at java/lang/UNIXProcess.forkAndExec (native)

  at java/lang/UNIXProcess.<init> (line 184)

  at java/lang/ProcessImpl.start (line 130)

  at java/lang/ProcessBuilder.start (line 1022)

  at java/lang/Runtime.exec (line 617)

  at java/lang/Runtime.exec (line 450)

  at java/lang/Runtime.exec (line 347)

  at Processes.main (line 7)

I looked in Processes.java and ran the 'sleep 10' from a prompt by hand.  Worked fine.  Not sure why Avian couldn't start it.

[Joel Dice]

On Tue, 22 Jul 2014, Scott Duensing wrote:

> Beautiful! Built and mostly passed all the tests. I got a "Processes:
> fail" but otherwise, it all seems quite happy. The log says:
>
> java/lang/RuntimeException: java.io.IOException: Cannot run program
> "sleep": error=0, spawn failed
> at Processes.main (line 28)
> caused by: java/io/IOException: Cannot run program "sleep": error=0, spawn
> failed
> at java/lang/ProcessBuilder.start (line 1041)
> at java/lang/Runtime.exec (line 617)
> at java/lang/Runtime.exec (line 450)
> at java/lang/Runtime.exec (line 347)
> at Processes.main (line 7)
> caused by: java/io/IOException: error=0, spawn failed
> at java/lang/UNIXProcess.forkAndExec (native)
> at java/lang/UNIXProcess.<init> (line 184)
> at java/lang/ProcessImpl.start (line 130)
> at java/lang/ProcessBuilder.start (line 1022)
> at java/lang/Runtime.exec (line 617)
> at java/lang/Runtime.exec (line 450)
> at java/lang/Runtime.exec (line 347)
> at Processes.main (line 7)
>
> I looked in Processes.java and ran the 'sleep 10' from a prompt by hand.
> Worked fine. Not sure why Avian couldn't start it.

All tests are passing for me; I don't know what the difference is. What
version of OpenJDK are you using?

[Scott Duensing]

I've got openjdk-1.7.0-u60-unofficial-macosx-x86_64-image from https://bitbucket.org/alexkasko/openjdk-unofficial-builds along with the source from http://hg.openjdk.java.net/jdk7u/jdk7u60.  I was never able to build it myself.

[Joshua Warner]

Joel,

With the attached patch the arm bootimage openjdk-src build gets farther, but fails in an area I'm not super familiar with:

frame #7: 0x00000001000d5aa5 bootimage-generator`avian::codegen::arm::resolve(b=0x0000000109cd6dd8) + 373 at operations.cpp:253

   250          = (b->start + b->size - 8)

   251            - (con->poolOffsetHead->offset + con->poolOffsetHead->block->start);

   252

-> 253      expect(con, v == (v & PoolOffsetMask));

   254 #endif  // not NDEBUG

   255

   256      appendPoolEvent(

(lldb) p v

(int32_t) $0 = 10036

(lldb) p v & PoolOffsetMask

error: use of undeclared identifier 'PoolOffsetMask'

error: 1 errors parsing expression

(lldb) p v & 0xfff

(int) $1 = 1844

Any ideas?

-Joshua

--

[Joel Dice]

On Tue, 22 Jul 2014, Joshua Warner wrote:

> Joel,
>
> With the attached patch the arm bootimage openjdk-src build gets farther,
> but fails in an area I'm not super familiar with:
>
> frame #7: 0x00000001000d5aa5
> bootimage-generator`avian::codegen::arm::resolve(b=0x0000000109cd6dd8) +
> 373 at operations.cpp:253
> 250 = (b->start + b->size - 8)
> 251 - (con->poolOffsetHead->offset +
> con->poolOffsetHead->block->start);
> 252
> -> 253 expect(con, v == (v & PoolOffsetMask));
> 254 #endif // not NDEBUG
> 255
> 256 appendPoolEvent(
> (lldb) p v
> (int32_t) $0 = 10036
> (lldb) p v & PoolOffsetMask
> error: use of undeclared identifier 'PoolOffsetMask'
> error: 1 errors parsing expression
> (lldb) p v & 0xfff
> (int) $1 = 1844
>
> Any ideas?

That patch fixed it for me when I did a clean build (although there was a
huge amount of debug output). I don't have an iOS device available to
test with at the moment, but the build ran to completion.

[Joshua Warner]

Are you running in debug mode?  The expect is only enabled there.  Just to be sure, I did a clean (debug) build and reproduced the new problem.

Either way, I'll work up a PR with a cleaned-up version of that.

-Joshua

[Joshua Warner]

Are you running in debug mode?  The expect is only enabled there.  Just to be sure, I did a clean (debug) build and reproduced the new problem.

Joel and I figured out this is only a problem with an unproguarded build, which will be a very unusual use case.  I filed a (low-priority) issue here: https://github.com/ReadyTalk/avian/issues/305

 

Either way, I'll work up a PR with a cleaned-up version of that.

Done: https://github.com/ReadyTalk/avian/pull/306

-Joshua

[Joel Dice]

On Tue, 22 Jul 2014, Scott Duensing wrote:

> I've got openjdk-1.7.0-u60-unofficial-macosx-x86_64-image
> from https://bitbucket.org/alexkasko/openjdk-unofficial-builds along with
> the source from http://hg.openjdk.java.net/jdk7u/jdk7u60. I was never able
> to build it myself.

Looks like UNIXProcess_md.c was rewritten between jdk7u40 and jdk7u60; it
uses posix_spawn instead of (v)fork. Not sure why it doesn't work with
Avian's openjdk-src build. It does work with the openjdk (i.e. no
openjdk-src) build. I'll take closer look later, but if you need that
functionality you might want to switch to jdk7u40 (also available in
prebuilt form from openjdk-unofficial-builds).

[Scott Duensing]

Thanks, Joel.  I can live without it.  Just thought I'd provide the log to help further Avian.  Fantastic program.  :-)

[benjami...@googlemail.com]

Joel, I saw your latest property commit. Here is another one missing:

Undefined symbols for architecture i386:

  "_setUserHome", referenced from:

      _GetJavaProperties in build_ios-i386-bootimage-openjdk-src_openjdk_solaris_native_java_lang_java_props_md-openjdk.o

ld: symbol(s) not found for architecture i386

[benjami...@googlemail.com]

Found it. Added to my_java_props_macosx.c:

void setUserHome(java_props_t *sprops)

{

    // ignore

}

ios i386 builds ok. But now I get this at runtime:

java/lang/AssertionError: java.lang.ClassNotFoundException: sun/nio/fs/MacOSXFileSystemProvider

  at sun/nio/fs/DefaultFileSystemProvider$1.run (line 49)

  at sun/nio/fs/DefaultFileSystemProvider$1.run (line 43)

  at java/security/AccessController.doPrivileged (native)

  at sun/nio/fs/DefaultFileSystemProvider.createProvider (line 42)

  at sun/nio/fs/DefaultFileSystemProvider.create (line 72)

  at java/nio/file/FileSystems

...

caused by: java/lang/ClassNotFoundException: sun/nio/fs/MacOSXFileSystemProvider

Ben

[Joel Dice]

On Tue, 22 Jul 2014, benjami...@googlemail.com wrote:

> ios i386 builds ok. But now I get this at runtime:
>
>

> *java/lang/AssertionError: java.lang.ClassNotFoundException:
> sun/nio/fs/MacOSXFileSystemProvider*
>
> * at sun/nio/fs/DefaultFileSystemProvider$1.run (line 49)*
>
> * at sun/nio/fs/DefaultFileSystemProvider$1.run (line 43)*
>
> * at java/security/AccessController.doPrivileged (native)*
>
> * at sun/nio/fs/DefaultFileSystemProvider.createProvider (line 42)*
>
> * at sun/nio/fs/DefaultFileSystemProvider.create (line 72)*
>
> * at java/nio/file/FileSystems*
>
> *...*
>
> *caused by: java/lang/ClassNotFoundException:
> sun/nio/fs/MacOSXFileSystemProvider*

Can you provide a test case so I can reproduce it? Thanks.

[benjami...@googlemail.com]

I figured it's because I miss a few ProGuard rules. I've never used ProGuard, so took me some time to get a step further.

But now I'm stuck with a java.net.SocketException which I don't know how to resolve. Some search revealed that the issue may root from JDK7 trying to use IPv6 internally, and setting -Djava.net.preferIPv4Stack=true to vmargs may solve the problem when using the JDK7 VM. 

I also spam my ProGuard settings file after the stack trace.

Starting server on 127.0.0.1:80

2014-07-24 11:58:18.624:INFO:oejs.Server:jetty-7.x.y-SNAPSHOT

2014-07-24 11:58:18.631:WARN:oejuc.AbstractLifeCycle:FAILED SelectChann...@0.0.0.0:80: java.net.SocketException: Permission denied

java.net.SocketException: Permission denied

at sun.nio.ch.Net.bind0(Native Method)

at sun.nio.ch.Net.bind(Net.java:444)

at sun.nio.ch.Net.bind(Net.java:436)

at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:214)

at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)

at org.eclipse.jetty.server.nio.SelectChannelConnector.open(SelectChannelConnector.java:187)

at org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:316)

at org.eclipse.jetty.server.nio.SelectChannelConnector.doStart(SelectChannelConnector.java:265)

at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)

at org.eclipse.jetty.server.Server.doStart(Server.java:292)

at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)

at Hello.startServer(Hello.java:59)

at Hello.<init>(Hello.java:31)

2014-07-24 11:58:18.632:WARN:oejuc.AbstractLifeCycle:FAILED org.eclipse.jetty.server.Server@2af4acf: java.net.SocketException: Permission denied

java.net.SocketException: Permission denied

at sun.nio.ch.Net.bind0(Native Method)

at sun.nio.ch.Net.bind(Net.java:444)

at sun.nio.ch.Net.bind(Net.java:436)

at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:214)

at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)

at org.eclipse.jetty.server.nio.SelectChannelConnector.open(SelectChannelConnector.java:187)

at org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:316)

at org.eclipse.jetty.server.nio.SelectChannelConnector.doStart(SelectChannelConnector.java:265)

at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)

at org.eclipse.jetty.server.Server.doStart(Server.java:292)

at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)

at Hello.startServer(Hello.java:59)

at Hello.<init>(Hello.java:31)

java/net/SocketException: Permission denied

  at sun/nio/ch/Net.bind0 (native)

  at sun/nio/ch/Net.bind (line 444)

  at sun/nio/ch/Net.bind (line 436)

  at sun/nio/ch/ServerSocketChannelImpl.bind (line 214)

  at sun/nio/ch/ServerSocketAdaptor.bind (line 74)

  at org/eclipse/jetty/server/nio/SelectChannelConnector.open (line 187)

  at org/eclipse/jetty/server/AbstractConnector.doStart (line 316)

  at org/eclipse/jetty/server/nio/SelectChannelConnector.doStart (line 265)

  at org/eclipse/jetty/util/component/AbstractLifeCycle.start (line 64)

  at org/eclipse/jetty/server/Server.doStart (line 292)

  at org/eclipse/jetty/util/component/AbstractLifeCycle.start (line 64)

  at Hello.startServer (line 59)

  at Hello.<init> (line 31)

2014-07-24 11:58:18.633 hello[53235:60b] Application windows are expected to have a root view controller at the end of application launch

--- ProGuard Config ---

-keep class Hello {

   <init>(long);

   *** draw(int, int, int, int);

   *** dispose();

   *** startServer();

 }

 

 -keep class org.eclipse.jetty.server.Server {

   <init>(int);

   *** start();

   *** setHandler(AbstractHandler);

 }

 

  -keep  class java.nio.charset.Charset {

   <init>(long);

   *** start();

   *** startServer();

   *** setHandler(AbstractHandler);

 }

-repackageclasses ''

-allowaccessmodification

-dontpreverify

#-keep public class * implements javax.xml.parsers.SAXParserFactory{public *;} 

#-keep public class com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl 

#-keep public class com.sun.org.apache.xerces.internal.impl.dv.dtd.DTDDVFactoryImpl 

-keep public class  java.lang.ExceptionInInitializerError

-keep public class sun.nio.fs.MacOSXFileSystemProvider

-keep public class java.nio.charset.Charset

-keep public class * implements org.eclipse.jetty.io.ByteArrayBuffer {public *;} 

-keepattributes *Annotation*,EnclosingMethod

#-keep public class  java.io.Serializable

#-keep public class * implements javax.mail.Authenticator

-keep class org.eclipse.jetty.io.**

-keep class org.eclipse.jetty.http.**

-keep class java.nio.**

#charset.UnsupportedCharsetException

-keep public class java.nio.ByteBuffer

-keep public class java.nio.CharBuffer

-keep public class java.nio.charset.spi.CharsetProvider

-keep public class java.security.AccessController

-keep public class java.security.AccessControlException

-keep public class java.security.PrivilegedAction

-keep public class java.util.Collections

-keep public class java.util.HashSet

-keep public class java.util.Iterator

-keep public class java.util.Locale

-keep public class java.util.Map

-keep public class java.util.NoSuchElementException

-keep public class java.util.Set

-keep public class java.util.ServiceLoader

-keep public class java.util.ServiceConfigurationError

-keep public class java.util.SortedMap

-keep public class java.util.TreeMap

-keep public class sun.misc.ASCIICaseInsensitiveComparator

-keep public class sun.nio.cs.StandardCharsets

-keep public class sun.nio.cs.ThreadLocalCoders

-keep public class sun.security.action.GetPropertyAction

-keep class sun.nio.cs.**

-keep class java.nio.charset.**

-keep class java.io.**

-keep class java.util.**

-keep class java.nio.charset.**

-keep class java.nio.**

-keepclasseswithmembernames class * {

    native <methods>;

}

-keepclasseswithmembernames class * {

    public <init>(android.content.Context, android.util.AttributeSet);

}

-keepclasseswithmembernames class * {

    public <init>(android.content.Context, android.util.AttributeSet, int);

}

-keepclassmembers enum * {

    public static **[] values();

    public static ** valueOf(java.lang.String);

}

-keepclassmembers enum * {

public static **[] values();

public static ** valueOf(java.lang.String);

}

Ben

On Wednesday, July 23, 2014 2:51:56 AM UTC+2, Joel Dice wrote:

[benjami...@googlemail.com]

This occurred to me for the arm build also, other targets worked. 

I've removed the ifdef __APPLE__ stuf in that source file, leaving just the default implementation. This seems to work. 

What is the right way to make this patch for arm only? 

Ben

[Joel Dice]

On Thu, 24 Jul 2014, benjami...@googlemail.com wrote:

> I figured it's because I miss a few ProGuard rules. I've never used
> ProGuard, so took me some time to get a step further.
>
>
> But now I'm stuck with a java.net.SocketException which I don't know how to
> resolve. Some search revealed that the issue may root from JDK7 trying to
> use IPv6 internally, and setting -Djava.net.preferIPv4Stack=true to vmargs
> may solve the problem when using the JDK7 VM.
>
> I also spam my ProGuard settings file after the stack trace.
>

> *Starting server on 127.0.0.1:80*
>
> *2014-07-24 11:58:18.624:INFO:oejs.Server:jetty-7.x.y-SNAPSHOT*
>
> *2014-07-24 11:58:18.631:WARN:oejuc.AbstractLifeCycle:FAILED
> SelectChann...@0.0.0.0:80: java.net.SocketException: Permission
> denied*
>
> *java.net.SocketException: Permission denied*

You're not going to be able to bind to a privileged port (i.e. below 1024)
on iOS. Try something higher, like 8080.

[benjami...@googlemail.com]

That and NIO is not working. Meanwhile I had success on both iOS simulator and device running Jetty by explicitely setting a buffered IO connector.

The stack trace when using the default NIO connector is this:

2014-07-24 18:21:57.579:INFO:oejs.Server:jetty-7.x.y-SNAPSHOT

2014-07-24 18:21:57.587:WARN:oejuc.AbstractLifeCycle:FAILED org.eclipse.jetty.server.nio.SelectChannelConnector$ConnectorSelectorManager@30cd7dd: java.lang.UnsatisfiedLinkError: sun/nio/ch/KQueueArrayWrapper.initStructSizes()V

java.lang.UnsatisfiedLinkError: sun/nio/ch/KQueueArrayWrapper.initStructSizes()V

at sun.nio.ch.KQueueArrayWrapper.initStructSizes(Native Method)

at sun.nio.ch.KQueueArrayWrapper.<clinit>(KQueueArrayWrapper.java:90)

at sun.nio.ch.KQueueSelectorImpl.<init>(KQueueSelectorImpl.java:87)

at sun.nio.ch.KQueueSelectorProvider.openSelector(KQueueSelectorProvider.java:42)

at java.nio.channels.Selector.open(Selector.java:227)

at org.eclipse.jetty.io.nio.SelectorManager$SelectSet.<init>(SelectorManager.java:416)

[Joel Dice]

On Thu, 24 Jul 2014, benjami...@googlemail.com wrote:

> That and NIO is not working. Meanwhile I had success on both iOS simulator
> and device running Jetty by explicitely setting a buffered IO connector.
>
> The stack trace when using the default NIO connector is this:
>

> *2014-07-24 18:21:57.579:INFO:oejs.Server:jetty-7.x.y-SNAPSHOT*
>
> *2014-07-24 18:21:57.587:WARN:oejuc.AbstractLifeCycle:FAILED
> org.eclipse.jetty.server.nio.SelectChannelConnector$ConnectorSelectorManager@30cd7dd:
> java.lang.UnsatisfiedLinkError:
> sun/nio/ch/KQueueArrayWrapper.initStructSizes()V*

You'll probably have to add one or more .c files to openjdk-src.mk, e.g.
KQueueArrayWrapper.c. Actually, I just looked and I see that file *is*
included for the MacOS build but not the iOS build. I don't remember why
that is, but it might be that KQueueArrayWrapper.c has/had code that won't
build on iOS and I didn't want to bother trying to make it work. You can
try adding it to see what happens.

[benjami...@googlemail.com]

Nice, works after adding this file with jdk7u-60. Tested on both simulator and device.