User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008020504 Minefield/3.0b4pre Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008013122 Minefield/3.0b3pre When trying to open a shared library using js-ctypes in Linux, the open() method returns/throws NS_ERROR_FAILURE. Reproducible: Always Steps to Reproduce: 1.Compile Firefox with js-ctypes as an extension. 2.Try opening a shared library file (in an extension or similar). Actual Results: NS_ERROR_FAILURE is returned/thrown. Expected Results: The shared library is loaded. This is due to the way the PRLibSpec struct is filled out in nsNativeTypes::Open. The |libSpec.value.pathname_u = ...| assignment only works under Win32 as can be seen in prlink.c.
Created attachment 301890 [details] [diff] [review] tentative fix This patch fixes the problem for me. It's fairly straight-forward, although since I'm new at this thing (especially the Mozilla string classes) there may be a shorter way of doing it. Also, I'm not 100% sure that dlopen() groks UTF-8 so it's possible the conversion has to be the lossy one from UTF-16 to ASCII. (From what I've been able to find, it doesn't seem to mind being fed UTF-8.) Also, the patch isn't -u8p since svn diff kinda sucks.
Created attachment 301909 [details] [diff] [review] tentative patch v. 2 The copy was most likely completely unnecessary (aName being an in parameter). This works too, and is probably more correct. Sorry for the bug spam. I still have the training wheels on my bug-fixin' bike.
Attachment #301890 - Attachment is obsolete: true
Created attachment 304115 [details] [diff] [review] yet another revision, wee I may be breaking the record for most patch revisions for a 6-line addition. I deserve a medal. And cake. Anyway, this one only uses ns[C]AutoString, and gets rid of the original nsString line, which is bad stack mojo according to the string literature. I'll shut up now.
Attachment #301909 - Attachment is obsolete: true
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attachment #301909 - Attachment is obsolete: false
Bug 397248 pointed out a problem with not using a local string so I used patch 2 instead of patch 3.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Component: js-ctypes → js-ctypes
Product: Other Applications → Core
You need to log in before you can comment on or make changes to this bug.