• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

Future versions of Firefox on OS/2 after Firefox 12

Started by ppgrainbow, 2012.02.04, 19:43:14

Previous topic - Next topic

ppgrainbow

Hey there! The bad news is that on the Windows side, the Mozilla Release Engineering team has decided to upgrade their Windows compilers to Visual Studio 2010 meaning that they won't be able to build Firefox on Windows 2000, Windows XP RTM, Windows XP SP1 or Windows Server 2003 RTM affecting .4% of these users. The discussion can be found on Asa Doltzer's blog here: http://weblogs.mozillazine.org/asa/archives/2012/01/end_of_firefox_win2k.html :(

Just curious enough to ask. Are we going to plan any future versions of Firefox after Firefox 12 for OS/2 and eComStation?

What compilers will we use to create custom build versions of Firefox 13 (and beyond) on OS/2 or eComStation and will the system requirements be changed on the OS/2 side as well?

Post your thoughts about this issue.

DougB

Well, it seems that there is only 1 (ONE!) person working on Firefox, Thunderbird, and SeaMonkey, at the moment, and he admits that he is not a programmer, and doesn't entirely understand a lot of it. There could be trouble ahead.

More, competent, volunteers are needed (but that is true of a lot of OS/2 stuff). I think that the people who were working on the Mozilla derivatives are busy on more important stuff, at the moment. Hopefully, some, or all, of them will return to the project, after they finish the other things (no, I don't know what they are working on, but I would guess that ACPI is part of it).

aschn

Quote from: DougB on 2012.02.04, 22:12:08
Well, it seems that there is only 1 (ONE!) person working on Firefox, Thunderbird, and SeaMonkey, at the moment, and he admits that he is not a programmer, and doesn't entirely understand a lot of it. There could be trouble ahead.

Not true. Please don't spread that kind of nonsense.

Andreas

dryeo

Quote from: aschn on 2012.02.05, 05:49:32
Quote from: DougB on 2012.02.04, 22:12:08
Well, it seems that there is only 1 (ONE!) person working on Firefox, Thunderbird, and SeaMonkey, at the moment, and he admits that he is not a programmer, and doesn't entirely understand a lot of it. There could be trouble ahead.

Not true. Please don't spread that kind of nonsense.

Andreas

Unluckily it is basically true. Rich has vanished, which usually means he's totally involved in what ever he is doing and might be Mozilla related but until he surfaces...
Walter has had personal issues taking most of his time last I heard, which just leaves me and I'm not really a programmer though I have learned a lot about porting in the last 10 years.

Answering the original post. The OS/2 Mozilla port is built with GCC, currently 4.4.1 and as far as I can see that will continue to work for building Mozilla for the foresee-able future. We are at the limit of our tool chain though, most notably our linkers. We can barely link XUL.dll and can no longer build a debug version which makes things difficult.

Paul Smedley

Is mozilla using wlink or ilink these days?

Also, what other parts of the toolchain are lacking?

ydario

Quote from: dryeo on 2012.02.05, 06:38:44
The OS/2 Mozilla port is built with GCC, currently 4.4.1 and as far as I can see that will continue to work for building Mozilla for the foresee-able future. We are at the limit of our tool chain though, most notably our linkers. We can barely link XUL.dll and can no longer build a debug version which makes things difficult.

IBM linkers all have different bugs, linking OpenOffice had been a problem with both 3.08 and ilinkv5; the watcom linker wlink is the only one able to correctly link every dll, even biggest ones (100MB with debug info).

And in gcc 4.4.6 I fixed a few problems related to linking a lot of files, mainly related to command line space exhaustion.

ivan

Quote from: ydario on 2012.02.05, 20:08:52
IBM linkers all have different bugs, linking OpenOffice had been a problem with both 3.08 and ilinkv5; the watcom linker wlink is the only one able to correctly link every dll, even biggest ones (100MB with debug info).

And in gcc 4.4.6 I fixed a few problems related to linking a lot of files, mainly related to command line space exhaustion.
Are you saying that you are working on a native version of Open Office, or is that asking too much?

ivan

dryeo

Quote from: Paul Smedley on 2012.02.05, 10:08:23
Is mozilla using wlink or ilink these days?

Also, what other parts of the toolchain are lacking?

Ilink fails to create useful map files last time I tried it, FF8? so we're using a version of wl that Rich patched to more aggressively use high memory. Wlink runs out of dynamic memory which holds things like the object file name.
Attempting to build a debug build with any linker fails as the page table overflows.
We're calling emxomfar directly for linking as we're dealing with a huge response file that GCC can't pass on to the linker.
Using LIBC064 (probably a problem with the includes) produces a browser that works well excepting SSL. Going to https://whatever would just produce a blank page.
We have to use nasm instead of yasm. They flat out refused to support nasm and we're just lucky that simply renaming nasm to yasm works.
There's also a couple of Bashism failures, most of which have not mattered. Lately I have to set the location of .mozconfig as the code to find it has changed. Have to use ksh as the shell.

abwillis

Quote from: dryeo on 2012.02.05, 21:20:45
Quote from: Paul Smedley on 2012.02.05, 10:08:23
Is mozilla using wlink or ilink these days?

Also, what other parts of the toolchain are lacking?

Ilink fails to create useful map files last time I tried it, FF8? so we're using a version of wl that Rich patched to more aggressively use high memory. Wlink runs out of dynamic memory which holds things like the object file name.
Attempting to build a debug build with any linker fails as the page table overflows.
We're calling emxomfar directly for linking as we're dealing with a huge response file that GCC can't pass on to the linker.
Using LIBC064 (probably a problem with the includes) produces a browser that works well excepting SSL. Going to https://whatever would just produce a blank page.
We have to use nasm instead of yasm. They flat out refused to support nasm and we're just lucky that simply renaming nasm to yasm works.
There's also a couple of Bashism failures, most of which have not mattered. Lately I have to set the location of .mozconfig as the code to find it has changed. Have to use ksh as the shell.
I wonder if the SSL issue could be related to:  http://svn.netlabs.org/libc/ticket/233
If so there is an hotfix lib file in there that might help.
I have found that I have had to use Bash for a few more things or late instead of Ash as I was wont to do.


ydario

Quote from: ivan on 2012.02.05, 21:06:34
Are you saying that you are working on a native version of Open Office, or is that asking too much?

yes, I am. Most patches have been already contributed to ASF OOo incubator project.

dryeo

Quote from: abwillis on 2012.02.05, 22:11:43
I wonder if the SSL issue could be related to:  http://svn.netlabs.org/libc/ticket/233
If so there is an hotfix lib file in there that might help.
I have found that I have had to use Bash for a few more things or late instead of Ash as I was wont to do.


No, the fixed lib makes no difference.
I usually use [pdk]sh.exe instead of Ash as it seems to work in most situations.

ppgrainbow

Quote from: dryeo on 2012.02.05, 06:38:44Unluckily it is basically true. Rich has vanished, which usually means he's totally involved in what ever he is doing and might be Mozilla related but until he surfaces...
Walter has had personal issues taking most of his time last I heard, which just leaves me and I'm not really a programmer though I have learned a lot about porting in the last 10 years.

Answering the original post. The OS/2 Mozilla port is built with GCC, currently 4.4.1 and as far as I can see that will continue to work for building Mozilla for the foresee-able future. We are at the limit of our tool chain though, most notably our linkers. We can barely link XUL.dll and can no longer build a debug version which makes things difficult.

I see what you mean. With the switch to MSVC2010 occurring in Firefox 13 for Windows builds, I understand. With being barely able to link XUL.DLL and unable to build a debug version and users on Win2k are not in the same position as to those on OS/2. :(

dryeo

Quote from: ydario on 2012.02.05, 20:08:52


IBM linkers all have different bugs, linking OpenOffice had been a problem with both 3.08 and ilinkv5; the watcom linker wlink is the only one able to correctly link every dll, even biggest ones (100MB with debug info).


Wish wlink worked as well for Firefox. Rich had to patch it to more aggressively to use high memory, ( http://e-vertise.com/misc/wl-fix.zip) and there are page table overflows with a debug build.
Fyi he changed the patch to use high memory for 4 k chunks instead of 64 k chunks.

Quote from: ydario on 2012.02.05, 20:08:52
And in gcc 4.4.6 I fixed a few problems related to linking a lot of files, mainly related to command line space exhaustion.


To work around a problem with the OS X linker, Mozilla got rid of static libs so for FF10 there are 2411 object files passed to GCC which our GCC can't pass on to the linker due to the lack of support for writing response files. We're calling emxomfar directly. Does your gcc 4.4.6 fixes include support for such huge command lines?
Currently using the 4.4.6 port from Paul's site fails to build a useful browser. It acts the same as if there was no network connection. Is the RPM version the same version of 4.4.6? I haven't used RPM much due to bandwidth limitations.

ydario

Quote from: dryeo on 2012.02.06, 09:58:21
Wish wlink worked as well for Firefox. Rich had to patch it to more aggressively to use high memory, ( http://e-vertise.com/misc/wl-fix.zip) and there are page table overflows with a debug build.
Fyi he changed the patch to use high memory for 4 k chunks instead of 64 k chunks.

To work around a problem with the OS X linker, Mozilla got rid of static libs so for FF10 there are 2411 object files passed to GCC which our GCC can't pass on to the linker due to the lack of support for writing response files. We're calling emxomfar directly. Does your gcc 4.4.6 fixes include support for such huge command lines?
Currently using the 4.4.6 port from Paul's site fails to build a useful browser. It acts the same as if there was no network connection. Is the RPM version the same version of 4.4.6? I haven't used RPM much due to bandwidth limitations.

I see XUL.DLL is bigger than SW.DLL... so probably OOo didn't touch the wlink limits...

But yes, gcc 4.4.6 makes use of response files to interact with child processes, also it does no longer use fork() to start them.
RPM and Paul's build are two builds generated from same source tree, so they are not the same binaries but I expect them to have same behaviour. The RPM one is also available with P4 code optimization.