Discussion:
FF38 req. DLLs
(too old to reply)
A.D. Fundum
2016-02-22 23:48:38 UTC
Permalink
So far (the undocumented?) EXPAT7.DLL, GTHR2.DLL and INTL8.DLL are
also required...


--
A.D. Fundum
2016-02-23 00:09:28 UTC
Permalink
Post by A.D. Fundum
So far (the undocumented?) EXPAT7.DLL, GTHR2.DLL and INTL8.DLL
are also required...
And, finally, STDCPP.DLL.


--
A.D. Fundum
2016-02-23 00:45:10 UTC
Permalink
Post by A.D. Fundum
And, finally, STDCPP.DLL.
Is there a ZIP version of the bleedin' RPM-only packages in the
README.OS2 file?

Now it looks like FF38 cannot load a STDCPP.DLL of 26-7-2013 and/or a
STDCPP6.DLL of 2-2-2015, albeit there's no error message to support
such a claim. Or is there yet another undocumented, missing and/or
updated DLL?


--
Dave Yeo
2016-02-23 02:32:16 UTC
Permalink
Post by A.D. Fundum
Post by A.D. Fundum
And, finally, STDCPP.DLL.
Is there a ZIP version of the bleedin' RPM-only packages in the
README.OS2 file?
Now it looks like FF38 cannot load a STDCPP.DLL of 26-7-2013 and/or a
STDCPP6.DLL of 2-2-2015, albeit there's no error message to support
such a claim. Or is there yet another undocumented, missing and/or
updated DLL?
There's Fontconfig, Pango, Cairo, Pixman, maybe glib and perhaps more.
I have to build to double check as my current build has some of the
above statically linked.
SM2.35a1 and Fontconfig available on my Bitbucket 31ESR page
Dave
A.D. Fundum
2016-02-23 09:34:29 UTC
Permalink
Post by Dave Yeo
maybe glib
INSTALL ... 'glib2.dll', 'gobj2.dll', 'gmod2.dll'
The glib ZIP package is mentioned in README.OS2, but its GTHR2.DLL
isn't.

FWIW, I've moved (work in progress) new DLLs to the LIBPATH, except
Z.DLL and a new FREETYP6.DLL which doesn't work with the installed SM.
Post by Dave Yeo
SM2.35a1 and Fontconfig available on my Bitbucket 31ESR
page
Thanks, SM is more important than FF and I do prefer static linking,
for one to avoid this "complicated" mess.

At the moment FF just produces beeps. With an adjust PM DLL STARTUPDIR
to use the right "." directory, PM DLL claims PLUGIN-CONTAINER.EXE
cannot load STDCPP6.DLL.

The PLUGIN-CONTAINER.EXE also cannot load MOZALLOC.DLL, NSS3.DLL,
PTHR01.DLL, SSL3.DLL, MMAP.DLL, PIXMAN10.DLL, MOZSQLT3.DLL,
CAIRO2.DLL, PANGO100.DLL, KAI0.DLL, and SMIME3.DLL.

Yesterday it looked like it worked with PM DLL, after copying
STDCPP.DLL to "." too, but it never really worked. It may have been
some PM DLL bug.

FWIW, I've only installed know, documented packages. For example, I
haven't verified if I should update GCC473,DLL, and so on. I'm almost
installing it as if I'm a new user, without an install whcih is
guaranteed to be fully up-to-date. All installed DLLs are verified,
only SM could cause a conflict but I haven't used that, nor games with
an own Z.DLL version.


--
Dave Yeo
2016-02-24 02:53:17 UTC
Permalink
Post by A.D. Fundum
Post by Dave Yeo
maybe glib
INSTALL ... 'glib2.dll', 'gobj2.dll', 'gmod2.dll'
The glib ZIP package is mentioned in README.OS2, but its GTHR2.DLL
isn't.
gthreads are part of glib2 and really should be in the same zip.
Post by A.D. Fundum
FWIW, I've moved (work in progress) new DLLs to the LIBPATH, except
Z.DLL and a new FREETYP6.DLL which doesn't work with the installed SM.
The new freetype dll should work with the last few releases and co-exist
with the mzfntcfgft DLLs
Post by A.D. Fundum
Post by Dave Yeo
SM2.35a1 and Fontconfig available on my Bitbucket 31ESR
page
Thanks, SM is more important than FF and I do prefer static linking,
for one to avoid this "complicated" mess.
https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.35a1.en.os2.zip
Post by A.D. Fundum
At the moment FF just produces beeps. With an adjust PM DLL STARTUPDIR
to use the right "." directory, PM DLL claims PLUGIN-CONTAINER.EXE
cannot load STDCPP6.DLL.
Have you got the most recent STDCPP6.DLL, IIRC it has been updated along
with the GCC* DLLs. New one will work for where the old one was needed.
Post by A.D. Fundum
The PLUGIN-CONTAINER.EXE also cannot load MOZALLOC.DLL, NSS3.DLL,
PTHR01.DLL, SSL3.DLL, MMAP.DLL, PIXMAN10.DLL, MOZSQLT3.DLL,
CAIRO2.DLL, PANGO100.DLL, KAI0.DLL, and SMIME3.DLL.
Most of those are mozilla DLLs and Mozilla can find them by itself.
pthr01, mmap, pixman10, cairo2, pango100 and kai0 should be on the libpath.
Post by A.D. Fundum
Yesterday it looked like it worked with PM DLL, after copying
STDCPP.DLL to "." too, but it never really worked. It may have been
some PM DLL bug.
FWIW, I've only installed know, documented packages. For example, I
haven't verified if I should update GCC473,DLL, and so on.
You need gcc1.dll along with its various forwarders such as gcc473.dll,
not the original gcc473.dll. Turns out all the GCC dlls are
interchangeable and should have been GCC1.DLL to start with.
Post by A.D. Fundum
I'm almost
installing it as if I'm a new user, without an install whcih is
guaranteed to be fully up-to-date. All installed DLLs are verified,
only SM could cause a conflict but I haven't used that, nor games with
an own Z.DLL version.
BTW, plugin-container.exe doesn't correctly work yet (it's used to run
Flash in its own process space). What you should point PMDLL at is
XUL.DLL which will show you all the needed DLLs and with SeaMonkey
running the only ones in red are the Mozilla ones.
Dave
ivan
2016-02-24 14:53:25 UTC
Permalink
Post by Dave Yeo
Post by A.D. Fundum
Post by Dave Yeo
maybe glib
INSTALL ... 'glib2.dll', 'gobj2.dll', 'gmod2.dll'
The glib ZIP package is mentioned in README.OS2, but its GTHR2.DLL
isn't.
gthreads are part of glib2 and really should be in the same zip.
Post by A.D. Fundum
FWIW, I've moved (work in progress) new DLLs to the LIBPATH, except
Z.DLL and a new FREETYP6.DLL which doesn't work with the installed SM.
The new freetype dll should work with the last few releases and co-exist
with the mzfntcfgft DLLs
Post by A.D. Fundum
Post by Dave Yeo
SM2.35a1 and Fontconfig available on my Bitbucket 31ESR
page
Thanks, SM is more important than FF and I do prefer static linking,
for one to avoid this "complicated" mess.
https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.35a1.en.os2.zip
Post by A.D. Fundum
At the moment FF just produces beeps. With an adjust PM DLL STARTUPDIR
to use the right "." directory, PM DLL claims PLUGIN-CONTAINER.EXE
cannot load STDCPP6.DLL.
Have you got the most recent STDCPP6.DLL, IIRC it has been updated along
with the GCC* DLLs. New one will work for where the old one was needed.
Post by A.D. Fundum
The PLUGIN-CONTAINER.EXE also cannot load MOZALLOC.DLL, NSS3.DLL,
PTHR01.DLL, SSL3.DLL, MMAP.DLL, PIXMAN10.DLL, MOZSQLT3.DLL,
CAIRO2.DLL, PANGO100.DLL, KAI0.DLL, and SMIME3.DLL.
Most of those are mozilla DLLs and Mozilla can find them by itself.
pthr01, mmap, pixman10, cairo2, pango100 and kai0 should be on the libpath.
Post by A.D. Fundum
Yesterday it looked like it worked with PM DLL, after copying
STDCPP.DLL to "." too, but it never really worked. It may have been
some PM DLL bug.
FWIW, I've only installed know, documented packages. For example, I
haven't verified if I should update GCC473,DLL, and so on.
You need gcc1.dll along with its various forwarders such as gcc473.dll,
not the original gcc473.dll. Turns out all the GCC dlls are
interchangeable and should have been GCC1.DLL to start with.
Post by A.D. Fundum
I'm almost
installing it as if I'm a new user, without an install whcih is
guaranteed to be fully up-to-date. All installed DLLs are verified,
only SM could cause a conflict but I haven't used that, nor games with
an own Z.DLL version.
BTW, plugin-container.exe doesn't correctly work yet (it's used to run
Flash in its own process space). What you should point PMDLL at is
XUL.DLL which will show you all the needed DLLs and with SeaMonkey
running the only ones in red are the Mozilla ones.
Dave
The more I see of this the more I think that either firefox should be
compiled with static linking or there should be a zip made available
with the correct DLLs for that version (a RPM could also be made
available with the DLLs for those that use it).

The way this is going we are going to end up with some programs
requiring one version of the DLL and other programs requiring another
version of the same DLL.

I have already seen this with TAME no longer working on some updated
boxes but still working on unupdated ones.

ivan
--
A.D. Fundum
2016-02-27 21:56:45 UTC
Permalink
Post by Dave Yeo
Post by A.D. Fundum
The glib ZIP package is mentioned in README.OS2,
but its GTHR2.DLL isn't.
gthreads are part of glib2 and really should be in the same zip.
Yes, but initially I only installed DLLs mentioned in README.OS2
Post by Dave Yeo
The new freetype dll should work with the last few releases
and co-exist with the mzfntcfgft DLLs
Allright.
Post by Dave Yeo
Post by A.D. Fundum
The PLUGIN-CONTAINER.EXE also cannot load MOZALLOC.DLL,
NSS3.DLL, PTHR01.DLL, SSL3.DLL, MMAP.DLL, PIXMAN10.DLL,
MOZSQLT3.DLL, CAIRO2.DLL, PANGO100.DLL, KAI0.DLL, and
SMIME3.DLL.
Most of those are mozilla DLLs and Mozilla can find them by itself.
Now PM DLL claims that FF can load all DLLs. Maybe it was a PM DLL
bug.
Post by Dave Yeo
What you should point PMDLL at is XUL.DLL which will show
you all the needed DLLs and with SeaMonkey running the
only ones in red are the Mozilla ones.
I've pointed PM DLL at all DLLs and EXEs. PLUGIN-CONTAINER.EXE was (?)
the only one with red names. Out-of-the-box FF nor SM works. So far I
haven't seen red entries with SM, but that may be related to your
appriciated efforts w.r.t. static linking.

PM DLL tips & tricks, possibly outdated: the "." is in my LIBATH. With
PM DLL v2.11, a PM DLL program object assumes that "." is the PM DLL
directory instead of the directory of an examined DLL/EXE. I do change
the "working directory" (STARTUPDIR) to the directory of FF/SM first ,
so "." represents the relevant directory and PM DLL won't show red
entries. Of course PM DLL's interpretation of "." is technically
right, but there's no reason to presume that PM DLL's directory is a
better and more relevant choice than the directory of an examined
DLL/EXE. I haven't checked v2.12 yet, but otherwise a drag & drop
wrapper could be written to use the directory of the dropped DLL/EXE
instead of PM DLL's (should be quite easy with e.g. VX-REXX if VX-REXX
can execute PM DLL, FWW).


--
Dave Yeo
2016-02-28 03:46:20 UTC
Permalink
Post by A.D. Fundum
I've pointed PM DLL at all DLLs and EXEs. PLUGIN-CONTAINER.EXE was (?)
the only one with red names. Out-of-the-box FF nor SM works. So far I
haven't seen red entries with SM, but that may be related to your
appriciated efforts w.r.t. static linking.
It was actually more of an accident. Given more bandwidth, I would
produce 2 binaries with one being mostly statically linked
Post by A.D. Fundum
PM DLL tips & tricks, possibly outdated: the "." is in my LIBATH. With
PM DLL v2.11, a PM DLL program object assumes that "." is the PM DLL
directory instead of the directory of an examined DLL/EXE. I do change
the "working directory" (STARTUPDIR) to the directory of FF/SM first ,
so "." represents the relevant directory and PM DLL won't show red
entries. Of course PM DLL's interpretation of "." is technically
right, but there's no reason to presume that PM DLL's directory is a
better and more relevant choice than the directory of an examined
DLL/EXE. I haven't checked v2.12 yet, but otherwise a drag & drop
wrapper could be written to use the directory of the dropped DLL/EXE
instead of PM DLL's (should be quite easy with e.g. VX-REXX if VX-REXX
can execute PM DLL, FWW).
I'm pretty sure that Mozilla doesn't use the "." or Libpath at all
besides finding system DLLs (including the RPM ones). Note that
SeaMonkey still has one DLL (suite.dll) under components and if the
lightning extension is installed (automatic now), there is a DLL under
the extensions directory.
Fontconfig also has code to find where the DLL is installed and find its
configuration that way but our port is not linked against DLL_INIT (or
is that DLL_TERM?) so doesn't work on OS/2.
Dave
A.D. Fundum
2016-02-29 15:00:39 UTC
Permalink
Post by Dave Yeo
I'm pretty sure that Mozilla doesn't use the "." or Libpath at all
Restricted to the ".", the real "." can be anything indeed. In this
case a better description perhaps is that the "." represents a sane
working directory of an app, but that third-party software which
checks DLLs may ignore the likely use of that directory.

If e.g. PM DLL claims that SEAMONKEY.EXE cannot load SM's XUL.DLL,
then PM DLL is right nor wrong. Typically SEAMONKEY.EXE will be able
to load XUL.DLL in the same SM directory, so PM DLL could show a
conditional warning instead of an error because it assumes that the
(variable) "." is the current directory of SM.

I still may try to write a drop target which assumes that a "."
represents the directory of the dropped DLL/EXE, regardless of the
LIBPATH, so PM DLL can report that A:\TEST.EXE can load A:\TEST.DLL by
using its directory A:\ instead of PM DLL's C:\UTILS\PMDLL. So I'll CD
to A:\, and then execute "C:\UTILS\PMDLL\PMDLL.EXE A:\TEST.EXE".
Post by Dave Yeo
our port is not linked against DLL_INIT (or is that DLL_TERM?)
Yes, if the "or" is not an XOR. It's all of the above: DLL_InitTerm


--
A.D. Fundum
2016-02-29 15:18:25 UTC
Permalink
Given more bandwidth, I would produce 2 binaries with one
being mostly statically linked
FWIW, with my setup the damage is already done by FF. FF (mainly
evaluation) >= SM (mainly production), so an awful lot of DLLs already
made it to my LIBPATH now.

So next time it may be harder to report undocumented, required DLLs,
because there's more "polution" in my LIBPATH than before this
dynamically linked version of FF.

FWIW/2, an older version of QupZilla stopped working. IIRC due to an
updated GCC* DLL. Upgrading QupZilla to v1.8.0 solved that minor issue
(newer versions of QupZilla required yet another unclear package). So
far that was the only derived issue (without using some test policy).


--
ivan
2016-03-01 20:27:51 UTC
Permalink
Post by A.D. Fundum
Given more bandwidth, I would produce 2 binaries with one
being mostly statically linked
FWIW, with my setup the damage is already done by FF. FF (mainly
evaluation) >= SM (mainly production), so an awful lot of DLLs already
made it to my LIBPATH now.
So next time it may be harder to report undocumented, required DLLs,
because there's more "polution" in my LIBPATH than before this
dynamically linked version of FF.
FWIW/2, an older version of QupZilla stopped working. IIRC due to an
updated GCC* DLL. Upgrading QupZilla to v1.8.0 solved that minor issue
(newer versions of QupZilla required yet another unclear package). So
far that was the only derived issue (without using some test policy).
--
We got round the problem of updating DLLs by having a dedicated DLL
directory in which to put them. We have a backup of that directory
from when we knew all the programs we use work, thus if when the DLLs
are 'updated' and something we use stops working we blowaway the dir
and restore from backup. So far that has not failed but I expect
there will come a time when we will have to use drastic measures to
keep everything working.


--
A.D. Fundum
2016-03-03 02:39:18 UTC
Permalink
a drag & drop wrapper could be written to use the directory
of the dropped DLL/EXE instead of PM DLL's
Done, FWIW: /pub/incoming/whatisthedot.zip @ Hobbes (8 KiB).

With e.g. SM's XUL.DLL it will often reduce the number of PM DLL's red
errors by using the directory of XUL.DLL as PM DLL's working
directory. It's quite common that a DLL can be found in the same
non-LIBPATH directory.

Animals were harmed during the production, but I have nothing to do
with that.


--

Dave Yeo
2016-02-24 03:01:16 UTC
Permalink
Post by A.D. Fundum
Post by Dave Yeo
maybe glib
INSTALL ... 'glib2.dll', 'gobj2.dll', 'gmod2.dll'
The glib ZIP package is mentioned in README.OS2, but its GTHR2.DLL
isn't.
gthreads are part of glib2 and really should be in the same zip.
Post by A.D. Fundum
FWIW, I've moved (work in progress) new DLLs to the LIBPATH, except
Z.DLL and a new FREETYP6.DLL which doesn't work with the installed SM.
The new freetype dll should work with the last few releases and co-exist
with the mzfntcfgft DLLs
Post by A.D. Fundum
Post by Dave Yeo
SM2.35a1 and Fontconfig available on my Bitbucket 31ESR
page
Thanks, SM is more important than FF and I do prefer static linking,
for one to avoid this "complicated" mess.
https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.35a1.en.os2.zip
Post by A.D. Fundum
At the moment FF just produces beeps. With an adjust PM DLL STARTUPDIR
to use the right "." directory, PM DLL claims PLUGIN-CONTAINER.EXE
cannot load STDCPP6.DLL.
Have you got the most recent STDCPP6.DLL, IIRC it has been updated along
with the GCC* DLLs. New one will work for where the old one was needed.
Post by A.D. Fundum
The PLUGIN-CONTAINER.EXE also cannot load MOZALLOC.DLL, NSS3.DLL,
PTHR01.DLL, SSL3.DLL, MMAP.DLL, PIXMAN10.DLL, MOZSQLT3.DLL,
CAIRO2.DLL, PANGO100.DLL, KAI0.DLL, and SMIME3.DLL.
Most of those are mozilla DLLs and Mozilla can find them by itself.
pthr01, mmap, pixman10, cairo2, pango100 and kai0 should be on the libpath.
Post by A.D. Fundum
Yesterday it looked like it worked with PM DLL, after copying
STDCPP.DLL to "." too, but it never really worked. It may have been
some PM DLL bug.
FWIW, I've only installed know, documented packages. For example, I
haven't verified if I should update GCC473,DLL, and so on.
You need gcc1.dll along with its various forwarders such as gcc473.dll,
not the original gcc473.dll. Turns out all the GCC dlls are
interchangeable and should have been GCC1.DLL to start with.
Post by A.D. Fundum
I'm almost
installing it as if I'm a new user, without an install whcih is
guaranteed to be fully up-to-date. All installed DLLs are verified,
only SM could cause a conflict but I haven't used that, nor games with
an own Z.DLL version.
BTW, plugin-container.exe doesn't correctly work yet (it's used to run
Flash in its own process space). What you should point PMDLL at is
XUL.DLL which will show you all the needed DLLs and with SeaMonkey
running the only ones in red are the Mozilla ones.
Dave
Dave Parsons
2016-02-25 15:25:21 UTC
Permalink
Hi Dave,
Post by Dave Yeo
Post by A.D. Fundum
At the moment FF just produces beeps. With an adjust PM DLL STARTUPDIR
to use the right "." directory, PM DLL claims PLUGIN-CONTAINER.EXE
cannot load STDCPP6.DLL.
Have you got the most recent STDCPP6.DLL, IIRC it has been updated along
with the GCC* DLLs. New one will work for where the old one was needed.
You need gcc1.dll along with its various forwarders such as gcc473.dll, not the original gcc473.dll. Turns out all the GCC dlls are interchangeable and should have been GCC1.DLL to start with.
The latest versions of stdcpp6, gcc1 & gcc473 that I can find are all
dated 2 Feb 2015.
Do you mean newer than these?

I am also trying to get FF 38.2.1 to work but at the moment it starts
to load & after about 5 seconds or so it beeps and quits.
There was nothing on the screen but it produced a TRP file and output
via stdout/stderr these few lines:-
Post by Dave Yeo
Fontconfig error: Cannot load default config file
DIVE is disabled - Panorama's shadow-buffer is enabled
Fontconfig error: Cannot load default config file
Fontconfig error: Cannot load default config file
Fontconfig error: Cannot load default config file
Fontconfig warning: ignoring en_GB_EURO: not a valid region tag
Fontconfig error: Cannot load default config file
Fontconfig error: Cannot load default config file
Fontconfig error: Cannot load default config file
Fontconfig error: Cannot load default config file
Creating 031E_01.TRP
Killed by SIGSEGV
Any idea which file it is referring to?

The TRP file says it is trying to read from 00000018 & shows this:-

Call Stack
______________________________________________________________________

EBP Address Module Obj:Offset Nearest Public Symbol
-------- --------- -------- ------------- -----------------------
Trap -> 0E04991E XUL 0001:00D0991E nsExpirationTracker.h#34 __ZN17gfxPangoFontGroup17GetFirstValidFontEj + 21E 0001:00D09700
(D:\Coding\mozilla\master\gfx\thebes\gfxPangoFonts.cpp)

Lost Stack chain - invalid EBP 40000000

I've been round all the DLLs mentioned in the readme and a few which
aren't and they all seem to be up-to-date. Presumably there is one
that isn't, but which?

Cheers,
Dave P.
Dave Yeo
2016-02-25 16:26:06 UTC
Permalink
Post by Dave Parsons
Hi Dave,
Post by Dave Yeo
Post by A.D. Fundum
At the moment FF just produces beeps. With an adjust PM DLL STARTUPDIR
to use the right "." directory, PM DLL claims PLUGIN-CONTAINER.EXE
cannot load STDCPP6.DLL.
Have you got the most recent STDCPP6.DLL, IIRC it has been updated along
with the GCC* DLLs. New one will work for where the old one was needed.
You need gcc1.dll along with its various forwarders such as
gcc473.dll, not the original gcc473.dll. Turns out all the GCC dlls
are interchangeable and should have been GCC1.DLL to start with.
The latest versions of stdcpp6, gcc1 & gcc473 that I can find are all
dated 2 Feb 2015.
Do you mean newer than these?
Mine are all from 2 Feb 2015.
Post by Dave Parsons
I am also trying to get FF 38.2.1 to work but at the moment it starts
to load & after about 5 seconds or so it beeps and quits.
There was nothing on the screen but it produced a TRP file and output
via stdout/stderr these few lines:-
Post by Dave Yeo
Fontconfig error: Cannot load default config file
DIVE is disabled - Panorama's shadow-buffer is enabled
Fontconfig error: Cannot load default config file
Fontconfig error: Cannot load default config file
Fontconfig error: Cannot load default config file
Fontconfig warning: ignoring en_GB_EURO: not a valid region tag
What is your codepage and LANG settings?
Post by Dave Parsons
Post by Dave Yeo
Fontconfig error: Cannot load default config file
Fontconfig error: Cannot load default config file
Fontconfig error: Cannot load default config file
Fontconfig error: Cannot load default config file
Creating 031E_01.TRP
Killed by SIGSEGV
Any idea which file it is referring to?
The TRP file says it is trying to read from 00000018 & shows this:-
Call Stack
______________________________________________________________________
EBP Address Module Obj:Offset Nearest Public Symbol
-------- --------- -------- ------------- -----------------------
Trap -> 0E04991E XUL 0001:00D0991E nsExpirationTracker.h#34
__ZN17gfxPangoFontGroup17GetFirstValidFontEj + 21E 0001:00D09700
(D:\Coding\mozilla\master\gfx\thebes\gfxPangoFonts.cpp)
Lost Stack chain - invalid EBP 40000000
I've been round all the DLLs mentioned in the readme and a few which
aren't and they all seem to be up-to-date. Presumably there is one
that isn't, but which?
How did you install Fontconfig? By default it needs to be installed in
@UNIXROOT/usr, @UNIXROOT/etc and @UNIXROOT/var.
It should also work with everything installed in %HOME%, need to test
though.
What happens if you run fc-list.exe (the fc-* executables should be on
the PATH).Running fc-cache.exe --verbose is another test you can do.
Should show where it is looking for its configuration.
Dave
Dave Parsons
2016-02-26 09:46:47 UTC
Permalink
Post by Dave Yeo
Post by Dave Parsons
I've been round all the DLLs mentioned in the readme and a few which
aren't and they all seem to be up-to-date. Presumably there is one
that isn't, but which?
How did you install Fontconfig? By default it needs to be installed in
@UNIXROOT/usr, @UNIXROOT/etc and @UNIXROOT/var.
It should also work with everything installed in %HOME%, need to test though.
What happens if you run fc-list.exe (the fc-* executables should be on the
PATH).Running fc-cache.exe --verbose is another test you can do. Should show
where it is looking for its configuration.
Dave
Thanks Dave. I didn't use UNIXROOT previously and I only copied across the
dlls from \usr\lib.

Setting UNIXROOT and copying everything across got rid of the error messages
and fixed the crash.

Initial assessment, everything seems to work, fonts look a little better but
r followed by n still looks like m if displayed in bold.

However it hangs briefly when scrolling up & down with the mouse wheel on some
pages. It is particularly bad on http://www.bbc.com/news loading all the little
images. 31.8.0 does not have this problem.

Dave P.
Dave Yeo
2016-02-26 18:58:03 UTC
Permalink
Post by Dave Parsons
Post by Dave Yeo
Post by Dave Parsons
I've been round all the DLLs mentioned in the readme and a few which
aren't and they all seem to be up-to-date. Presumably there is one
that isn't, but which?
How did you install Fontconfig? By default it needs to be installed in
@UNIXROOT/usr, @UNIXROOT/etc and @UNIXROOT/var.
It should also work with everything installed in %HOME%, need to test though.
What happens if you run fc-list.exe (the fc-* executables should be on the
PATH).Running fc-cache.exe --verbose is another test you can do. Should show
where it is looking for its configuration.
Dave
Thanks Dave. I didn't use UNIXROOT previously and I only copied across the
dlls from \usr\lib.
Setting UNIXROOT and copying everything across got rid of the error messages
and fixed the crash.
As mentioned in a sibling post, it is possible to point at fonts.conf
Post by Dave Parsons
Initial assessment, everything seems to work, fonts look a little better but
r followed by n still looks like m if displayed in bold.
Fontconfig is also very configurable.
http://www.freedesktop.org/software/fontconfig/fontconfig-user.html
Post by Dave Parsons
However it hangs briefly when scrolling up & down with the mouse wheel on some
pages. It is particularly bad on http://www.bbc.com/news loading all the little
images. 31.8.0 does not have this problem.
Haven't really noticed this, perhaps partially due to using no-script. I
do see some heavy CPU usage displaying some scripts.
This is a bit of a weird version and hopefully the next upload will be
better.
Dave
Andreas Kohl
2016-02-25 16:53:18 UTC
Permalink
Post by Dave Parsons
The latest versions of stdcpp6, gcc1 & gcc473 that I can find are all
dated 2 Feb 2015.
Do you mean newer than these?
There's nothing newer.
Post by Dave Parsons
I am also trying to get FF 38.2.1 to work but at the moment it starts
to load & after about 5 seconds or so it beeps and quits.
There was nothing on the screen but it produced a TRP file and output
via stdout/stderr these few lines:-
Post by Dave Yeo
Fontconfig error: Cannot load default config file
Any idea which file it is referring to?
Path for fontconfig seems to hard coded to a location under /usr/share/...
Post by Dave Parsons
I've been round all the DLLs mentioned in the readme and a few which
aren't and they all seem to be up-to-date. Presumably there is one
that isn't, but which?
You also need dll files that are not mentioned in README.OS2. At least
EXPAT7.DLL, INTL8.DLL (from gettext).

--
Andreas
David Parsons
2016-02-25 18:46:53 UTC
Permalink
Post by Andreas Kohl
You also need dll files that are not mentioned in README.OS2. At least
EXPAT7.DLL, INTL8.DLL (from gettext).
Yes, thanks Andreas I saw those in an earlier post here. I only need
to add INTL8.

Dave P.
ivan
2016-02-25 23:39:34 UTC
Permalink
Post by Andreas Kohl
Post by Dave Parsons
The latest versions of stdcpp6, gcc1 & gcc473 that I can find are all
dated 2 Feb 2015.
Do you mean newer than these?
There's nothing newer.
Post by Dave Parsons
I am also trying to get FF 38.2.1 to work but at the moment it starts
to load & after about 5 seconds or so it beeps and quits.
There was nothing on the screen but it produced a TRP file and output
via stdout/stderr these few lines:-
Post by Dave Yeo
Fontconfig error: Cannot load default config file
Any idea which file it is referring to?
Path for fontconfig seems to hard coded to a location under /usr/share/...
That makes it very dificult for those of us that don't have a
?:\usr\share directory on our systems, or %unixroot% for that matter.

Now the question arrises, what is fontconfig used for and why would I
tell our clients that we need to put (install) it on their computers?

Does anything else use it other than firefox?
Post by Andreas Kohl
Post by Dave Parsons
I've been round all the DLLs mentioned in the readme and a few which
aren't and they all seem to be up-to-date. Presumably there is one
that isn't, but which?
You also need dll files that are not mentioned in README.OS2. At least
EXPAT7.DLL, INTL8.DLL (from gettext).
--
Andreas
ivan
--
Dave Yeo
2016-02-26 01:58:37 UTC
Permalink
Post by ivan
Post by Dave Parsons
Post by Dave Yeo
Fontconfig error: Cannot load default config file
Any idea which file it is referring to?
Path for fontconfig seems to hard coded to a location under/usr/share/...
That makes it very dificult for those of us that don't have a
?:\usr\share directory on our systems, or %unixroot% for that matter.
It's possible for it to use %HOME%, at that it used to be used that way.
Here fc-cache seems to have this search order,
R:\tmp>fc-cache -v
N:/OS2/OS2.INI: skipping, existing cache is valid: 140 fonts, 0 dirs
/@unixroot/usr/local/share/fonts: skipping, no such directory
/@unixroot/usr/share/fonts: skipping, no such directory
F:/home/dave/.local/share/fonts: skipping, no such directory
F:/home/dave/.fonts: skipping, no such directory
/@unixroot/var/cache/fontconfig: cleaning cache directory
F:/home/dave/.cache/fontconfig: not cleaning non-existent cache directory
F:/home/dave/.fontconfig: not cleaning non-existent cache directory
K:\usr\bin\fc-cache.exe: succeeded

I need to experiment.
Post by ivan
Now the question arrises, what is fontconfig used for and why would I
tell our clients that we need to put (install) it on their computers?
It's used to catalog the fonts on the system and find the best match.
It' actually a pretty powerful utility.
Post by ivan
Does anything else use it other than firefox?
Many *nix ports use it. Firefox has been using it since 3.6 IIRC, first
fontconfig 2.3.2, then Peter and Doodle wrote the OS/2 specific
mzfntcfg, which was sorta a stripped down Fontconfig to get away from
the configuration stuff. Now Firefox's font handling stuff has changed
enough that mzfntcfg doesn't handle it and we've gone back to the real
Fontconfig.
Dave
Dave Yeo
2016-02-26 04:50:11 UTC
Permalink
Post by ivan
Post by Dave Parsons
I am also trying to get FF 38.2.1 to work but at the moment it starts
to load & after about 5 seconds or so it beeps and quits.
There was nothing on the screen but it produced a TRP file and output
via stdout/stderr these few lines:-
Post by Dave Yeo
Fontconfig error: Cannot load default config file
Any idea which file it is referring to?
Path for fontconfig seems to hard coded to a location under/usr/share/...
That makes it very dificult for those of us that don't have a
?:\usr\share directory on our systems, or %unixroot% for that matter.
You can use %FONTCONFIG_FILE% to point to fonts.conf and fonts.conf can
point somewhere other then @UNIXROOT/usr.
Note that <dir>OS2FONTDIR</dir> actually loads the fonts listed in the
INI files.
Dave
ivan
2016-02-26 16:52:37 UTC
Permalink
Post by Dave Yeo
Post by ivan
Post by Dave Parsons
I am also trying to get FF 38.2.1 to work but at the moment it starts
to load & after about 5 seconds or so it beeps and quits.
There was nothing on the screen but it produced a TRP file and output
via stdout/stderr these few lines:-
Post by Dave Yeo
Fontconfig error: Cannot load default config file
Any idea which file it is referring to?
Path for fontconfig seems to hard coded to a location under/usr/share/...
That makes it very dificult for those of us that don't have a
?:\usr\share directory on our systems, or %unixroot% for that matter.
You can use %FONTCONFIG_FILE% to point to fonts.conf and fonts.conf can
Note that <dir>OS2FONTDIR</dir> actually loads the fonts listed in the
INI files.
Dave
Thanks for that Dave. I will set up our test WSeB machine this
evening and see what happens.

ivan
--
Dave Yeo
2016-02-26 20:40:31 UTC
Permalink
Post by ivan
Post by Dave Yeo
Post by ivan
Post by Dave Parsons
I am also trying to get FF 38.2.1 to work but at the moment it starts
to load & after about 5 seconds or so it beeps and quits.
There was nothing on the screen but it produced a TRP file and output
via stdout/stderr these few lines:-
Post by Dave Yeo
Fontconfig error: Cannot load default config file
Any idea which file it is referring to?
Path for fontconfig seems to hard coded to a location under/usr/share/...
That makes it very dificult for those of us that don't have a
?:\usr\share directory on our systems, or %unixroot% for that matter.
You can use %FONTCONFIG_FILE% to point to fonts.conf and fonts.conf can
Note that <dir>OS2FONTDIR</dir> actually loads the fonts listed in the
INI files.
Dave
Thanks for that Dave. I will set up our test WSeB machine this
evening and see what happens.
You will also need some of the utility programs such as fc-cache.exe on
the PATH, fc-list.exe is also handy to see which fonts Fontconfig found.
I also used *nix path separator, / to point at fonts.conf.
There's also %FONTCONFIG_PATH% which is supposed to point to the default
configuration directory, untested here.
http://www.freedesktop.org/software/fontconfig/fontconfig-user.html
Let us know how you make out
Dave
A.D. Fundum
2016-02-27 21:17:36 UTC
Permalink
Post by Dave Yeo
You can use %FONTCONFIG_FILE% to point to fonts.conf
By default there's no file called fonts.conf.
Post by Dave Yeo
Note that <dir>OS2FONTDIR</dir> actually loads the fonts listed
in the INI files.
So, should a file fonts.conf be created and should it typically
contain the text "<dir>OS2FONTDIR</dir>"?


With SM the crash seems to be related to fonts (GetFirstValidFont)
indeed, FWIW.

Filename: XUL.DLL 02/18/2016 22:46:13 38,343,417
Address: 005B:0EF8BD73 (0001:0106BD73)
Cause: Attempted to read from 00000018
(not a valid address)

Trap -> 0EF8BD73 XUL 0001:0106BD73 between
gfxPangoFontGroup::GetFirstValidFont + 213 and
gfxDownloadedFcFontEntry::InitPattern - 11D (both in
gfxPangoFonts.cpp)

0013BB08 1080887D XUL 0001:028E887D between
NS_NewListBoxBodyFrame + 17D and nsListBoxBodyFrame::operator new - 13
(both in Unified_cpp_layout_xul1.cpp)


--
Dave Yeo
2016-02-28 03:10:08 UTC
Permalink
Post by A.D. Fundum
Post by Dave Yeo
You can use %FONTCONFIG_FILE% to point to fonts.conf
By default there's no file called fonts.conf.
I uploaded the full FONTCONFIG package to my bitbucket page,
https://bitbucket.org/dryeo/dry-comm-esr31/downloads/fontconfig-2.11.94-1.oc00.i686.zip
Post by A.D. Fundum
Post by Dave Yeo
Note that <dir>OS2FONTDIR</dir> actually loads the fonts listed
in the INI files.
So, should a file fonts.conf be created and should it typically
contain the text "<dir>OS2FONTDIR</dir>"?
The default one should the one installed with fontconfig
Post by A.D. Fundum
With SM the crash seems to be related to fonts (GetFirstValidFont)
indeed, FWIW.
Filename: XUL.DLL 02/18/2016 22:46:13 38,343,417
Address: 005B:0EF8BD73 (0001:0106BD73)
Cause: Attempted to read from 00000018
(not a valid address)
Trap -> 0EF8BD73 XUL 0001:0106BD73 between
gfxPangoFontGroup::GetFirstValidFont + 213 and
gfxDownloadedFcFontEntry::InitPattern - 11D (both in
gfxPangoFonts.cpp)
0013BB08 1080887D XUL 0001:028E887D between
NS_NewListBoxBodyFrame + 17D and nsListBoxBodyFrame::operator new - 13
(both in Unified_cpp_layout_xul1.cpp)
Yes, that is the broken fontconfig crash.
Fontconfig also comes with some utility programs that should probably be
installed on the PATH. fc-list.exe will show all fonts that fontconfig
is aware of.
Dave
A.D. Fundum
2016-02-29 14:21:05 UTC
Permalink
Post by Dave Yeo
I uploaded the full FONTCONFIG package to my bitbucket
page
Brilliant! Now FF worked at least once, after adding the missing
readme.os2 DLLs (original posting) to a LIBPATH directory and after
typing the magic words SET FONTCONFIG_FILE=N:/OUNIX/fonts.conf
(unmodified copy from your package).

Next I'll give SM a try, after a reboot, but with a working FF the
hard labour should be over (yes, famous last words) by now.

The missing fonts.conf file was probably the generic reason why FF
originally didn't work, with several right or wrong reports w.r.t.
unloadable DLLs.

Thanks, Dave.


--
Dave Yeo
2016-02-29 16:10:25 UTC
Permalink
Post by A.D. Fundum
The missing fonts.conf file was probably the generic reason why FF
originally didn't work, with several right or wrong reports w.r.t.
unloadable DLLs.
By itself, the missing fonts.conf causes a crash with a certain trp file
rather then unloadable DLLs so there must have been something else missing
Dave
A.D. Fundum
2016-03-01 01:14:37 UTC
Permalink
Post by Dave Yeo
with several right or wrong reports w.r.t. unloadable DLLs.
By itself, the missing fonts.conf causes a crash with a certain trp
file rather then unloadable DLLs so there must have been
something else missing
I didn't notice it immediately, but PM DLL itself created a TRP file
too, between install attempts. At that stage FF/SM produced the
"expected" missing-fonts.conf beeps.

An old SM-specific problem is solved too, by upgrading. Checking for
new mail (handshake) was extremely slow when the previous version was
used, with a honest Windows'ish 100% CPU load during several seconds.
So far I also haven't seen rare, possibly related, mail server error
messages while sending mails anymore.


--
A.D. Fundum
2016-03-01 10:38:11 UTC
Permalink
Post by Dave Yeo
Note that <dir>OS2FONTDIR</dir> actually loads the fonts listed
in the INI files.
FONTCONFIG-related RFC: with OS2FONTDIR in use, it creates a directory
called @UNIXROOT in de root directory of the SM/FONTCONFIG/fonts.conf
drive. Would it be posible to use %TMP%, %TEMP% or the directory of
fonts.conf (e.g. C:\TOOLS\FONTSCONFIG\...) to create some cache file?

Maybe %UNIXROOT% could be used, but I'm not using %UNIXROOT% and I
don't want other apps to assume that I'm using such a file structure.
Now only FONTCONFIG is. I don't know how this cache file is (re?)used,
so I don't know if %TMP% or %TEMP% is a good choice.


--
Dave Yeo
2016-03-01 15:44:13 UTC
Permalink
Post by A.D. Fundum
Post by Dave Yeo
Note that <dir>OS2FONTDIR</dir> actually loads the fonts listed
in the INI files.
FONTCONFIG-related RFC: with OS2FONTDIR in use, it creates a directory
drive. Would it be posible to use %TMP%, %TEMP% or the directory of
fonts.conf (e.g. C:\TOOLS\FONTSCONFIG\...) to create some cache file?
Maybe %UNIXROOT% could be used, but I'm not using %UNIXROOT% and I
don't want other apps to assume that I'm using such a file structure.
Now only FONTCONFIG is. I don't know how this cache file is (re?)used,
so I don't know if %TMP% or %TEMP% is a good choice.
Look in fonts.conf for the section "Font cache directory list" and add
where you want the cache. The usual for user set cache is in %HOME% but
should work anywhere.
fc-cache.exe can be used to rebuild the cache, use --help to see various
settings.
The other fc-*.exe can be useful as well and should probably be on the PATH
Dave
Andreas Kohl
2016-03-01 20:37:23 UTC
Permalink
Post by Dave Yeo
Look in fonts.conf for the section "Font cache directory list" and add
where you want the cache. The usual for user set cache is in %HOME% but
should work anywhere.
At least almost. Without a setting for UNIXROOT it could be become more
complicated.
Post by Dave Yeo
fc-cache.exe can be used to rebuild the cache, use --help to see various
settings.
The other fc-*.exe can be useful as well and should probably be on the PATH
From my observation also fc-list.exe causes the cache to be rebuilt. So
you don't have to restart for instance seamonkey or firefox to use a
newly installed font. I don't keep them on the PATH but thats only a
matter of taste. They only need to find the dll files in LIBPATH.

--
Andreas
Dave Yeo
2016-03-01 23:11:13 UTC
Permalink
Post by Andreas Kohl
Post by Dave Yeo
fc-cache.exe can be used to rebuild the cache, use --help to see various
settings.
The other fc-*.exe can be useful as well and should probably be on the PATH
From my observation also fc-list.exe causes the cache to be rebuilt. So
you don't have to restart for instance seamonkey or firefox to use a
newly installed font. I don't keep them on the PATH but thats only a
matter of taste. They only need to find the dll files in LIBPATH.
fc-list does not trigger a cache rebuild here. So far I've only seen
cache rebuilds when changing systems, eg rebooting to Warp or eCS.
I haven't added any fonts yet.
Dave
Loading...