91382 - Remove/replace xpidl's use of libglib...

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect)

Description

[Roland Mainz]

"xpidl" requires libglib even when I try to get rid of any alien Linux/Gnome
libraries via configure --enable-toolkit=xlib ... BAD.

% ldd ./xpidl
        libglib-1.2.so.0 =>      /usr/local/lib/libglib-1.2.so.0
        libIDL-0.6.so.0 =>       /usr/local/lib/libIDL-0.6.so.0
        librt.so.1 =>    /usr/lib/librt.so.1
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libm.so.1 =>     /usr/lib/libm.so.1
        libthread.so.1 =>        /usr/lib/libthread.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libaio.so.1 =>   /usr/lib/libaio.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1

Comment 1

[cls]

Umm, xpidl requires glib because libIDL requires glib and xpidl requires libIDL.
 Why is this considered a bug?

Comment 2

[John Bandhauer]

I'm with cls. Marking this invalid. REopen if you can make some case for why it 
should be different.

Comment 3

[Roland Mainz]

Two reasons:

1. Because libglib is not part of any Unix except on Linux.
If I want to ship a Zilla which does not require any libraries I usually use
--enable-toolkit=xlib - which works prefectly without any alien stuff/libs etc.
... except that "xpidl" requires libglib.
Should all users of Solaris/AIX/HP-UX/True64 etc. install these libraries only
to get _one_ binary (e.g. "xpidl") working ?

2. libglib does not work on 64bit platforms. Known bug, no solution yet. See bug
91386

Comment 4

[Roland Mainz]

Reopen per previous comment.

At least 64bit users cannot use "xpidl" because libglib is broken on most (all
!?) 64bit platforms, including 64bit SPARC (=sparc v9)...

Comment 5

[cls]

1. Yes, they should.  A conscious decision was made to use libIDL so you must
use the dependencies that go along with it.  It is not impossible nor even hard
to compile libIDL & glib on those platforms.  

Also, xpidl is only required for mozilla-based development.  Unless you are
planning to ship a completely Mozilla development environment to build
mozilla-components, there's no need to ship xpidl with your version of Zilla.

2. WFM.  See bug 91386

Comment 6

[David Bradley]

Moving this out. I'm not sure what I can do with this, short of modifying libidl
to not use glib, no small feat.

Comment 7

[David Bradley]

Moving this out to the proper post 1.0 bucket

Comment 8

[David Bradley]

After further discussion it was decided 1.0.1 makes more sense as a post 1.0
milestone.

Comment 9

[David Bradley]

Retargetting to the proper post 1.0 milestone

Comment 10

[Axel Hecht]

I'm evaluating how bad it is to port libIDL to nspr. Should be possible.
Any suggestions on which version of libIDL to focus on?

Comment 11

[David Bradley]

Moving out to 1.3. If this needs to be in before 1.3 please comment.

Comment 12

[David Bradley]

Moving to 1.4 Alpha

Comment 13

[David Bradley]

Moving out

Comment 14

[David Bradley]

Updating the summary and checking to see if there is any movement.

I'm moving this out as well. If someone has a plan and a timeframe to address
this, please update the milestone on this.

Comment 15

[Axel Hecht]

I am swamped with other stuff. I started on porting libIDL to nspr once, but it 
wasn't too  comforting. Esp. the fact that we need the glib1.2 based libIDL makes
things awkward, as you have more tweaks in there for 64bit stuff, for example.
It was tedious, to say the least.

Comment 16

[David Bradley]

Moving out

Comment 17

[Eyal Rozenberg]

How come libIDL depends on glib? Maybe libIDL itself can be built so as not to depend on glib?

Comment 18

[Makoto Kato [:m_kato]]

no longer use libidl now since we swtich to pyidl