Hello, On ketvirtadienis 17 Rugsėjis 2009 15:35:04 Mathieu Malaterre wrote: > On Thu, Sep 17, 2009 at 1:26 PM, Modestas Vainius <modes...@vainius.eu> wrote: > >> > Secondly, fixing #544674 bug will NOT fix #545335. Current > >> > FindJNI.cmake refers to $JAVA_HOME/ppc in the search path as it is > >> > supposed to (according to openjdk-6-jre-headless package). > >> > >> There is no convention AFAIK. So unless you inspect all of them you > >> will *not* find libjawt.so. > > > > Well, I've found how openjdk determines its libarch dir and mostly have > > proper cmake code for it. > > Excellent. How about all the other ones ? > http://packages.debian.org/search?suite=sid&searchon=contents&keywords=libj > awt.so
openjdk libarch dir is the most complex one. Due to its proprietary nature, openjdk does some hardly explainable hacks with `uname -m`. Other JVMs are plain `uname -m` (kaffe) or no libarch subdir at all (gcj). Plain simple I would say. > >> That's just wrong. cmake is doing system inspection. This was written > >> by someone not knowing the cmake enough. > > > > That's a workaround for broken FindJNI, it could be improved a bit to > > exclude i386,amd64,powerpc where FindJNI does its job well. > > Well FindJNI is an interface, it should work regardless of CPU/ARCH. That's exactly the point. It SHOULD. That's the reason I don't like library path hardcoding like your patch does. > >> I can understand that you would prefer another solution (I also > >> personnaly do), but for the time being there is no convention for > >> debian package providing libjawt.so and symlinks are not always > >> provided. > > > > So you just added Debian arches. What about linux arches debian does not > > support? I'm trying to think about broader issue here. > > Correct it will fails miserably. I just do not know how to deal with > that in a portable manner. I haven't found any documentation that > describe where libjawt.so should be located. Because there are no docs about this. stuff is hidden deeply in java build system and *linux* specific hacks to discover that path at runtime. Java paths are a huge MESS. > Well the patch you describe in your other mail: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544674#68 > > has just been applied upstream (thanks to Denis Barbier), it took > *several* round to get it right (Denis, Berk, Jeff, Brad and I did > work on that patch). Yeah, it is hard to get that right. > I doubt anyone will actually spent the time to > integrate this large patch to VTK 5.2 since it is so old. VTK 5.4 is > out and VTK 5.6 should come out soon. Since it is fixed in 5.4, leave upstream stuff in 5.2 as it is (it would be pointless to waste time on fixing obsolete stuff). Just fix up VTK 5.2 packaging hack now (a single ifeq line in debian/rules) and good path to libjawt.so will propagate to all vtk rdeps as a result. This will solve FTBFSes and let everything migrate to testing. In the meantime, proper fix for FindJNI won't take ages and you will be able to get rid of the hack all together really soon. > So I thought -again for the time being- that this modest patch was ok. Maybe for Debian, but definitely not upstream... -- Modestas Vainius <modes...@vainius.eu>
signature.asc
Description: This is a digitally signed message part.
