Linux xpinstall and libjar components can't load due to missing zlib



19 years ago
14 years ago


(Reporter: samir_bugzilla, Assigned: samir_bugzilla)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: 06/02)


(1 attachment)



19 years ago
When the XPInstall engine is run from the Linux installer, loading the xpisntall 
and libjar components fail because zlib is apparently missing.  Initial review 
reveals that teh linkage has not changed.


19 years ago
Keywords: nsbeta2
Priority: P3 → P1
Target Milestone: --- → M17

Comment 1

19 years ago
The Linux installer is currently broken due to this.  It could be a pckaging 

Comment 2

19 years ago
The linkage was changed to use the shared version of zlib if it was around.  
This broke us.  Consulting if we can back this out or if he will 
fix the horkage.  Either way, this should be fixed by tomorrow's verification 
Whiteboard: 06/02

Comment 3

19 years ago
I think this is just a packaging issue.  Moving bin/ from the
[browser] to the [xpcom] section of packages-unix should fix the problem.  

Comment 4

19 years ago
This is not a packaging issue.  Day before's reveals no dependency
on but yesterday's reveals that it is dynamically linked.  This is
clealrly due to your changes to

Before pinging you, I tried moving zlib to xpcom, the obvious route, to no
avail.  I've moved it to both the bin and the components dir (since component
loading was failing).  The problem is that people have zlib lying around on
their machines because it is so common.  We are not guaranteed the correct
version and so we statically link.

I am assuming that your changes were not to resurrect a platform or you would
have voiced the same.  I am going to back your changes out now.  Not sure why
you made the changes.  If you can elaborate on teh reason I'll no what I'm
impacting.  Thanks.

Comment 5

19 years ago
Linkage rules reverted.  Fixed.  Probably won't show up till tonight's 8pm
builds per granrose.
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 6

19 years ago
I think you misunderstood.  I said I believe it's a packaging issue because is not included in the xpcom package and clearly libxpinstall &
libjar50 have dependencies upon  It was indeed caused by changes I

You are correct; the changes I made were not made to resurrect a platform but to
reduce the amount of duplicate code in the tree due to linking against static
libs.  We should not be statically linking in libraries unless they are linked
in a single place against a common base library (ala libreg & libxpcom).  Since
zlib is used by at least xpinstall & libjar, it's a perfect candidate for
dynamic linking.  

Preexisting installations of zlib should not be a problem.  In just about every
unix installation of zlib I've seen, the library is named 'libz.{a,so}' but for
some reason we decided to use 'libzlib.{a,so}' instead.  Also, if I'm not
mistaken, the script that runs the installer/mozilla sets the LD_LIBRARY_PATH so
that the mozilla versions of the libraries are preferred over the system
versions.  (Using major & minor version numbers on our libraries would help to
lower confusion as well, but I digress.)

I did a bit of searching last night but I couldn't figure out how to create the
xpcom.xpi file so I could test the changes I proposed.  Could you point me to a
doc that explains how to do that?


Comment 8

19 years ago
I did not misunderstand.  Like I said, I tried moving zlib into xpcom.xpi.  
There were some LD_LIBRARY_PATH problems still even though my script puts . 
first as you pointed out.  There may be a solution to use zlib dynamically.  My 
point here is this:  the static linkage reasons I have given are clearly weak 
(pretty lame actually, I admit).  However, I don't have cycles in the near 
future to resolve this.  If you would like to look into it I would encourage you 
to do so.  Then reinstate your changes (which I undid this morning, btw).

To build the installer all you need to do is run with no args.
* cd to the [...]/packager/unix dir and run the script from there. 
* the installer is delivered in raw form to mozilla/installer/raw with the .xpis 
right next to it in the "xpi" dir.  You can modify these .xpis (plain old zip 
archives).  Keep us posted here if you take up this chore.  Thanks.

Comment 9

19 years ago
Is there any other file that determines which .so to use in the installer
besides packages-unix ?  After running the deliver script (which doesn't seem to
work for objdir builds btw), I found that is actually being put in
the xpcom.xpi archive, but it's not being extracted by the installer program.

GetFactory(/tmp/installer/.tmp.xi.0/bin/components/ Load FAILED
with error: cannot open shared object file: No such file or
sinking:installer> unzip -v .tmp.xi.0/xpcom.xpi | grep zlib
  135763  Defl:N    47665  65%  06-02-00 19:38  4e72391d  bin/
sinking:installer> find .tmp.xi.0 -name '*zlib*'

Comment 10

19 years ago
Ok, found the problem.  The installer engine has the core xpcom files hardcoded
into it.  This small patch fixes the zlib problem. 

Comment 11

19 years ago
Created attachment 9557 [details] [diff] [review]
Adds bin/ to list of core files

Comment 12

19 years ago
Oops.  Thanks for looking into it.  I'll make the changes.
Resolution: FIXED → ---


19 years ago

Comment 13

19 years ago
Patch checked in and zlib rules reverted to Chris' original changes to use the 
shared object when present.  The installer should work.
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED

Comment 14

19 years ago
ok on build 2000060508- 
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.