Re: [platform-swt-dev] Bug to do with the way SWT extracts it's native l

[Steve Northover <Steve_Northover@xxxxxxxxxx>]

This should already be fixed in 3.5.
 If not FIXEDFORYOU, please open a bug report.

Ben Staniford <ben@xxxxxxxxxxxxx>
Sent by: platform-swt-dev-bounces@xxxxxxxxxxx

05/29/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