> On 9 March 2010 17:31, Vladimir Sizikov <vsizi...@gmail.com> wrote: > > I think Wayne had some thoughts on how to build the launcher so that > > it would be compatible with as much Linux distros as possible (by > > carefully selecting the toolchain and compiler/lib versions). > > The "sweet spot" I found for linux binaries is to build them on ubuntu > 6.06.
May I suggest that the "sweet spot" for linux binaries is to have them packaged by there respective distro. Linux users really should be using their package manager for installing jruby. Within gentoo I know there is current a push by one dev to make jruby a standalone, drop in replacement for ruby. The same would occur for jython if it didn't lag so much. (This might come out a little as someone who is very bitter, but here it goes anyway. Please not that this is a general statement, and not directed at anyone or any project, jruby is probably a little better than average on this). Java and ruby [1] projects seem to have this idea that because there applications can "run everywhere" they shouldn't be able to be "built everywhere". Many java projects are a really pain to package for gentoo. Some of the common mistakes are * Bundling jars within jars ( or using jarjar to combine them all ). tomcat for example combines *parts* of 3 common-* jars into 1. This itself is a lib of the source build so isn't reproducible. I realise why you do it for jruby- complete.jar, but it would be oh so very very nice if it was extremely easy not to do it. * Ignoring CC, CFLAGS and LDFLAGS [2]. (Very very very common) Hopefully someone will get around to sending patches upstream for you guys. * Not providing source releases of packages (jffi, jna* guys). Having to fetch from scm's can be very annoying. At least you guys tag your releases. Try getting the source code for a package version when you need to know the last time the dev making the release sync'd trunk. * not using -source and -target with javac (we automagically rewrite build.xml files to 'fix' this). * including unit tests within the the production jar In fact it might be nice if you read our ebuild [3] [4]. Hopefully you will be able to follow it. My hope is to come back to you guys in a more constructive mood, bearing gifts of patches etc and really get jruby to be bloody brilliant on gentoo. when I get time. while there aint that many jruby related defects [5], some will be difficult to fix. The unit tests failing being a good example So please talk to your local ubuntu/debian, fedora, ****gentoo**** representative, get the distro's to be the main way you get jruby to the masses. > > This has: > - old glibc (2.3.x) - one of the perpetual problems jffi had was > building on glibc 2.4 and not running on older distros with 2.3.x > > - gcc 3.4.x - the C++ abi is compatible from gcc 3.4.x thru to current > gcc 4.x. This means dynamically linked binaries will work with the > libstdc++.so.6 on current distros. Before 3.4.x, the abi changed more > often than some people change their underwear. > > I have both 32bit and 64bit ubuntu 6.06 vms that I keep around > specifically for building jffi, that I could build the native launcher > with. And when there is a security vulnerability in the glibc version you built against are you going to release your own vulnerability and rebuilt the release again? Alistair Bush Gentoo Linux Developer - Java http://www.gentoo.org/ [1] http://blog.flameeyes.eu/2009/12/25/ruby-gems-problems-missing-dependencies [2] https://bugs.gentoo.org/show_bug.cgi?id=271533 [3] http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev- java/jruby/jruby-1.4.0-r5.ebuild?rev=1.2&view=markup [4] http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-java/jruby/files/ [5] https://bugs.gentoo.org/buglist.cgi?quicksearch=jruby+OR+jna+OR+jffi --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
