Darren J Moffat wrote: > Danek Duvall wrote: >> I'm sponsoring the following case for Harshal Patil. This case is >> intended >> to support the Azureus (soon to be Vuze) bittorrent client, the case for >> which should be running soon. It would also enable Eclipse to be >> integrated. > > Yeah, I've spent far to much time in the last two weeks trying to build > these libs for exactly that reason!
I guess you are trying to build on OpenSolaris 2008.05. If yes, there is simple hack for it. get the spec file for SWT from spec-files-extra and search for this line, make -j$CPUS replace that line with following, make -j$CPUS -f make_solaris.mak JAVA_HOME=/usr/java make_swt make_atk make_awt make_cairo make_gnome This will remove the Dt dependency and your SWT will get built without Dt support. Resulting lib works fine with Vuze, I haven't checked it with Eclipse though. And this is all I am doing. That is why the questions like, this file should be in this directory puzzle me, because I haven't decided any of these file locations. I took to spec file from SFE and by doing the above mentioned trick, things worked for me. Does spec files submitted on spec-files-extra go through similar kind of Reviews? I don't know, I am just few days old in SUN. so may be I am missing something. > >> /usr/lib/swt/swt.jar > > Why are we hiding the main swt interface here ? > > Should this be somewhere more generic like /usr/share/lib/java/ > >> /usr/lib/swt/swt-debug.jar >> /usr/lib/swt/libswt-pi-gtk-3349.so >> /usr/lib/swt/libswt-gtk-3349.so >> /usr/lib/swt/libswt-gnome-gtk-3349.so >> /usr/lib/swt/libswt-cde-gtk-3349.so >> /usr/lib/swt/libswt-cairo-gtk-3349.so >> /usr/lib/swt/libswt-awt-gtk-3349.so >> /usr/lib/swt/libswt-atk-gtk-3349.so >> >> Since this is a shared lib, the numbers before .so don't matter.. even if >> we later upgrade this lib, all the apps depending on it will not be >> affected. What those apps will look for is to load libs like swt-atk-gtk >> etc. > > As Danek already pointed out the statement is clearly false. > > I'm also VERY concerned about this since the motivation for this case is > Vuze which auto updates itself. I'm concerned that some future version > of an autoupdate of Vuze will need a different version of SWT. How will > that be dealt with [ Not the Vuze update but the future version of > libswt ] ? > > Unless there is a plan to have multiple versions of SWT installed I see > no reason to have the -3349 in the file names. Particularly since it is > NOT present in the main swt.jar file; meaning it isn't possible with the > layout presented in this case to have multiple versions of SWT. So just > drop the -3349. > OK, this is how it looks on ubuntu 8.04, /usr/lib/jni/libswt-gnome-gtk-3236.so /usr/lib/jni/libswt-awt-gtk-3236.so /usr/lib/jni/libswt-atk-gtk-3236.so /usr/lib/jni/libswt-gtk-3236.so /usr/lib/jni/libswt-pi-gtk-3236.so /usr/lib/jni/libswt-cairo-gtk-3236.so /usr/lib/jni/libswt-mozilla-gtk-3236.so /usr/lib/jni/libswt-glx-gtk-3236.so They haven't drop any tailing numbers. I am no expert on shared libs, but I can tell you what I have experienced. I have used libs with -3346 and download the .jar files for Azureus 2 and Azureus 3. Both worked fine! so upgrade didnt matter, then I kept Azureus 3 constant, and changed SWT libs from -3346 to -3349.. it still works. If you want I can send you the spec file and you can try it out (i dont know if sending any attachments on this list is acceptable). What I saw is that, if you completely remove SWT from path, it will spit saying swt-gtk not found in blah blah blah path. > What versions of the JRE does this SWT build support ? > To build SWT thought you need JDK, I have compiled using JDK 1.5 and JDK 1.6 both. JRE is not required directly by SWT, it might be required by the app which might use SWT (eg. my very own headache Vuze ;)
