Re: ImageIO Native Java 1.6 / Small Progress
Re: ImageIO Native Java 1.6 / Small Progress
- Subject: Re: ImageIO Native Java 1.6 / Small Progress
- From: Johnny Miller <email@hidden>
- Date: Tue, 02 Apr 2013 10:39:36 -1000
Hi Tim,
Yeah, I'm getting stumped. I've tried setting x86_64 in the build setting for all targets and I've even tried compiling with xcodebuild ARCHS="x86_64" from the command line but no matter what if I run
file libImageIOImageProcessor.jnilib
I get
libImageIOImageProcessor.jnilib: Mach-O dynamically linked shared library i386
It just refuses to take the x86_64 setting.
Johnny
On Apr 2, 2013, at 10:14 AM, Tim Worman <email@hidden> wrote:
> I've had this issue before. There used to be a WO based app for changing your Open Directory password. It was set up with a JNI library for interfacing with Apple's directory services frameworks. It no longer ran on 64-bit Intel.
>
> I never tried to dive into XCode and recompile it - so not sure about that part.
>
> Tim
>
> On Apr 2, 2013, at 12:55 PM, Johnny Miller <email@hidden> wrote:
>
>> OK. So I added this argument to the application's additional arguments in WOMonitor:
>>
>> -Djava.library.path=/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java
>>
>> And it is now finding the JNI. But now I'm on to a new problem!
>>
>> java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/libImageIOImageProcessor.jnilib: no suitable image found. Did find: /Library/Java/Extensions/libImageIOImageProcessor.jnilib: mach-o, but wrong architecture
>>
>> So the Google seems to think this is because the JNI is compiled for 32 bit but I'm using 64 bit java. That would make sense. I've tried recompiling the JNI and I've changed the ARCHS variable in the build properties to x86_64 but I'm still getting the error. Does anyone who is wise in the ways of MacOSX programming know where I've gone wrong? I'm using 10.5 and XCode 3.1
>>
>> Thanks,
>>
>> Johnny
>>
>> On Apr 2, 2013, at 9:25 AM, Johnny Miller <email@hidden> wrote:
>>
>>> Thanks for the advice guys. Although, I'd really like to get the native going...
>>>
>>> The error I'm seeing is a com.webobjects.foundation.NSForwardException [java.lang.NoClassDefFoundError] Could not initialize class er.attachment.thumbnail.ImageIOImageProcessor:java.lang.NoClassDefFoundError:
>>>
>>> I made a simple class that prints out the java class path from the command line and I see that /Library/Java/Extensions is in there. But... getting WebObjects to use Java 1.6 was kind of a hack to begin with. I had to create the file /etc/launchd.conf which contains these two lines:
>>>
>>> setenv JAVA_VERSION 1.6
>>> setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home
>>>
>>> Philippe Rabier pointed me to this solution a few months back -> http://stackoverflow.com/questions/135688/setting-environment-variables-in-os-x
>>>
>>> Do you think I also need to add a Java class path variable to this file? If so does anyone know what the variable would be?
>>>
>>> Thanks,
>>>
>>> Johnny
>>>
>>> On Apr 2, 2013, at 8:52 AM, Ramsey Gurley <email@hidden> wrote:
>>>
>>>> Frankly, my most recent experience with all three sucked. I tried installing octave. fink, macports, and homebrew all failed. I finally found a compiled package installer for Mac OS X which sorta works. I can't see myself getting to excited about any of them.
>>>>
>>>> Ramsey
>>>>
>>>> On Apr 2, 2013, at 10:46 AM, Tim Worman wrote:
>>>>
>>>>> That could be so I suppose. And, it may be due to the particular packages I use, but I have never had anything break with the software packages I install. My experiences with homebrew have been good.
>>>>>
>>>>> Tim
>>>>>
>>>>> On Apr 2, 2013, at 9:58 AM, Ramsey Gurley <email@hidden> wrote:
>>>>>
>>>>>> If my understanding is correct, Homebrew uses the installed system libraries whenever possible. That's the reason to use, and to avoid, Homebrew. Install an app with Homebrew, then update the system from Lion to Mountain Lion and pray things still work.
>>>>>>
>>>>>> With macports, you install a full set of your dependencies in a separate /opt/ directory. Update your system all you want. It doesn't matter because system updates won't touch /opt/.
>>>>>>
>>>>>> So Homebrew is a bit like dumping a lot of jars in $JAVA_HOME/ext/, where macports is like a fully embedded build. You get more bloat, but fewer headaches. Given a choice, I know which one I'd choose.
>>>>>>
>>>>>> That's what I remember reading about them at least. :-)
>>>>>>
>>>>>> Ramsey
>>>>>>
>>>>>> On Apr 2, 2013, at 9:43 AM, Tim Worman wrote:
>>>>>>
>>>>>>> I'm not quite as passionate about it, but that's why I use homebrew. :-)
>>>>>>>
>>>>>>> Tim
>>>>>>> UCLA GSE&IS
>>>>>>>
>>>>>>> On Apr 2, 2013, at 7:55 AM, Þór Sigurðsson <email@hidden> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Actually no - since macports and fink install dependant libraries that the system already has installed, it's hardly an enhancement since now you have _two_ or more sets of the same libraries which each needs its own method of updating.
>>>>>>>>
>>>>>>>> The net result of overusing fink/macports is a machine that requires more time to manage than to use - hardly a productive result (unless you don't care about security, updates or management, in which case it's perfectly fine).
>>>>>>>>
>>>>>>>> One should strive to keep the management footprint at a minimum.
>>>>>>>>
>>>>>>>> /Þór
>>>>>>>>
>>>>>>>> On 2.4.2013, at 14:34, Kieran Kelleher wrote:
>>>>>>>>
>>>>>>>>> There .. fixed it for you ;)
>>>>>>>>>
>>>>>>>>> On Apr 2, 2013, at 9:32 AM, Þór Sigurðsson <email@hidden> wrote:
>>>>>>>>>
>>>>>>>>>> If you don't want to "enhance" your system with macports/fink, then you can use the cactuslabs build: http://cactuslab.com/imagemagick/
>>>>>>>>>>
>>>>>>>>>> /Þór
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ________________________________
>>>>>>>>
>>>>>>>> Fyrirvari á tölvupósti / e-mail disclaimer
>>>>>>>> http://us.is/fyrirvari
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>>> Webobjects-dev mailing list (email@hidden)
>>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>>
>>>>>>>> This email sent to email@hidden
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>> Webobjects-dev mailing list (email@hidden)
>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>
>>>>>>> This email sent to email@hidden
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>> Webobjects-dev mailing list (email@hidden)
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>
>>>>>> This email sent to email@hidden
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Webobjects-dev mailing list (email@hidden)
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>> This email sent to email@hidden
>>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden