xpidl cannot build on 64bit SPARC

VERIFIED INVALID

Status

()

Core
XPCOM
VERIFIED INVALID
17 years ago
10 years ago

People

(Reporter: Roland Mainz, Assigned: David Bradley)

Tracking

Trunk
Sun
Solaris
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
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...
(Reporter)

Updated

17 years ago
Blocks: 20860
Depends on: 91382

Comment 1

17 years ago
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.
(Reporter)

Comment 2

17 years ago
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
...

Comment 3

17 years ago
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.

Comment 4

17 years ago
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 .  
(Reporter)

Comment 5

17 years ago
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)...
(Assignee)

Comment 6

17 years ago
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.

Comment 7

17 years ago
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.

Comment 8

17 years ago
> 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?
(Reporter)

Comment 9

17 years ago
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...

Comment 10

17 years ago
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.

No longer blocks: 20860
(Assignee)

Comment 11

17 years ago
So do we still have an issue here?
(Assignee)

Comment 12

16 years ago
Marking this INVALID per CLS comments, and to see if anyone is still interested
in this.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID

Comment 13

16 years ago
Marking Verified -
Status: RESOLVED → VERIFIED

Updated

10 years ago
Component: xpidl → XPCOM
QA Contact: pschwartau → xpcom
You need to log in before you can comment on or make changes to this bug.