Update on testing Solaris versions of MailNews and Navigator components.

[athenian200]

So, I've been working on getting other UXP-based applications to work on Solaris. Compiling the Navigator works (as you would expect), but support for MailNews is going to take longer than I expected. I was optimistic at first because it compiled with no errors, but I'm running into weird startup issues again. I had some other issues related to using a symlink for the mozilla directory and getting a null version string as a result, and also chased false leads related to the warning about installLocationsByName being null (which likely is a separate issue). If I delete all the profile information it creates each time before trying to run it, the installLocations warning goes away. These warnings only appear on subsequent attempts to run it after the initial crash, so I doubt it's related to the initial crash itself.

If I try running ./interlink -P, it brings up profile information and I can play around with the dialog box right up until it tries to load the "meat" of the program, so I know the executable isn't totally faulty. Playing around with GDB isn't helping much, and it feels like a very similar kind of situation to the NSS issues I was having earlier. All I know is that an attempt to initialize something (or possibly even a FAILURE to attempt to initialize something?) is probably causing everything to blow up, only this time I have even less information. It usually prints nothing relevant to the console even with a debug build and appears to exit normally.

So basically, the program's execution goes like this. The main execution loop in nsMailApp.cpp starts up fine, it loads in libxul.so without much of a problem, and then the last library that gets loaded in before the crash is libpixbufloader-png.so. I don't think that library is the problem, though.

After loading in that library, the program continues spinning up new threads as it goes through XREMain in nsAppRunner.cpp. Everything looks fairly normal until it hits RecordShutdownEndTimeStamp, at which point I think it might be clear something is going wrong, but I don't know what. Then I'm back in nsMailApp watching it go through nsCOMPtr<nsIFile> statements. After nsCOMPtr<nsIFile> appini, suddenly I've hit NS_LogTerm, by which point it's clear the application is definitely shutting down and not starting up. It's weird, because when I compare it with the navigator, nsNavigatorApp.cpp looks just like nsMailApp.cpp, so I don't see why that should be working while this fails.

As far as I can tell, the application is going straight from the startup to the shutdown without doing anything at all in the middle, or if it is doing anything in the middle I don't know where to look for it. So yeah... if anyone was looking forward to this being done quickly just because I got the browser to work somehow (I know I was looking forward to it), it's going to be a while. I estimate this will take me another 2 weeks to a month. I'm not giving up, though!

On a more positive note, here are some screenshots of the progress I've made so far...

[New Tobin Paradigm]

Please don't put out navigator stuff it isn't reasy. Also I didn't expect any issues with it.

[athenian200]

Yeah, don't worry, I'm not going to distribute anything at this point, my work is also still very preliminary and isn't ready for prime time yet either. I'm still doing a lot of testing at this point. I've been comparing the way they both start up to try and figure out what the difference is, since one is working and the other isn't and they both use a lot of the same/similar code. Hope I haven't caused any problems for you.

[New Tobin Paradigm]

I see.. Right on then. Yeah do use Navigator as an indicator of some of the older ways of doing things and as a test point for things much closer to the underlying platform than the Phoenix browsers.

[athenian200]

Yeah, I really like the theme it has. I remember using Netscape 6 as a kid, and comparing the Mozilla Suite side-by-side with Netscape wondering why they looked so similar except the logo.

Anyway... good news. I've successfully gotten Interlink to compile and run on Solaris, and the problems weren't nearly as bad as I thought they were.



But I had to do it in a really weird way. The reason for the build failure almost doesn't make sense to me, nor does the solution.

I completed analyzing the differences between the browser and the mail client, and concluded that most of the underlying executable stuff is the same. The same -P option to access stubs that are built in. GDB wasn't any help because of what turned out to be the case. The majority of the differences between the browser and the mail client aren't at the C++ level, they're at the Javascript level. I figured out what was going on when I remembered that the browser has a --jsconsole option, and realized the mail client might support it as well.

When I ran the --jsconsole, I saw that the browser was complaining about missing Javascript files. I started dropping them into the modules directory from the source code, and as I did so, Interlink started sort of working. The interface would come up, but was non-functional. I noticed that most of the missing functionality was from the /mailnews folder, and started looking around the source files. All of the mailnews functionality appeared to be locked behind the MOZ_MAILNEWS variable, along with a few others. I double-checked by building the exact source code I'm messing with on Linux Mint, and the only differences in the build process were basically that the /mailnews folder gets included and the lightning extension gets built. For whatever reason, the program was being built as some kind of weird empty shell with neither browser guts nor mailnews guts, that just exits normally if you don't use any command line options.

I tried everything I could to get those variables to be true. I tried adding export statements to confvars.sh. I tried adding export statements to my .mozconfig file, along with mk_add_options statements. I tried exporting the values explicitly in my shell. I tried explicitly adding a 1 value to all the AC_SUBST and AC_DEFINE statements in configure.in. I even tried using set_config and set_define statements in another file somewhere, along with using explicit DEFINES statements in various moz.build files. Absolutely nothing worked. For whatever reason, the build system was determined that the variables I need to be true in order to build Interlink properly were going to be false whether I like it or not.

So, what did I do? I did something kind of stupid and desperate. I replaced all the checks for MOZ_MAILNEWS and the other variables that were 'stuck' with checks for what OS I'm using that will always return true. It worked.

Interestingly, I went through on Mint and found that the reverse was true. I couldn't make the variables false. I could comment out all the variables in confvars.sh, I could comment out all the AC_SUBST/AC_DEFINE statements in configure.in, and it would still build everything properly even when I explicitly tried to break it.

I couldn't figure out where those variables were being set and why they were "stuck," but I did at least isolate the problem and get it working for now, even if I didn't manage to do it in a proper way.