Post by Dave YeoPost by A.D. FundumPost by A.D. FundumAnd it still cannot load URP0.DLL: "DLL could not be loaded, error 87,
After copying PNG1616.DLL and Z.DLL (not using the RPM files) to the
Firefox directory the DLL can be loaded, but now there's a
SYSxxxx-error. I'm not using virtual hardware.
03-11-2015 20:31:19 SYS2070 PID 033a TID 0001 Slot 00a8
D:\TEST\FIREFOX\FIREFOX.EXE
XUL->STDCPP6.__ZSt24__throw_out_of_range_fmtPKcz
127
------------------------------------------------------------
03-11-2015 20:31:19 SYS3170 PID 033a TID 0001 Slot 00a8
D:\TEST\FIREFOX\FIREFOX.EXE
c0010001
125b8170
EAX=00000000 EBX=fffffff4 ECX=fffffffe EDX=fffffffc
ESI=15f30138 EDI=00000000
DS=0053 DSACC=f0f3 DSLIM=ffffffff
ES=0053 ESACC=f0f3 ESLIM=ffffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:1d73021a CSACC=f0df CSLIM=ffffffff
SS:ESP=0053:0012ff14 SSACC=f0f3 SSLIM=ffffffff
EBP=0012ff70 FLG=00012246
XUL.DLL 0001:020b8170
Solved: I also had to update STDCPP6.DLL.
So, compared to a former working install, I had to install (Dave's)
GCC1.DLL, URP0.DLL (Dave's link), Z.DLL (ZIP version of the RPM file
of the press release), PNG1616.DLL (ZIP version of the RPM file of the
press release), and I had to update STDCPP6.DLL (probably Ian's).
Thanks for catching that STDCPP6 has changed again :(
I'm left wondering about SM and TB. The one I'm posting from doesn't
have so many dependencies and can be reduced further.
Keep using mzfntcfgft, no need for the png dependency, statically link
pthread, rebuild mmap and use statically linked gcc all the way is one idea
Dave
I have been working on making a WarpIn installer for FF 24.8.1, beta
4, but the dependencies are a bit of a problem. So far, it seems that
one needs about 4 different packages to get them all, or use YUM
(which i really object to). I am not sure what the real answer is, but
I do know that distributing the dependencies in the way that is being
done, is asking for trouble, eventually. The user may get Firefox
working today, but doing so may break other things, and chances are
that something will break eventually anyway.
The biggest "problem" (other than users thinking they know better)
seems to be that some programmers have been distibuting some of this
stuff in parts, with their work. That eventually results in multiple
copies of DLLs (also caused by YUM, if you use it). That works okay,
until a user starts a program that uses a down level DLL, and then
tries to use a program that requires a higher level DLL. It may partly
work, or more likely, it will fail. If you happen to get the up level
DLL loaded first, everything may work. The only answer seems to be to
get the very latest stuff, and get rid of ALL of the other copies,
everywhere on your system. Using YUM just makes things worse, because
it takes no steps to remove down level versions of anything that may
exist in other places.
I note that Dave Yeo recently released a file that contains the
forwarder DLLs for GCC446 and GCC473, along with GCC1. That,
unfortunately, is only a part of the whole package. There are
forwarder DLLs for the rest of the GCC DLLs, which should really be
included. Without them, you have only a partial GCC1 installation.
While that may not cause trouble today, it may, eventually, cause a
problem.
I will also note that the AOO-4111-GA-rpm.wpi that is distributed for
AOO4, puts system DLLs into the AOO4\program directory, when they
should be in either \eCS\DLL, or \OS2\DLL (depending on what you
have). That has already started to cause grief because most LibPath
staements have one of the "official" DLL directories before the AOO4
directory (which probably isn't even in LibPath). Meaning that if the
working directory is AOO4\program, AOO4 will work (but only if it is
the first one started). If you start something else first, and it
loads a down level DLL from the "official" location, AOO4 won't work.
I am not really sure what the answer is. YUM is supposed to look after
such things, and it does, to a certain extent, but it does not remove
down level stuff from the "official" locations, so it depends on which
one gets started first. YUM also intorduces a new "official" location
(@UNIXROOT/usr/lib), which complicates the whole theng, even more. Yum
has also been somewhat unreliable, and it is difficult to actually
tell if it works, or not, unless you inspect every word that it churns
out. Arca Noae has been working on a package manager, which should
help the average user to use YUM, but it can only be as good as YUM
is, and that is not an impressive record during testing.
Another complication is that most, if not all, of the stuff
distributed by YUM does not have BLDLEVEL information, so it is really
impossible to tell what version any particular file is. YUM keeps a
databse of that information, but it doesn't really know if the file
got changed in some other way.
For now, I am tempted to just release Firefox 24.8.1 as a WarpIn
archive, without dependency checking, and let the user figure it out
(good luck). FF does work okay, with all of the packages installed,
but that will eventually cause problems, unless a user is very careful
about what gets updated, and when. It is also possible that installing
all of the dependencies will break something else, although, from what
I have heard, that usually happens when a user (or some package
distribution) has put DLLs into the wrong location.
Meanwhile, I would suggest that users start looking for stray DLLs,
that are duplicate file names of what is in \eCS\DLL, and/or OS2\DLL.
Get rid of them, before they cause problems (if they aren't already).
Note that those files don't have to be in LibPath to cause problems.
Then, take steps to get the latest versions of what is in the
"official" locations. Of course, you need to be sure that whatever
program was using the old DLLs, still works. If it doesn't you may
need to make it use a down level DLL, which should be possible if you
use LIBPATHSTRICT (I haven't tried it), or get the program updated to
use a later DLL.
Unfortunately, it seems that developers are not interested in doing
this properly, so a user needs to compensate for that, and clean out
the cruft so that it doesn't cause problems (I suspect that it will
anyway).
Hope some of this helps somebody...
--
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)