SeaMonkey 2.35b7

classic Classic list List threaded Threaded
55 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Dave Yeo-3
On 07/19/16 10:37 PM, Steve Wendt wrote:
> On 07/19/16 10:14 pm, Steve Wendt wrote:
>
>>> Try copying all the missing DLLs from my last build to the new build.
>>
>> Yes, those work just fine.  So I'll have to narrow it down from there.
>
> The culprits are softokn3.dll and ssl3.dll; now to see if I can
> determine why the new ones don't work for me.

The chk files? eg softokn3.chk.
Dave

_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Steve Wendt
In reply to this post by Steve Wendt
On 07/19/16 10:37 pm, Steve Wendt wrote:

> The culprits are softokn3.dll and ssl3.dll; now to see if I can
> determine why the new ones don't work for me.

If I'm reading the linkages correctly:

dry build:
ssl3: libc066, nssutil3, nspr4, nss3, plc4, doscalls
softokn3: libc066, nspr4, nssutil3, plds4, mozsqlt3, plc4

netlabs build:
ssl3: libc066, nssutil3, nspr4, nss3, z, gcc1, plc4, doscalls
softokn3: libc066, nspr4, nssutil3, plds4, sqlit3, plc4, gcc1

The big glaring thing I see is sqlit3 instead of mozsqlt3, which would
explain the major breakage.  Now to see if I can fix that...

_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Steve Wendt
In reply to this post by Dave Yeo-3
On 07/19/16 10:42 pm, Dave Yeo wrote:

> I take it you were closing the browser between tests.

Yes; I tried removing the non-working netlabs DLLs (none were locked, a
good sign they were ignored) and putting in yours without restarting,
but obviously the code that checks for support isn't that dynamic.

_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Steve Wendt
In reply to this post by Dave Yeo-3
On 07/19/16 10:57 pm, Dave Yeo wrote:

> The chk files? eg softokn3.chk.

I don't know what the chk files are for, but they don't appear to be
needed or relevant to the problem.

_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Dave Yeo-3
In reply to this post by Steve Wendt
Steve Wendt wrote:

> On 07/19/16 10:37 pm, Steve Wendt wrote:
>
>> The culprits are softokn3.dll and ssl3.dll; now to see if I can
>> determine why the new ones don't work for me.
>
> If I'm reading the linkages correctly:
>
> dry build:
> ssl3: libc066, nssutil3, nspr4, nss3, plc4, doscalls
> softokn3: libc066, nspr4, nssutil3, plds4, mozsqlt3, plc4
>
> netlabs build:
> ssl3: libc066, nssutil3, nspr4, nss3, z, gcc1, plc4, doscalls
> softokn3: libc066, nspr4, nssutil3, plds4, sqlit3, plc4, gcc1
>
> The big glaring thing I see is sqlit3 instead of mozsqlt3, which would
> explain the major breakage.  Now to see if I can fix that...
>

That would explain that. I see mozz.dll has gone away, probably part of
xul.dll now.
One other thing was that I had a build breakage due to missing some z
exports and being rushed, I switched to using --with-system-zlib so
somewhere my build should require z.dll
Dave
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Steve Wendt
In reply to this post by Steve Wendt
On 07/19/16 10:58 pm, Steve Wendt wrote:

> The big glaring thing I see is sqlit3 instead of mozsqlt3, which would
> explain the major breakage.

Sure enough, all works well when that dll is present.  New mozsupport
package is uploading now (slow ftp server).

_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Steve Wendt
In reply to this post by Dave Yeo-3
On 07/19/16 11:10 pm, Dave Yeo wrote:

> somewhere my build should require z.dll

Other dependencies have needed it for quite some time, so that's been
part of the mozsupport package for a while now.

_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Steve Wendt
In reply to this post by Dave Yeo-3
On 07/17/16 06:34 pm, Dave Yeo wrote:

> https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.35b7.en-US.os2.zip
>
> Same requirements as FF38.8.0b7

Updated mozsupport package, which should finally have everything:
http://os2news.warpstock.org/mozsupport-2016-07-20.zip

I'm thinking of splitting the nss/nspr (only newest builds, conflicts
with files that used to be included with Mozilla), and libav (optional
for media playback) files.  Any opinions?

_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Dave Yeo-3
In reply to this post by Steve Wendt
On 07/19/16 10:56 PM, Steve Wendt wrote:
> On 07/19/16 10:42 pm, Dave Yeo wrote:
>
>> I take it you were closing the browser between tests.
>
> Yes; I tried removing the non-working netlabs DLLs (none were locked, a
> good sign they were ignored) and putting in yours without restarting,
> but obviously the code that checks for support isn't that dynamic.

After removing avform55.dll, avcode55.dll, avutil53.dll from LIBPATH, leaving avform56.dll, avcode56.dll, and avutil54.dll on the LIBPATH, H264 works fine here, this is SM Build ID: 20160617210117 which if I remember correctly is the one I uploaded.
Setting NSPR_LOG_MODULES=FFmpegDecoderModule:9 gives this output, (not sure if first line is FFmpeg related)
I/SampleTable(   95): There are reordered frames present.
44[2d199a40]: Initialising FFmpeg decoder.
44[2d199a40]: FFmpeg init successful.
44[2d199a40]: Initialising FFmpeg decoder.
44[2d199a40]: FFmpeg init successful.
44[2d199a40]: Choosing FFmpeg pixel format for video decoding.
44[2d199a40]: Requesting pixel format YUV420P.

Looking at the source, the supported DLLs are,
#ifdef XP_OS2
  { { "avform56.dll", "avcode56.dll", "avutil54.dll" }, FFmpegDecoderModule<55>::Create, 55 },
  { { "avform55.dll", "avcode55.dll", "avutil53.dll" }, FFmpegDecoderModule<55>::Create, 55 },
  { { "avform53.dll", "avcode53.dll", "avutil51.dll" }, FFmpegDecoderModule<53>::Create, 53 },
#else
...

Dave
 
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Steve Wendt
On 07/20/16 05:24 pm, Dave Yeo wrote:

> H264 works fine here

Thanks for the hints, and confirmation that it works. I now have it
working as well (at least, says Yes on html5test.com). For anyone
curious about the details:

dry build:
avcode55: libc066, avutil53, pthr01
avform55: libc066, avutil53, avcode55, z, bz2, tcpip32, doscalls
avutil53: libc066, pthr01, mmap

netlabs build:
avcode56: libc066, avutil54, gcc1, z, doscalls, libvpx2, swresa1
avform56: libc066, avutil54, avcode56, gcc1, z, bz2, tcpip32, doscalls
avutil54: libc066, doscalls, mmap, gcc1
swresa1: libc066, avutil54, gcc1

The big difference is that the netlabs build is dependent on libvpx2,
even though that is natively supported by Mozilla.

I'll repackage and upload shortly...

_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Steve Wendt
In reply to this post by Steve Wendt
On 07/19/16 11:32 pm, Steve Wendt wrote:

> I'm thinking of splitting the nss/nspr (only newest builds, conflicts
> with files that used to be included with Mozilla), and libav (optional
> for media playback) files.  Any opinions?

I split out the optional mozmedia support package; it now includes the
previously missing libvpx2 DLL.
http://os2news.warpstock.org/Warpzilla.html

_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Steve Wendt
In reply to this post by Steve Wendt
On 07/21/16 12:46 am, Steve Wendt wrote:

> I now have it working as well (at least, says Yes on html5test.com).

All 3 formats play for me here:
http://www.quirksmode.org/html5/tests/video.html

Would be nice to have libkva support.  :)

_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Dave Yeo-3
In reply to this post by Steve Wendt
On 07/21/16 12:46 AM, Steve Wendt wrote:

> On 07/20/16 05:24 pm, Dave Yeo wrote:
>
>> H264 works fine here
>
> Thanks for the hints, and confirmation that it works. I now have it
> working as well (at least, says Yes on html5test.com). For anyone
> curious about the details:
>
> dry build:
> avcode55: libc066, avutil53, pthr01
> avform55: libc066, avutil53, avcode55, z, bz2, tcpip32, doscalls
> avutil53: libc066, pthr01, mmap

Libav ripped out the os2threads support in favour of pthreads

>
> netlabs build:
> avcode56: libc066, avutil54, gcc1, z, doscalls, libvpx2, swresa1
> avform56: libc066, avutil54, avcode56, gcc1, z, bz2, tcpip32, doscalls
> avutil54: libc066, doscalls, mmap, gcc1
> swresa1: libc066, avutil54, gcc1
>
> The big difference is that the netlabs build is dependent on libvpx2,
> even though that is natively supported by Mozilla.
>

You can use the netlabs build of ffmpeg.exe to transcode to vp8/vp9 (not
sure if their libvpx is new enough for vp9), long term plan is to also
add X264, lame, libogg, libtheora, opus, and xvidcode, much like the
FFmpeg v3.0.x package I uploaded to Hobbes.

> I'll repackage and upload shortly...

Dave
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Peter Brown
In reply to this post by Dave Yeo-3
Hi All

Dave Yeo wrote:
> Uploaded
> https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.35b7.en-US.os2.zip
>
> Same requirements as FF38.8.0b7. Unluckily Lightning still broken. Drag
> & drop between address books fixed
> Dave


Having unzipped all known required packages I find this build of
Seamonkey cannot start. Reason: Cannot load XPCOM

A hunt for XPCOM*.* on my system reveals only 1 XPCOM.DLL installed in
seamonkey272_12 and, no, adding that to the current seamonkey directory
does not resolve this problem.

So, where do I get the current XPCOM.DLL?


Regards

Pete
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Dave Yeo-3
On 08/06/16 06:28 AM, Peter Brown wrote:

> Hi All
>
> Dave Yeo wrote:
>> Uploaded
>> https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.35b7.en-US.os2.zip
>>
>>
>> Same requirements as FF38.8.0b7. Unluckily Lightning still broken. Drag
>> & drop between address books fixed
>> Dave
>
>
> Having unzipped all known required packages I find this build of
> Seamonkey cannot start. Reason: Cannot load XPCOM
>
> A hunt for XPCOM*.* on my system reveals only 1 XPCOM.DLL installed in
> seamonkey272_12 and, no, adding that to the current seamonkey directory
> does not resolve this problem.
>
> So, where do I get the current XPCOM.DLL?

Seems the error message needs updating as xpcom.dll is long gone:) It's
a generic error message that happens when some requirement is missing,
or more likely, a requirement of a requirement. It's got complex enough
that it can be hard to trace which requirement though I thought Steve
had it figured out at http://os2news.warpstock.org/Warpzilla.html.
Did the last release run OK?
Dave
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Peter Brown
Hi Dave

Dave Yeo wrote:

> On 08/06/16 06:28 AM, Peter Brown wrote:
>> Hi All
>>
>> Dave Yeo wrote:
>>> Uploaded
>>> https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.35b7.en-US.os2.zip
>>>
>>>
>>>
>>> Same requirements as FF38.8.0b7. Unluckily Lightning still broken. Drag
>>> & drop between address books fixed
>>> Dave
>>
>>
>> Having unzipped all known required packages I find this build of
>> Seamonkey cannot start. Reason: Cannot load XPCOM
>>
>> A hunt for XPCOM*.* on my system reveals only 1 XPCOM.DLL installed in
>> seamonkey272_12 and, no, adding that to the current seamonkey directory
>> does not resolve this problem.
>>
>> So, where do I get the current XPCOM.DLL?
>
> Seems the error message needs updating as xpcom.dll is long gone:) It's
> a generic error message that happens when some requirement is missing,
> or more likely, a requirement of a requirement. It's got complex enough
> that it can be hard to trace which requirement though I thought Steve
> had it figured out at http://os2news.warpstock.org/Warpzilla.html.
> Did the last release run OK?
> Dave


I thought xpcom.dll had been dropped a while back so was surprised by
the error message.

I did download all necessary packages from Steves Warpzilla site - Thank
you Steve for figuring out and packaging required files.


Problem Resolved : Operator Error - Failed to read the mozsupport.txt
before attempting to run seamonkey.

Having rectified my error I discovered that the files in the nss
directory in the mozsupport package needed to be on the libpath.

Having sorted that out seamonkey starts fine.

Thanks for your efforts in keeping Seamonkey available for OS/2 users.


Regards

Pete


_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Steve Wendt
On 08/06/2016 05:13 PM, Peter Brown wrote:

> I did download all necessary packages from Steves Warpzilla site - Thank
> you Steve for figuring out and packaging required files.

I'm glad you found it useful; no one has commented recently, so I wasn't
sure if anyone else still cared.  :)

> Problem Resolved : Operator Error - Failed to read the mozsupport.txt
> before attempting to run seamonkey.
>
> Having rectified my error I discovered that the files in the nss
> directory in the mozsupport package needed to be on the libpath.

I was conflicted about keeping those in a separate folder, but I figured
having to RTFM because it didn't work was better than having DLL
conflicts because of not RTFM.  I could probably be convinced to change
the packaging structure if there are good arguments.

Personally, I just stuck the nss/nspr files in the SeaMonkey folder,
since I don't really consider those "shared" at this point.  I may
change my opinion if I ever care to run something else that depends on
them (I am unlikely to run VirtualBox).

As an aside, the way they are built right now is in some ways
unfortunate, as it means there are duplicate libraries linked in now;
sqlite3 plus mozsqlit3 is one, but there may be others.

Back when IBM was building Mozilla, they took great care to avoid any
licensing issues and DLL conflicts, statically linking or using DLLRNAME
to make private versions of DLLs.  Others that followed mostly tried to
stick to that, but what we have now is quite the opposite.  The "new
way" has some advantages of its own, but the ability to create a clean
install package is definitely not one of them.

I've mentioned before that I think there's room for two means of
packaging and distribution here:

a) yum install seamonkey thunderbird firefox
I believe this is the eventual goal of bitwise, but as everyone knows,
this simply does not work yet.

b) static build with minimal external dependencies, like Mozilla
distributes, and we had previously.  Both ZIP and installer package
(WarpIn or otherwise) are perfectly viable.

Doug has been making WarpIn packages for quite some time, which I
commend him for, but I feel they are currently pointless, since it
doesn't do anything about dependencies.  Isn't the point of an
installation package to set everything up for you?  I'm not faulting
Doug for that, just pointing out that option b above is what needs to be
packaged for it to be viable.

_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Doug Bissett-2
On Sun, 7 Aug 2016 05:03:21 UTC, Steve Wendt <[hidden email]>
wrote:

> On 08/06/2016 05:13 PM, Peter Brown wrote:
>
> > I did download all necessary packages from Steves Warpzilla site - Thank
> > you Steve for figuring out and packaging required files.
>
> I'm glad you found it useful; no one has commented recently, so I wasn't
> sure if anyone else still cared.  :)
>
> > Problem Resolved : Operator Error - Failed to read the mozsupport.txt
> > before attempting to run seamonkey.
> >
> > Having rectified my error I discovered that the files in the nss
> > directory in the mozsupport package needed to be on the libpath.
>
> I was conflicted about keeping those in a separate folder, but I figured
> having to RTFM because it didn't work was better than having DLL
> conflicts because of not RTFM.  I could probably be convinced to change
> the packaging structure if there are good arguments.
>
> Personally, I just stuck the nss/nspr files in the SeaMonkey folder,
> since I don't really consider those "shared" at this point.  I may
> change my opinion if I ever care to run something else that depends on
> them (I am unlikely to run VirtualBox).
>
> As an aside, the way they are built right now is in some ways
> unfortunate, as it means there are duplicate libraries linked in now;
> sqlite3 plus mozsqlit3 is one, but there may be others.
>
> Back when IBM was building Mozilla, they took great care to avoid any
> licensing issues and DLL conflicts, statically linking or using DLLRNAME
> to make private versions of DLLs.  Others that followed mostly tried to
> stick to that, but what we have now is quite the opposite.  The "new
> way" has some advantages of its own, but the ability to create a clean
> install package is definitely not one of them.
>
> I've mentioned before that I think there's room for two means of
> packaging and distribution here:
>
> a) yum install seamonkey thunderbird firefox
> I believe this is the eventual goal of bitwise, but as everyone knows,
> this simply does not work yet.
>
> b) static build with minimal external dependencies, like Mozilla
> distributes, and we had previously.  Both ZIP and installer package
> (WarpIn or otherwise) are perfectly viable.
>
> Doug has been making WarpIn packages for quite some time, which I
> commend him for, but I feel they are currently pointless, since it
> doesn't do anything about dependencies.  Isn't the point of an
> installation package to set everything up for you?  I'm not faulting
> Doug for that, just pointing out that option b above is what needs to be
> packaged for it to be viable.

I think that a) will be an option, in the near future, and that will
make other methods obsolete. If you haven't looked seriously at
installing, and using Arca Noae Package Manager (ANPM), I suggest that
you do so. It makes life a whole lot easier. I don't agree with the
way the RPM/YUM does things, but that is the way that was chosen by
those who do it, so we are stuck with it, and it will become even more
important to follow that path in the future as more programs are
packaged that way. The whole thing is a LOT better than it was when
the ANPM project was started, and ANPM makes it easy to operate
RPM/YUM.

On the other hand, option b) may become necessary just to overcome the
shared memory problems, but that doesn't mean that it can't be
distributed by RPM/YUM. After doing some investigation, we need to get
high shared memory working (it does work, as long as you never unload
the DLLs), or we need a way to keep, at least, XUL.DLL (perhaps
others) loaded all of the time (preferably high),  so it doesn't run
into a situation where it can't get enough contiguous memory to load.
It also needs to be fixed so that it just fails when it can't load the
DLLs. Now, it seems that it just keeps retrying, until the user
reboots (and a user won't know what is going on, if they don't have
Process Dumps enabled). I would also suggest that those who use only a
browser, should use FF. Those who use only e-mail, (and news etc.)
should use TB. Those who need both, should use SM. The idea is to have
only ONE XUL.DLL loaded. Apparently, if you can get the right one,
they can all share XUL.DLL, but that seems to be hit and miss, at the
moment. In fact, part of the answer may be to simply drop FF and TB,
and only update SM, but SM is not an "official" project, so that
causes other problems.

I will note, that I gave up trying to verify requirements, with
WarpIn, because Bitwise gave up trying to document that stuff (too
complicated), and simply said to use RPM/YUM (meaning ANPM to make it
easy). I did consider looking to see if the user has RPM/YUM
installed, and simply run the command to do the updates, if it was
found, but that didn't seem to be a good idea if the user had it
installed, but wasn't actually using it. As it turned out, those who
use ANPM spent about 2 minutes (depending on download speed) getting
the requirements installed, and those who don't use ANPM spent days
trying to figure it out. Steve made that much easier, but his package
still doesn't contain all of the parts that ANPM includes, and it will
be the same thing next time. Possibly worse.

One thought (Dave, perhaps you can do something), is to have a program
that will simply load XUL.DLL, and keep it loaded in high shared
memory space when FF is closed. currently, it seems to take about 90
meg to load XUL.DLL, and it seems that that must be contiguous memory.
If another program loads something after that, and it stays in memory
when FF is closed, and something else  uses another chunk of shared
memory, it can come out of the part that XUL.DLL was using. Now, when
XUL.DLL tries to load, it can't find enough contiguous shared memory
space to be able to load XUL.DLL. That just happened to me, and the
result was repeating Process Dumps, all pointing to Firefox (no *.TRP
files, or entries in POPUPLOG.OS2). That kept on repeating until I
rebooted. If XUL.DLL was loaded, and stayed in memory, that problem
wouldn't happen. Of course, FF should also detect that it couldn't
load the DLL, and inform the user of the problem.

--
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)

_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Dave Yeo-3
In reply to this post by Steve Wendt
Steve Wendt wrote:

> On 08/06/2016 05:13 PM, Peter Brown wrote:
>
>> I did download all necessary packages from Steves Warpzilla site - Thank
>> you Steve for figuring out and packaging required files.
>
> I'm glad you found it useful; no one has commented recently, so I wasn't
> sure if anyone else still cared.  :)
>
>> Problem Resolved : Operator Error - Failed to read the mozsupport.txt
>> before attempting to run seamonkey.
>>
>> Having rectified my error I discovered that the files in the nss
>> directory in the mozsupport package needed to be on the libpath.
>
> I was conflicted about keeping those in a separate folder, but I figured
> having to RTFM because it didn't work was better than having DLL
> conflicts because of not RTFM.  I could probably be convinced to change
> the packaging structure if there are good arguments.
>
> Personally, I just stuck the nss/nspr files in the SeaMonkey folder,
> since I don't really consider those "shared" at this point.  I may
> change my opinion if I ever care to run something else that depends on
> them (I am unlikely to run VirtualBox).
>
> As an aside, the way they are built right now is in some ways
> unfortunate, as it means there are duplicate libraries linked in now;
> sqlite3 plus mozsqlit3 is one, but there may be others.

It may have been better to just package up the missing dependencies from
the last release of SM. They seem to work and don't have extra dependencies.
Of course the new problem is that any work done to NSPR or NSS etc is
going to happen to the Netlabs versions, so eventually we'll have to use
them.

>
> Back when IBM was building Mozilla, they took great care to avoid any
> licensing issues and DLL conflicts, statically linking or using DLLRNAME
> to make private versions of DLLs.  Others that followed mostly tried to
> stick to that, but what we have now is quite the opposite.  The "new
> way" has some advantages of its own, but the ability to create a clean
> install package is definitely not one of them.

It helped that OS/2 was tier 1 back then, so that when Mozilla added
libz and the sys2070's started happening on OS/2, the obvious solution,
prefixing DLLs with moz, was easy to push.
Things like mzfntcfgft were written as much to reduce external
dependencies as to make it OS/2 specific. There was a time when we
depended on the real fontconfig.
One thing was that with regular releases, it was easy to update the
static libraries. Now it's hard to say how  many more releases we'll
have. After 45ESR it is going to be very hard to update, just due to the
rust dependency, little well all the build system changes etc.

>
> I've mentioned before that I think there's room for two means of
> packaging and distribution here:
>
> a) yum install seamonkey thunderbird firefox
> I believe this is the eventual goal of bitwise, but as everyone knows,
> this simply does not work yet.

It still needs to be decided how. Most Linux dists put the binaries
somewhere such as under /usr/lib or /usr/share and just have a script in
/usr/bin to launch. It'd be nice to be able to share all DLLs but not
sure if it is possible.

>
> b) static build with minimal external dependencies, like Mozilla
> distributes, and we had previously.  Both ZIP and installer package
> (WarpIn or otherwise) are perfectly viable.

Some of the dependencies seem to not work as static libraries, at least
Fontconfig and Pango. I tried a static build and managed to get a
browser that didn't display any text, not even miss-glyph symbols.

>
> Doug has been making WarpIn packages for quite some time, which I
> commend him for, but I feel they are currently pointless, since it
> doesn't do anything about dependencies.  Isn't the point of an
> installation package to set everything up for you?  I'm not faulting
> Doug for that, just pointing out that option b above is what needs to be
> packaged for it to be viable.
>

Dave
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Dave Yeo-3
In reply to this post by Doug Bissett-2
Doug Bissett wrote:

>> I've mentioned before that I think there's room for two means of
>> >packaging and distribution here:
>> >
>> >a) yum install seamonkey thunderbird firefox
>> >I believe this is the eventual goal of bitwise, but as everyone knows,
>> >this simply does not work yet.
>> >
>> >b) static build with minimal external dependencies, like Mozilla
>> >distributes, and we had previously.  Both ZIP and installer package
>> >(WarpIn or otherwise) are perfectly viable.
>> >
>> >Doug has been making WarpIn packages for quite some time, which I
>> >commend him for, but I feel they are currently pointless, since it
>> >doesn't do anything about dependencies.  Isn't the point of an
>> >installation package to set everything up for you?  I'm not faulting
>> >Doug for that, just pointing out that option b above is what needs to be
>> >packaged for it to be viable.
> I think that a) will be an option, in the near future, and that will
> make other methods obsolete. If you haven't looked seriously at
> installing, and using Arca Noae Package Manager (ANPM), I suggest that
> you do so. It makes life a whole lot easier. I don't agree with the
> way the RPM/YUM does things, but that is the way that was chosen by
> those who do it, so we are stuck with it, and it will become even more
> important to follow that path in the future as more programs are
> packaged that way. The whole thing is a LOT better than it was when
> the ANPM project was started, and ANPM makes it easy to operate
> RPM/YUM.
>
> On the other hand, option b) may become necessary just to overcome the
> shared memory problems, but that doesn't mean that it can't be
> distributed by RPM/YUM. After doing some investigation, we need to get
> high shared memory working (it does work, as long as you never unload
> the DLLs),

It does work here, at least until memory gets fragmented or some other
resource runs out. Currently with TB and SM loaded, I have 256 MBs of
low shared memory available. If I restart SM enough times, the system
will usually spontaneously reboot when loading SM or opening a new SM
window. Occasionally the system just freezes. This usually happens here
when Free Shared Memory app shows about 200MBs free.

> or we need a way to keep, at least, XUL.DLL (perhaps
> others) loaded all of the time (preferably high),  so it doesn't run
> into a situation where it can't get enough contiguous memory to load.

Which XUL.DLL? Right now I loaded TB and then SM without RUN! or
LIBPATHSTRICT and Theseus shows both XUL.DLLs being loaded. Trying to
also run FF now gives a sqlite error about the version being too old,
which seems like a new error.
The wildcard seems to be Calendar, or its DLL, calbscmp.dll. Without
Calendar installed, I was running all 3 Mozilla apps without
LIBPATHSTRICT. With it installed in only TB, I can load TB and then SM
but lately it fails if I have it installed in both SM and TB, with SM
crashing when loading the mail & news window. SM also seems to keep
reverting to an older version and even when the DLL is the same in both
apps, it crashes lately.
Really it seems that it is just safer to use LIBPATHSTRICT or RUN!

> It also needs to be fixed so that it just fails when it can't load the
> DLLs. Now, it seems that it just keeps retrying, until the user
> reboots (and a user won't know what is going on, if they don't have
> Process Dumps enabled).

I haven't seen this. Here it seems to just reboot or freeze the system.
Occasionally I get a TRAP E in SM

> I would also suggest that those who use only a
> browser, should use FF. Those who use only e-mail, (and news etc.)
> should use TB. Those who need both, should use SM.

Lots of people don't like FF, so prefer browsing with SM. I also run TB
for testing purposes.

> The idea is to have
> only ONE XUL.DLL loaded. Apparently, if you can get the right one,
> they can all share XUL.DLL, but that seems to be hit and miss, at the
> moment. In fact, part of the answer may be to simply drop FF and TB,
> and only update SM, but SM is not an "official" project, so that
> causes other problems.

Then there are the people who don't like SM and prefer FF.

>
> I will note, that I gave up trying to verify requirements, with
> WarpIn, because Bitwise gave up trying to document that stuff (too
> complicated), and simply said to use RPM/YUM (meaning ANPM to make it
> easy). I did consider looking to see if the user has RPM/YUM
> installed, and simply run the command to do the updates, if it was
> found, but that didn't seem to be a good idea if the user had it
> installed, but wasn't actually using it. As it turned out, those who
> use ANPM spent about 2 minutes (depending on download speed) getting
> the requirements installed, and those who don't use ANPM spent days
> trying to figure it out. Steve made that much easier, but his package
> still doesn't contain all of the parts that ANPM includes, and it will
> be the same thing next time. Possibly worse.
>
> One thought (Dave, perhaps you can do something), is to have a program
> that will simply load XUL.DLL, and keep it loaded in high shared
> memory space when FF is closed. currently, it seems to take about 90
> meg to load XUL.DLL, and it seems that that must be contiguous memory.

That should be possible. Mozilla used to pre-load the DLLs if you ran
their pre-loader program and Dink had a program that did similar.
I'd assume that you just need a small program linked against XUL.DLL
that is left running. Not sure how it handles XUL data, does it get
unloaded when FF closes?

> If another program loads something after that, and it stays in memory
> when FF is closed, and something else  uses another chunk of shared
> memory, it can come out of the part that XUL.DLL was using. Now, when
> XUL.DLL tries to load, it can't find enough contiguous shared memory
> space to be able to load XUL.DLL. That just happened to me, and the
> result was repeating Process Dumps, all pointing to Firefox (no *.TRP
> files, or entries in POPUPLOG.OS2). That kept on repeating until I
> rebooted. If XUL.DLL was loaded, and stayed in memory, that problem
> wouldn't happen. Of course, FF should also detect that it couldn't
> load the DLL, and inform the user of the problem.

I don't know why Mozilla hasn't added code to inform about not being
able to allocate enough continuous memory as it is also a major problem
on 32 bit Windows. Eventually it'll probably be only 64 bit to avoid
these issues.
Dave

_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
123