"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
Umm, xpidl requires glib because libIDL requires glib and xpidl requires libIDL. Why is this considered a bug?
I'm with cls. Marking this invalid. REopen if you can make some case for why it should be different.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → INVALID
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
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)...
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
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
Moving this out. I'm not sure what I can do with this, short of modifying libidl to not use glib, no small feat.
Target Milestone: --- → mozilla1.0.1
Moving this out to the proper post 1.0 bucket
Target Milestone: mozilla1.0.1 → mozilla1.1
After further discussion it was decided 1.0.1 makes more sense as a post 1.0 milestone.
Target Milestone: mozilla1.1 → mozilla1.0.1
Retargetting to the proper post 1.0 milestone
Target Milestone: mozilla1.0.1 → mozilla1.2
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?
Moving out to 1.3. If this needs to be in before 1.3 please comment.
Target Milestone: mozilla1.2alpha → mozilla1.3alpha
Moving to 1.4 Alpha
Target Milestone: mozilla1.3alpha → mozilla1.4alpha
Target Milestone: mozilla1.4alpha → mozilla1.5alpha
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.
Summary: "xpidl" requires libglib... → Remove/replace xpidl's use of libglib...
Target Milestone: mozilla1.5alpha → mozilla1.6alpha
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.
Target Milestone: mozilla1.6alpha → mozilla1.7alpha
How come libIDL depends on glib? Maybe libIDL itself can be built so as not to depend on glib?
no longer use libidl now since we swtich to pyidl
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago → 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.