Per comment in bug 20860: "xpidl" cannot be build on 64bit Solaris SPARC (Solaris >= 2.7 UltraSPARC is a mixed 32bit/64bit environment which can run both 32bit and 64bit libraries). This is more or less related to bug 91382 ("New: "xpidl" requires libglib...) - there is currently no 64bit SPARC version of libglib (build not does not work correctly (crash)). Two solutions: - Force build of 32bit binary (=bad hack) OR - Fix bug 91382 and fix build stuff to build it correctly...
What are the errors that you are seeing? xpidl successfully builds using -xarch=v9 on my Solaris 7 box. The build later craps out in xpcom but that's the subject of another bug.
Finally it dies because libglib is not available as sparcv9 version... and even if I compile a 64bit libglib the "xpidl" binary is unuseable to crash in libglib ...
WFM. What commands are you using to build glib & libIDL with? I used: env CC='cc -xarch=v9' ./configure glib-1.2.10 libIDL-0.6.8 And all of the glib 'make check' tests passed.
Turns out that I used: env CC='cc -xarch=v9' CFLAGS=-O ./configure Without the explicit setting of CFLAGS, libtool (or something) gets confused and tries to link in the 32-bit version of libc.a .
cls: Last time I test that is nearly half a year ago, maybe someone fixed that... :-) But... an option like --use-external-xpidl (to use an already existing "xpidl" binary) would be much easier than building tons of extra libraries (that's why I am using --enable-toolkit=xlib for 64bit sparcv9 build, too)...
When you say "to use an already existing xpidl binary" are you talking about one that you have built and that you are providing to your "users", or something else? This goes back to the question of why you need to provide your users with xpidl.exe? It's not needed to run the browser, it's only needed for development.
right we're concerned about the mozilla build environment. iirc mozilla configure can use system nspr, graphics libs, zlib, it also has support for --with-glib-prefix and --with-gtk-prefix and other stuff I don't see a reason we shouldn't let developers say --with-xpidl= to supress building xpidl and just use a prepacked one. xpidl doesn't change often.
> xpidl doesn't change often. Lately. It does change. The changes are often critical. There may be periods of frequent changes in the future (as there have been in the past). I don't really care if this builds config feature gets added or not - but it becomes one more thing for someone to maintain and one more reason why someone's build might break when xpidl changes. If the build option is the goal, then a bug report should exist requesting that specific feature. Has the assertion made by the subject of this bug been confirmed or refuted?
The problem is: libglib is only required for "xpidl". Building it on 32bit is easy, building it on 64bit is a horror. I think it's far easier to use a 32bit binary instead of compiling libglib&libidl again as 64bit versions and then play alphatester for that code. Or is it mandatory to use a 64bit xpidl binary in a 64bit build ? And: What about crosscompiling Mozilla ? I think it's far easier to use a given xpidl binary in all these cases...
jband: The assertion made by this bug has been refuted. A 64-bit mozilla compiles with the patches in bug 20860 , which have absolutely nothing to do with xpidl. Roland: You're grasping now. CC='cc -xarch=v9' CFLAGS=-O ./configure --prefix=/usr/local-64 That's hardly horrific nor even involved. If it didn't work "half a year ago", why not try the latest version. Glib is under active development just as mozilla is. You're not willing to play "alphatester" for 64-bit xpidl but you will for 64-bit Mozilla? *blink* In a cross-compiled build, we build both the native & the target versions of xpidl so I'm not seeing your point here. As I said before, this particular bug is bogus and should be marked invalid. If you want to add a build config option to use an external copy of xpidl, then file a separate bug on it but keep in mind jband's warnings. Chances are that if you run into a bug using the system xpidl, you *will* be asked to duplicate it with the in-tree version. If you can't, then expect the bug to languish.
So do we still have an issue here?
Marking this INVALID per CLS comments, and to see if anyone is still interested in this.
Marking Verified -