Kirix Support Forums

Building and Making it works under MACOSX

Please post any wxWebConnect patches or modifications you've created here. Thanks!

Building and Making it works under MACOSX

Postby foldink on Tue Oct 26, 2010 2:20 am

Hi all,

I recently went into troubles trying to make wxWebconnect working under MacOSX, snow leopard 10.6. I spend few days to look trough the code and I finally found out how to make it working !

I made it running using the Xulrunner Framework 1.9.2.10 provided by mozilla on their web site.
Steps are described bellow:

1- Compile all your wxWidgets libraries with the -arch i386 flag because Xulrunner universal libraries are not provided with the x86_64 architecture. More over the source code for the 1.9.2.10 is not compiling on a x86_64 arch.
2- Make sure that your application is compiling also with the -arch i386 compilation and linker flag.
3- Create your application bundle (I used macdylibbundler)
4- copy all the libs contained in the /Libraray/Frameworks/Xul.framework/Versions/1.9.2.10 in your bundle maybundle.app/Contents/MacOS dir and set up the path for libxpcom.dylib and plugins in your app to ./ and ./plugins. This is mainly due to the fact that libxpcom and other XUL libraries are set up with @executable_path@ when looking for libraries in your bundle. (This could be different by using install_name_tool but weird)
5- finally the gecko steps will not be ok so I've just commented out the return false when gecko path is failling in the wxWebconnect code GeckoEngine::Init() method.
All this stuff shall make your application works
This has been tested with the old wxWebconnect version, and wx2.9 on MacOSX 10.6.2 but shall works for all other Mac OS versions

Regards
foldink
foldink
Registered User
 
Posts: 1
Joined: Tue Mar 02, 2010 7:08 am

Re: Building and Making it works under MACOSX

Postby dpage on Thu Nov 25, 2010 1:31 pm

Hi foldink,

I've been working on the same problem, and thanks to your hints have got to the point where webconnect loads and initialises, and can even be seen downloading web pages and their component files (the download activity can be seen on the status bar).

However, where the web page should be displayed, I just see a blank window pane. Did you see this as well, or did you see the page properly displayed? Any ideas how to fix it?

Thanks, Dave.
dpage
Registered User
 
Posts: 7
Joined: Fri Jul 14, 2006 5:17 am

Re: Building and Making it works under MACOSX

Postby MrD on Mon Jan 10, 2011 6:34 pm

I'm having the same issue as Dave despite following foldink's instructions.

I've copied XULRunner 1.9.2.13 into my bundle inside Contents/MacOS and updated the code as stated to try and load XULRunner from ./ however when it tries to load the library, it fails and returns NULL.

Inside XPCOMGlueStartup, dlopen(xpcom_dll_path, RTLD_GLOBAL | RTLD_LAZY) is always returning NULL for me where xpcom_dll_path is ./libxpcom.dylib.

Is there any word from Kirix on Mac support? I've seen some old forum threads saying they were looking into it, but to be honest this project seems dead on this front and there doesn't seem to be a lot of support for it, which is a real shame since it is by far the easiest Web Toolkit to build for wxWidgets.

EDIT
Returning @executable_path from FindXulRunner has allowed it to load the library, it also allows it to get NS_GetFrozenFunctions, however it fails now when it tries to do res = f(&funcs, xpcom_dll_path)

I'll continue investigating.

EDIT 2
Actually, it's not failing where I thought it was. It's failing on NS_NewNativeLocalFile in GeckoEngine::Init.

EDIT 3
And that was because it gecko_path was set to @executable_path which normal functions don't understand. Setting it back to an empty string allowed GeckoEngine to finish initialising. It still doesn't render anything, and it crashes, but hey it's a start.

EDIT 4
And now it works! The crashes were my fault since I had to remove some of the AUI code to get it to build (for some odd reason). Now to remove all my hacks and make the code neat and not hard-coded for OS X.
MrD
Registered User
 
Posts: 20
Joined: Mon Jan 10, 2011 6:26 pm

Re: Building and Making it works under MACOSX

Postby dpage on Wed Jan 12, 2011 7:06 am

So what changes did you make exactly MrD? I'm still in the position where I can initialised XPCOM successfully, and it will download URLs (and linked images etc) but just doesn't render anything. I can even use other XPCOM functions to fetch documents into wxStrings.

I'm currently using wxWidgets 2.8, but I've also tried 2.9 with the same results.

Thanks.
dpage
Registered User
 
Posts: 7
Joined: Fri Jul 14, 2006 5:17 am

Re: Building and Making it works under MACOSX

Postby MrD on Wed Jan 12, 2011 6:38 pm

My thought process is pretty much documented above to be honest, I'm not sure what else to say as I've never had an issue where it didn't render.

Since I made this post I've gone through and properly tidied up the changes I made and I've made both an SVN style patch file showing my changes, and have also made a zip of the sources I am using to build on OS X. Hopefully one of these will be of help to you.

I just build this code and then paste the contents of a stock OS X XulRunner download inside the MacOS folder in the applications bundle and it works fine.

The patch file is inside the zip as the forums wouldn't let me upload a patch file by itself.

EDIT
I'm using the latest version of wxWidgets 2.9 by the way. I've not tested it with 2.8.
Attachments
wxWebConnect_OSX.zip
(164.05 KiB) Downloaded 796 times
MrD
Registered User
 
Posts: 20
Joined: Mon Jan 10, 2011 6:26 pm

Re: Building and Making it works under MACOSX

Postby dpage on Thu Jan 13, 2011 8:00 am

OK, so I tried wx 2.9 again, and this time it worked, however I had to use a shared Cocoa build. I have a sneaking suspicion, that last time I may have inadvertently used a Carbon build.\

Thanks for the tips!
dpage
Registered User
 
Posts: 7
Joined: Fri Jul 14, 2006 5:17 am

Re: Building and Making it works under MACOSX

Postby MrD on Thu Jan 13, 2011 1:30 pm

Ah yes, that might help.

I've not tested it with Carbon since I made sure to build wxWidgets with Cocoa since I'd read some whispers on here that XulRunner for OS X doesn't support a Carbon window handle, so not wanting to risk more pain I just avoided that potential pitfall altogether.
MrD
Registered User
 
Posts: 20
Joined: Mon Jan 10, 2011 6:26 pm

Re: Building and Making it works under MACOSX

Postby Aaron on Thu Jan 13, 2011 2:27 pm

Thanks to everyone for working to get this up on the Mac. We've been wanting this, and we appreciate the extra help. Are there additional things that need to be done to make it work better on Mac?
Aaron Williams
Kirix Support Team
User avatar
Aaron
Kirix Support Team
 
Posts: 120
Joined: Fri Dec 16, 2005 3:01 pm

Re: Building and Making it works under MACOSX

Postby MrD on Thu Jan 13, 2011 7:49 pm

Are there plans to add these fixes to an official release?

The only thing I'd really like to see is, I think, out of your control due to the way that XulRunner is built. I would like to be able to run it from a sub-folder just to help keep things tidy, however when I tried this it failed to load the dylib. foldink also stated this to be the case in the first post.

I've also just realised I made a small error (not that it would cause a problem, since this code path will currently never run due to the fact that XulRunner currently won't load from a sub-folder), in webcontrol.cpp on line 1671, I currently have:
Code: Select all
    // On OS X, remove @executable_path since normal functions won't be able to understand it
    std::string replace_string = "@executable_path";
    if (size_t pos = local_file_path.find(replace_string + path_separator) != std::string::npos)
    {
        local_file_path = local_file_path.substr(pos + replace_string.length() - 1);
    }
    else if (size_t pos = local_file_path.find(replace_string) != std::string::npos)
    {
        local_file_path = local_file_path.substr(pos + replace_string.length() - 1);
    }


However the substr on the first case shouldn't use the -1 due to it also needing to remove the path_separator character. So it should be:
Code: Select all
    // On OS X, remove @executable_path since normal functions won't be able to understand it
    std::string replace_string = "@executable_path";
    if (size_t pos = local_file_path.find(replace_string + path_separator) != std::string::npos)
    {
        local_file_path = local_file_path.substr(pos + replace_string.length());
    }
    else if (size_t pos = local_file_path.find(replace_string) != std::string::npos)
    {
        local_file_path = local_file_path.substr(pos + replace_string.length() - 1);
    }
MrD
Registered User
 
Posts: 20
Joined: Mon Jan 10, 2011 6:26 pm

Return to wxWebConnect Patches & Modifications