Thanks Richard ! Can I say I love you? "org.osgi.framework.bootdelegation=*" did the work and my VTK bundle works perfectly now. Just to understand what I just did, what is this variable doing?
Regarding the processor, I indeed have a Core2Duo proc, which is 64bits. The VTK version I compiled is 64bits as well. Kind regards, and again thank you very much Benoît Le 4 nov. 2010 à 16:06, Richard S. Hall a écrit : > On 11/4/10 10:43, Thiébault Benoît wrote: >> Thank you Richard, >> >> I added "processor=x86_64" and it "worked". I now have the same error >> message than with Equinox :-) >> >> When I add like you "processor=x86", it crashes, but my error message is not >> as explicit as yours: >> >>> org.osgi.framework.BundleException: Unresolved constraint in bundle >>> test-osgi-vtk [5]: No matching native libraries found. > > It appears that you have a different processor than me, which is why x86 > doesn't work for you. > >> I have two questions regarding this "processor" issue: >> - Could it be possible in future versions of felix to have a more detailed >> error message for this issue? > > It is difficult to get a detailed error message, because the selecting of > matching libraries happens earlier than the resolve, so by then we don't know > why they didn't match. > >> - Is it a bug or a feature? I mean, what does the OSGi standard say about >> the "processor": is it mandatory (in this case, Felix is right to crash) or >> optional (and its a felix bug)? > > It didn't crash, it just didn't resolve the bundle. > > I'm not sure about whether requiring processor is correct or not, so I will > look into it, but it would definitely be a best practice. > >> Now, regarding my VTK-specific error, does anyone have any clue what OSGi >> does that makes the pure Java application work and not the OSGi bundle? >> I have looked for an answer to this problem for days and can't find what >> causes it (and how to solve it) >> Any hint is thus very welcome :-) > > Hard to say. For the fun of it, try editing conf/config.properties to include: > > org.osgi.framework.bootdelegation=* > > And see if that has any impact. > > -> richard > >> Kind regards, >> >> Benoît >> >> Le 4 nov. 2010 à 15:26, Richard S. Hall a écrit : >> >>> It appears that Felix treats processor as a required attribute on the >>> native library, so you have to specify "processor=FOO" on the end of your >>> Bundle-NativeLibrary header. I added "processor=x86" and got it to resolve >>> on my Mac, but ended up getting errors when I started it: >>> >>> Caused by: java.lang.UnsatisfiedLinkError: >>> /Users/rickhall/Projects/felix-trunk/main/felix-cache/bundle5/version1.1/bundle.jar-lib/0/vtk/osx64b/libvtkproj4.jnilib: >>> no suitable image found. Did find: >>> /Users/rickhall/Projects/felix-trunk/main/felix-cache/bundle5/version1.1/bundle.jar-lib/0/vtk/osx64b/libvtkproj4.jnilib: >>> mach-o, but wrong architecture >>> >>> Not sure if processor should be required, but it seems like a good idea. >>> >>> -> richard >>> >>> >>> On 11/4/10 10:00, Thiébault Benoît wrote: >>>> Hi everyone, >>>> >>>> I am currently working on creating an OSGi bundle embedding VTK, the >>>> Visualization ToolKit (http://www.vtk.org), written in C++, on Mac OS X. >>>> >>>> I have written an article about my adventures and the related issues I >>>> have encountered so far: >>>> http://dev.artenum.com/blog/ben/posts/osgi_vtk_and_macosx >>>> >>>> The short story is that by default, the compilation configuration of VTK >>>> does not create and link properly the dynamic libraries on Mac OS X. I >>>> thus had to modify 3 things: >>>> • change the .dylib extensions to .jnilib >>>> • prepend the @loader_path prefix to the library transitive dependencies >>>> • remove the version numbers from the library file names and >>>> dependencies. >>>> >>>> This way, I managed to execute the bundle without an UnsatisfiedLinkError >>>> with Equinox. I however have a new problem, that seems much more complex >>>> to me. >>>> >>>> When the bundle starts, it creates a "vtkPanel", which extends the AWT >>>> Canvas. The rendering on the panel is then performed by a native method >>>> call that crashes. >>>> >>>>> WARNING in native >>>>> method: JNI call made with exception pending >>>>> at vtk.vtkPanel.RenderCreate(Native Method) >>>>> at vtk.vtkPanel.Render(vtkPanel.java:166) >>>>> - locked<1060ffa88> (a vtk.vtkPanel) >>>>> at vtk.vtkPanel.paint(vtkPanel.java:189) >>>>> at sun.awt.RepaintArea.paintComponent(RepaintArea.java:276) >>>>> at sun.awt.RepaintArea.paint(RepaintArea.java:241) >>>>> at apple.awt.ComponentModel.handleEvent(ComponentModel.java:263) >>>>> at java.awt.Component.dispatchEventImpl(Component.java:4790) >>>>> at java.awt.Component.dispatchEvent(Component.java:4544) >>>>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:635) >>>>> at >>>>> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:296) >>>>> at >>>>> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211) >>>>> at >>>>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:201) >>>>> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:196) >>>>> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:188) >>>>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:122) >>>>> FATAL ERROR in >>>>> native >>>>> method: Bad global or local ref passed to JNI >>>>> at vtk.vtkPanel.RenderCreate(Native Method) >>>>> at vtk.vtkPanel.Render(vtkPanel.java:166) >>>>> - locked<1060ffa88> (a vtk.vtkPanel) >>>>> at vtk.vtkPanel.paint(vtkPanel.java:189) >>>>> at sun.awt.RepaintArea.paintComponent(RepaintArea.java:276) >>>>> at sun.awt.RepaintArea.paint(RepaintArea.java:241) >>>>> at apple.awt.ComponentModel.handleEvent(ComponentModel.java:263) >>>>> at java.awt.Component.dispatchEventImpl(Component.java:4790) >>>>> at java.awt.Component.dispatchEvent(Component.java:4544) >>>>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:635) >>>>> at >>>>> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:296) >>>>> at >>>>> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211) >>>>> at >>>>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:201) >>>>> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:196) >>>>> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:188) >>>>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:122) >>>>> Invalid memory access of location 0x0 rip=0x1010af1f4 >>>>> ./ben.sh: line 11: 23453 Abort trap java -Xcheck:jni -jar >>>>> org.eclipse.osgi_3.6.0.v20100517.jar -console >>>> This native method crashes when calling the jawt.h method >>>> GetDrawingSurfaceInfo(ds), and I have no idea where it may come from. >>>> >>>> The pure Java (no OSGi) application works fine, so I thought it could be >>>> Equinox-related. This is why I tried to load the same bundle in Felix. >>>> But here I have a new error message: >>>> >>>>> org.osgi.framework.BundleException: Unresolved constraint in bundle >>>>> test-osgi-vtk [5]: No matching native libraries found. >>>> ... and nothing more (even with log level at 4). >>>> How can I know what does not work? >>>> What did I do that is Equinox-compatible and Felix-incompatible? I don't >>>> recall using specific Manifest entries... >>>> >>>> Project source code can be downloaded here: >>>> http://dev.artenum.com/blog/ben/download/test-osgi-vtk_zip?action=download&nodecorator >>>> >>>> Kind regards, >>>> >>>> Benoît >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>>> For additional commands, e-mail: users-h...@felix.apache.org >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>> For additional commands, e-mail: users-h...@felix.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
