Re: Firefox 38.8.0 Beta 7 released

I figured that some DLLs from the Thunderbird distribution could be 
deleted as they are also contained in \usr\lib (if you use yum/rpm ...).
The ones that had to be left in where:
ldap60.dll
ldif60.dll
mozalloc.dll
mozqslt3.dll
prldap60.dll
xul.dll

as they either do not exist in \usr\lib or they are not yet "unified" 
between Firefox and Thunderbird. I guess once "xul.dll" gets "unified" 
that that will also eliminate the shared memory problem (this thing is 
HUGE).

Lars

Am 12.06.16 um 20.19 schrieb Dave Yeo:
> Doug Bissett wrote:

>>
>> FWIW, I would like to see a statically linked version of FF (at
>> least), just because I am running out of shared memory space, and I am
>> also running out of ways to solve the problem. Currently, I cannot run
>> FF and TB at the same time, without crashing one, both, or something
>> else (fortunately, I use PMMail, which doesn't use very much shared
>> memory space).
>
> Statically linking still means linking things into xul.dll, which won't
> help your shared memory problem.
> Here I can run FF, SM, and TB for a couple of days before the system
> traps. I mark all the DLLs to load high and lately I've been sharing the
> DLLs when the apps are built from the same tree. Due to calendar, I have
> to start TB first and then SM and FF happily use the same DLLs that TB
> loaded.
> I just revisited which DLLs can be statically linked in, and actually it
> isn't too many. Fontconfig and Pango are only available as DLLs (I built
> FF with a static Pango at one point, had a browser with no text) and
> while they can be rebuilt to statically link in their dependencies, its
> work, the binaries need hosting somewhere along with their source for
> licensing reasons. Ideally would be to build with the -bstatic flag but
> its broken on our platform.

>
> Dave