[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] Bug to do with the way SWT extracts it's native library to $TEMP
|
see https://bugs.eclipse.org/bugs/show_bug.cgi?id=236855
please use the bugzilla for bugs. thank you
Ben Staniford <ben@xxxxxxxxxxxxx>
Sent by: platform-swt-dev-bounces@xxxxxxxxxxx
29/05/2009 09:06 AM
Please respond to
"Eclipse Platform SWT component developers list."
<platform-swt-dev@xxxxxxxxxxx>
To
"Eclipse Platform SWT component developers list."
<platform-swt-dev@xxxxxxxxxxx>
cc
Subject
[platform-swt-dev] Bug to do with the way SWT extracts it's native library
to $TEMP
I noticed a nasty little bug today with the SWT. Basically, when you run
an SWT app and reference swt-disribution.jar in your application. It
extracts it's native library to a TEMP path and then does a System.load()
on that location. However, it fails to mangle the name of the library
when it puts it in TEMP. This means that if you (for example) try to
start a 32 bit and then subsequently 64 bit SWT application on the same
system, the 64 bit SWT library will attempt to extract it's 64 bit native
library over the top of the 32 bit one and will fail to overwrite it due
to it being locked. It'll then attempt to load that library and the
application will fail with an UnsatisfiedLinkError.
This basically means that it's currently impossible for 64 bit and 32 bit
SWT apps to coexist presently. It looks very easy to fix though.
--
Ben Staniford
Web: http://www.staniford.net
Phone: +44 (0) 151 638 0725
Mobile: +44 (0) 7891 842962_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev
