How to go on (especially with Hg)?
Peter Weilbacher
for the good news, I have heard from Mike Kaply who has set up a new
nightly builds machine, so there should soon be 1.8 branch nightlies
again for all three products and Firefox 3.0.x nightlies.
As for the nightlies from Mercurial, I currently don't know how to
proceed. The guys working on the JavaScript module are nice enough to
allow simple patches to accommodate our old compiler (bug 452630), but
the XPCOM guys don't like that (bug 451278, especially as the patch
would pollute their headers with ugly stuff).
This means that until Paul or somebody else comes up with a newer GCC,
nightlies have to be built with extra patches applied and that cannot
really be automated with Mercurial. And I think if I place such
nightlies on the Mozilla FTP server, they should be accompanied by a
README detailing the differences, which needs even more manual
interaction.
Who is actually interested/using Mercurial nightlies? If it's just two
people, I think we should concentrate our efforts more on testing with
release candidates (even for the upcoming betas) instead of nightlies.
I should also point out that my time to work on Mozilla stuff is
diminishing. I used to spend a few hours per day on debugging and
programming but this has gone down to two hours or so per week. Partly
because nightly builds and releases take up so much time, partly because
I just have less spare time now... That's also why much of the stuff
that I wanted to implement hasn't happened (font selection overhaul,
printing improvements, etc.) and I don't really see it happening any
time soon.
Finally, I wanted to work on the build instructions on the Mozilla
developer center, separating out instructions for CVS and Mercurial. But
I can't find my way around the new wiki system that was put in place
recently. If somebody else could start on that, it would be nice. If some
details are unclear I would be happy to fill in blanks later...
Btw, due to the new system the page has (temporarily?) moved to
http://developer.mozilla.org/index.php?title=En/OS%2F%2F2_Build_Prerequisites
--
Please Enhanced OS/2 builds of Mozilla applications
reply in http://pmw-warpzilla.sf.net/
newsgroup
Steve's Warpzilla Tips: http://www.os2bbs.com/os2news/Warpzilla.html
Steve Wendt
> The guys working on the JavaScript module are nice enough to
> allow simple patches to accommodate our old compiler (bug 452630), but
> the XPCOM guys don't like that (bug 451278, especially as the patch
> would pollute their headers with ugly stuff).
I understand why they don't like it, but I think they (he) should have a
more pragmatic attitude about it. :-(
> Who is actually interested/using Mercurial nightlies? If it's just two
> people, I think we should concentrate our efforts more on testing with
> release candidates (even for the upcoming betas) instead of nightlies.
Given lack of resources, it's more important to have good release
candidates than nightly builds. Still, it would be good to know early
when things get broken (and have intermediate builds to test with later,
to help pinpoint when something changed).
Peter Weilbacher
> On 9/4/2008 1:10 AM, Peter Weilbacher wrote:
>
>> The guys working on the JavaScript module are nice enough to
>> allow simple patches to accommodate our old compiler (bug 452630), but
>> the XPCOM guys don't like that (bug 451278, especially as the patch
>> would pollute their headers with ugly stuff).
>
> I understand why they don't like it, but I think they (he) should have a
> more pragmatic attitude about it. :-(
Yes, especially as the maintenance expense that he is talking about is
minimal, too. They will at most change those headers once or twice more
in the 1.9.1 timeframe. Perhaps he doesn't want such ugliness to spread
and so draws the border right now.
>> Who is actually interested/using Mercurial nightlies? If it's just two
>> people, I think we should concentrate our efforts more on testing with
>> release candidates (even for the upcoming betas) instead of nightlies.
>
> Given lack of resources, it's more important to have good release
> candidates than nightly builds. Still, it would be good to know early
> when things get broken (and have intermediate builds to test with later,
> to help pinpoint when something changed).
I'll continue my own builds of SeaMonkey when I have enough time and
file bugs with whatever I find. I guess Dave will do the same and Walter
for Firefox. But at least my builds will rarely be clean enough for
distribution as nightly.
--
Please | Official Warpzilla Ports: http://www.mozilla.org/ports/os2/
reply in |
newsgroup | Enhanced OS/2 builds: http://pmw-warpzilla.sf.net/
Walter Meinl
> On 04.09.08 19:28, Steve Wendt wrote:
>
> > On 9/4/2008 1:10 AM, Peter Weilbacher wrote:
>
>
> Yes, especially as the maintenance expense that he is talking about is
> minimal, too. They will at most change those headers once or twice more
> in the 1.9.1 timeframe. Perhaps he doesn't want such ugliness to spread
> and so draws the border right now.
>
> >> Who is actually interested/using Mercurial nightlies? If it's just two
> >> people, I think we should concentrate our efforts more on testing with
> >> release candidates (even for the upcoming betas) instead of nightlies.
>
> > Given lack of resources, it's more important to have good release
> > candidates than nightly builds. Still, it would be good to know early
> > when things get broken (and have intermediate builds to test with later,
> > to help pinpoint when something changed).
>
> I'll continue my own builds of SeaMonkey when I have enough time and
> file bugs with whatever I find. I guess Dave will do the same and Walter
> for Firefox. But at least my builds will rarely be clean enough for
> distribution as nightly.
future. Though my knowledge about real code fixes equals about zero, I
can help at least sometimes when it comes to troubles with the build
system itself. Anyway, try to keep it going, though we might have no
nightlies or some very infrequently uploaded, will be necessary,
otherwise, we fall to far behind. Well having this said, I'll open a
new thread about the next break....
Walter Meinl
> otherwise, we fall to far behind. Well having this said, I'll open a
> new thread about the next break....
https://bugzilla.mozilla.org/show_bug.cgi?id=453705
though I won't be able to help much during the next three weeks
Paul Smedley
On Thu, 4 Sep 2008 08:10:47 UTC, Peter Weilbacher
<news...@weilbacher.org> wrote:
> This means that until Paul or somebody else comes up with a newer GCC,
> nightlies have to be built with extra patches applied and that cannot
> really be automated with Mercurial. And I think if I place such
> nightlies on the Mozilla FTP server, they should be accompanied by a
> README detailing the differences, which needs even more manual
> interaction.
We're getting closer to a GCC 3.4.6. I have the beast compiling and
producing executables - I've built some simple things like wget,
ffmpeg and bison with it.
The main remaining issue before I release a build is
- The compiler is not obeying the _System directive - so
applications that use the OS/2 api's fail at linking due to being
unable to find (for example) _DosFindFirst - when it should be linking
against DosFindFirst
More news as it happens!
--
Cheers,
Paul.
Walter Meinl
wrote:
> We're getting closer to a GCC 3.4.6. I have the beast compiling and
> producing executables - I've built some simple things like wget,
> ffmpeg and bison with it.
>
>
> Paul.
I raise my hat off to you, great news in such a shooooort time! ;-)
Regards Walter
Peter Weilbacher
> We're getting closer to a GCC 3.4.6. I have the beast compiling and
> producing executables - I've built some simple things like wget,
> ffmpeg and bison with it.
>
> The main remaining issue before I release a build is
> - The compiler is not obeying the _System directive - so
> applications that use the OS/2 api's fail at linking due to being
> unable to find (for example) _DosFindFirst - when it should be linking
>
> against DosFindFirst
>
> More news as it happens!
Cool, didn't think that was possible in such a short time! Did you quit
your day job to have enough time? ;-)
If it's not too much to ask, could you post the build steps (don't need
to be full instructions) somewhere? I also looked at building GCC but
couldn't make heads or tails from Knut's instructions at
svn.netlabs.org/libc...
Dave Yeo
> If it's not too much to ask, could you post the build steps (don't need
> to be full instructions) somewhere? I also looked at building GCC but
> couldn't make heads or tails from Knut's instructions at
> svn.netlabs.org/libc...
I had success building the libc06x branch with configure && make once I
updated my tools to symlink aware versions. I especially needed to make
which I got from Knut's kbuild.
Dave
Andy Willis
GCC I so far have been unsuccessful building. Other parts have had to
do some changes to complete, I got to the end so far with building
everything except Perl and Python when running kmk (emx, libc, and gcc
are not built by just running kmk).
Andy
Dave Yeo
Branch doesn't use kmk so it is pretty simple, EMX and LIBC build with a
simple make and GCC built with just configure and make. As I said you
need symlink aware tools as GCC builds in a symlinked directory. Also
EMX depends on MASM and Krx(sp?) from Odin. Krx just crashed so I
replaced it with cmd /C IIRC.
So far I've spent 14 hrs downloading trunk and am not finished yet <gr>
Dave
Paul Smedley
On Tue, 9 Sep 2008 12:35:37 UTC, Peter Weilbacher
<news...@weilbacher.org> wrote:
> On 09.09.2008 11:39, Paul Smedley wrote:
>
> > We're getting closer to a GCC 3.4.6. I have the beast compiling and
> > producing executables - I've built some simple things like wget,
> > ffmpeg and bison with it.
> >
> > The main remaining issue before I release a build is
> > - The compiler is not obeying the _System directive - so
> > applications that use the OS/2 api's fail at linking due to being
> > unable to find (for example) _DosFindFirst - when it should be linking
> >
> > against DosFindFirst
> >
> > More news as it happens!
>
> Cool, didn't think that was possible in such a short time! Did you quit
> your day job to have enough time? ;-)
Nah - I've just been spending a lot of my available time on it over
the last couple of weeks - hence the lack of other updates at
http://os2ports.smedley.info :)
The diff of gcc 3.3.5 in netlabs svn vs the gcc code was actually
relatively small - the most difficult part was adapting the patches to
the newer 3.4.6 code.
> If it's not too much to ask, could you post the build steps (don't need
> to be full instructions) somewhere? I also looked at building GCC but
> couldn't make heads or tails from Knut's instructions at
> svn.netlabs.org/libc...
This is absolutely planned! IN fact, if I don't get joy from making
_System work soon, I'll be posting a zip of the source in the hope
that someone else can help spy the problem!
Getting this kind of back on topic, I tried building firefox with GCC
3.4.6 (understanding that I was going to fail at linking, but just to
test) - somehow support for -Zlinker has fallen out of my binary,
which is another thing I'll need to look at - out of curiosity - is
this critical to Mozilla?
Thanks to all for the kind works of encouragement - I have a day off
work Friday - I really hope I can tidy things up to the point that I
can do a release!
--
Cheers,
Paul.
Peter Weilbacher
> Getting this kind of back on topic, I tried building firefox with GCC
> 3.4.6 (understanding that I was going to fail at linking, but just to
> test) - somehow support for -Zlinker has fallen out of my binary,
> which is another thing I'll need to look at - out of curiosity - is
> this critical to Mozilla?
Probably not critical, but it's used throughout the codebase for various
things, so it would be extra work to find other ways to do it.
Dave Yeo
> On 10.09.2008 11:19, Paul Smedley wrote:
>> Getting this kind of back on topic, I tried building firefox with GCC
>> 3.4.6 (understanding that I was going to fail at linking, but just to
>> test) - somehow support for -Zlinker has fallen out of my binary,
>> which is another thing I'll need to look at - out of curiosity - is
>> this critical to Mozilla?
>
> Probably not critical, but it's used throughout the codebase for various
> things, so it would be extra work to find other ways to do it.
What about using -wl ? The only problem I can think of is whether -wl
allows options that start with a slash. Though I think wlink allows
options with --
Dave
Paul Smedley
On Wed, 10 Sep 2008 13:24:32 UTC, Peter Weilbacher
<news...@weilbacher.org> wrote:
> On 10.09.2008 11:19, Paul Smedley wrote:
> > Getting this kind of back on topic, I tried building firefox with GCC
> > 3.4.6 (understanding that I was going to fail at linking, but just to
> > test) - somehow support for -Zlinker has fallen out of my binary,
> > which is another thing I'll need to look at - out of curiosity - is
> > this critical to Mozilla?
>
> Probably not critical, but it's used throughout the codebase for various
> things, so it would be extra work to find other ways to do it.
OK - now that I have linking of Dos* symbols working correctly, I'll
look in to fixing -Zlinker :)
--
Cheers,
Paul.
Paul Smedley
On Thu, 4 Sep 2008 08:10:47 UTC, Peter Weilbacher
<news...@weilbacher.org> wrote:
> This means that until Paul or somebody else comes up with a newer GCC,
> nightlies have to be built with extra patches applied and that cannot
> really be automated with Mercurial. And I think if I place such
> nightlies on the Mozilla FTP server, they should be accompanied by a
> README detailing the differences, which needs even more manual
> interaction.
An initial release....
http://download.smedley.info/gcc-3.4.6-os2-20080912.zip
Unzip in the root of the drive whre \usr is already installed - all
files are put in \usr\local so it won't impact on an existing
installation.
My modified setmozenv is at
http://download.smedley.info/setmozenv_gcc346.cmd
Note that I haven't successfully built mozilla with this yet - there
are some problems documented in
https://bugzilla.mozilla.org/show_bug.cgi?id=454956 but also some
other changes are required.
Currently I fail linking xul.dll due to a bunch of missing symbols....
--
Cheers,
Paul.
Ilya Zakharevich
Paul Smedley
<pa...@smedley.id.au>], who wrote in article <POn1Xm9ddZOp-p...@smedley.info>:
> OK - now that I have linking of Dos* symbols working correctly
While this is fresh with you, can it be generalized? AFAIU, this
addition of "_" (for an unfathomable reason) is the main
uncompatibility with EMX-OMF... If one could remove it (optionally?),
EMX may be used with gcc4...
Yours,
Ilya
Peter Weilbacher
> Currently I fail linking xul.dll due to a bunch of missing symbols....
It's probably the same problem but with my trial SeaMonkey build it
already happens when linking xpcom.dll:
make.exe[7]: Entering directory `<path>suite/mozilla/xpcom/stub'
nsXPComStub.cpp
weakld: error: Unresolved symbol (UNDEF) '_NS_LogInit_P'.
weakld: info: The symbol is referenced by: <path>\suite\mozilla\xpcom\stub\nsXPComStub.o
weakld: error: Unresolved symbol (UNDEF) '_NS_Alloc_P'.
weakld: info: The symbol is referenced by: <path>\suite\mozilla\xpcom\stub\nsXPComStub.o
[... etc. ...]
All these are #defined symbols from xpcom/reflect/xptcall/public/xptcall.h,
xpcom/build/nsXPCOM.h, and xpcom/string/public/nsXPCOMStrings.h.
I faintly remember having seen this #defined _symbols problem somewhere
some time ago, but I cannot recall any details (or solutions)...
--
Please | Official Warpzilla Ports: http://www.mozilla.org/ports/os2/
reply in |
newsgroup | Enhanced OS/2 builds: http://pmw-warpzilla.sf.net/
Paul Smedley
On Fri, 12 Sep 2008 22:28:30 UTC, Peter Weilbacher
<news...@weilbacher.org> wrote:
> On 12.09.08 07:41, Paul Smedley wrote:
> > Currently I fail linking xul.dll due to a bunch of missing symbols....
>
> It's probably the same problem but with my trial SeaMonkey build it
> already happens when linking xpcom.dll:
>
> make.exe[7]: Entering directory `<path>suite/mozilla/xpcom/stub'
> nsXPComStub.cpp
> weakld: error: Unresolved symbol (UNDEF) '_NS_LogInit_P'.
> weakld: info: The symbol is referenced by: <path>\suite\mozilla\xpcom\stub\nsXPComStub.o
> weakld: error: Unresolved symbol (UNDEF) '_NS_Alloc_P'.
> weakld: info: The symbol is referenced by: <path>\suite\mozilla\xpcom\stub\nsXPComStub.o
> [... etc. ...]
>
> All these are #defined symbols from xpcom/reflect/xptcall/public/xptcall.h,
> xpcom/build/nsXPCOM.h, and xpcom/string/public/nsXPCOMStrings.h.
> I faintly remember having seen this #defined _symbols problem somewhere
> some time ago, but I cannot recall any details (or solutions)...
Yeah - probably the same problem. Per my post to the libc group - I
seem to have introduced a problem linking c++ objects when fixing the
linking of Dos* - will try and fix it ASAP
--
Cheers,
Paul.
Dave Yeo
[...]
> While this is fresh with you, can it be generalized? AFAIU, this
> addition of "_" (for an unfathomable reason) is the main
> uncompatibility with EMX-OMF... If one could remove it (optionally?),
> EMX may be used with gcc4...
>
Its not hard to link with EMX DLLs, you just need to create a new import
lib by making a DEF (using emximp) and create an alias, eg
foo = _foo then use emximp to create the import lib from the DEF. (may
need the emximp from klibc)
It is not recommended to mix static libraries from two different
versions of GCC.
Dave
Dave Yeo
> On 12.09.08 07:41, Paul Smedley wrote:
>> Currently I fail linking xul.dll due to a bunch of missing symbols....
>
> It's probably the same problem but with my trial SeaMonkey build it
> already happens when linking xpcom.dll:
>
> make.exe[7]: Entering directory `<path>suite/mozilla/xpcom/stub'
> nsXPComStub.cpp
> weakld: error: Unresolved symbol (UNDEF) '_NS_LogInit_P'.
> weakld: info: The symbol is referenced by:
> <path>\suite\mozilla\xpcom\stub\nsXPComStub.o
> weakld: error: Unresolved symbol (UNDEF) '_NS_Alloc_P'.
> weakld: info: The symbol is referenced by:
> <path>\suite\mozilla\xpcom\stub\nsXPComStub.o
> [... etc. ...]
>
> All these are #defined symbols from xpcom/reflect/xptcall/public/xptcall.h,
> xpcom/build/nsXPCOM.h, and xpcom/string/public/nsXPCOMStrings.h.
> I faintly remember having seen this #defined _symbols problem somewhere
> some time ago, but I cannot recall any details (or solutions)...
I notice that xpcom.def has no exports (same as gcc 3.3.5) so these
symbols must be accessed by _declspec so I wonder if perhaps that is not
working?
Dave
ps I also made it to xpcom.dll before failing
Ilya Zakharevich
<dave....@gmail.com>], who wrote in article <pv6dnfXXi6BBr1bV...@mozilla.org>:
> Its not hard to link with EMX DLLs, you just need to create a new import
> lib by making a DEF (using emximp) and create an alias, eg
> foo = _foo then use emximp to create the import lib from the DEF. (may
> need the emximp from klibc)
DLLs are, of course, easy.
> It is not recommended to mix static libraries from two different
> versions of GCC.
Libraries should not be compiler-dependent. (Unless some j**ks change
the ABI for no apparent reason...)
Yours,
Ilya
Paul Smedley
Once I have things tidied up, I could see how much effort it would
take to create a build that did not prepend the underscore for you.
Of course, doing so would break all my libs that were built with
libc06x & gcc 3.3.5 :(
--
Cheers,
Paul.
Peter Weilbacher
> I notice that xpcom.def has no exports (same as gcc 3.3.5) so these
> symbols must be accessed by _declspec so I wonder if perhaps that is not
> working?
> Dave
> ps I also made it to xpcom.dll before failing
Had the same thought overnight but now I found out again that NSPR uses
declspec, too, and that does link nicely. So it looks like it's a
problem of declspec in conjunction with C++. mozjs.dll and xpcomcor.dll
do link before the xpcom.dll failure, so it cannot really be C++ alone.
Ilya Zakharevich
Paul Smedley
<pa...@smedley.id.au>], who wrote in article <POn1Xm9ddZOp-p...@smedley.info>:
> > > OK - now that I have linking of Dos* symbols working correctly
> >
> > While this is fresh with you, can it be generalized? AFAIU, this
> > addition of "_" (for an unfathomable reason) is the main
> > uncompatibility with EMX-OMF... If one could remove it (optionally?),
> > EMX may be used with gcc4...
>
> Once I have things tidied up, I could see how much effort it would
> take to create a build that did not prepend the underscore for you.
> Of course, doing so would break all my libs that were built with
> libc06x & gcc 3.3.5 :(
I do not think that this should be of very high priority right now
(unless it is very easy to implement).
I was thinking more about having a pie and eating it too. Something
like -Zunderscore (or ASS_PREPEND_UNDERSCORE) which would allow
coexistence of two environments...
There may be two possible targets one could wish to explore: using
gcc4 with EMX libraries, and "porting" EMX to gcc4, so that both
libraries and startup code are EMX ones... I do not know whether all
3 modes (current, and these two) can coexist with such switches...
Unfortunately, myself, I never compiled anything with gcc3+, and I
haven't read the source code of the gcc3+ libc either. While all the
implicit indication I saw were of the "designed in a kindergarten"
syndrom, this impression of mine may be erroneous, so there may be no
*need* for compatibility with EMX.
Given very short time I can dedicate to tinkering with compilers, I do
not consider myself a very good judge of the current situation. What
do other people think?
Thanks,
Ilya
Peter Weilbacher
> I do not think that this should be of very high priority right now
> (unless it is very easy to implement).
>
> I was thinking more about having a pie and eating it too. Something
> like -Zunderscore (or ASS_PREPEND_UNDERSCORE) which would allow
> coexistence of two environments...
>
> There may be two possible targets one could wish to explore: using
> gcc4 with EMX libraries, and "porting" EMX to gcc4, so that both
> libraries and startup code are EMX ones... I do not know whether all
> 3 modes (current, and these two) can coexist with such switches...
Just a quick note: if you just take a quick look at the kLibc SVN (like
here http://svn.netlabs.org/libc/browser/trunk/ or
http://svn.netlabs.org/libc/browser/branches/libc-0.6) you will see that
the current code _is_ some kind of a port of EMX. Some parts of the
C-library are still unchanged from EMX times and that's also the reason
why all the tools are still called emx*.
I don't know what originally prompted the underscore thing but I am
pretty sure that Knut would not have added that without a good reason.
By now there is too much code that was changed to work with that and I
don't think we (who use GCC 3+) have time to change all that back.
But of course, if a -Zno_underscore would be possible, I would be happy,
too.
--
Please | Official Warpzilla Ports: http://www.mozilla.org/ports/os2/
reply in |
newsgroup | Enhanced OS/2 builds: http://pmw-warpzilla.sf.net/
Dave Yeo
>
> I don't know what originally prompted the underscore thing but I am
> pretty sure that Knut would not have added that without a good reason.
> By now there is too much code that was changed to work with that and I
> don't think we (who use GCC 3+) have time to change all that back.
> But of course, if a -Zno_underscore would be possible, I would be happy,
> too.
It is explained here,
http://svn.netlabs.org/libc/wiki/Faq#Callingconventions.
Dave
Ilya Zakharevich
Peter Weilbacher
<moz...@weilbacher.org>], who wrote in article <IOGdnf2tSs3LHFbV...@mozilla.org>:
> Just a quick note: if you just take a quick look at the kLibc SVN (like
> here http://svn.netlabs.org/libc/browser/trunk/ or
> http://svn.netlabs.org/libc/browser/branches/libc-0.6) you will see that
> the current code _is_ some kind of a port of EMX. Some parts of the
> C-library are still unchanged from EMX times and that's also the reason
> why all the tools are still called emx*.
IIRC, they started with -Zsys flavor, which is an EXTREMELY dumbed
down version with almost no support for POSIXification.
Yours,
Ilya
Ilya Zakharevich
Peter Weilbacher
> I don't know what originally prompted the underscore thing but I am
> pretty sure that Knut would not have added that without a good reason.
Judging by the fact that the explanation on
http://svn.netlabs.org/libc/wiki/Faq#Callingconventions is completely
bogus (note that DLL-related names are controlled by .DEF, not by some
compiler flags), I see no reason to assume this...
Yours,
Ilya
Andy Willis
Andy
Ilya Zakharevich
Andy Willis
<abwilli...@nospamattbi.com>], who wrote in article <q-GdnaElafBM9FDV...@mozilla.org>:
> > http://svn.netlabs.org/libc/wiki/Faq#Callingconventions.
> According to that... -D_System would do what -Zno_underscore would do.
No it's not. -D_System is what is needed to use underscored-.h files
with EMX.
Hope this helps,
Ilya
Paul Smedley
On Thu, 4 Sep 2008 08:10:47 UTC, Peter Weilbacher
<news...@weilbacher.org> wrote:
> This means that until Paul or somebody else comes up with a newer GCC,
> nightlies have to be built with extra patches applied and that cannot
> really be automated with Mercurial. And I think if I place such
> nightlies on the Mozilla FTP server, they should be accompanied by a
> README detailing the differences, which needs even more manual
> interaction.
I've uploaded this morning an updated build of GCC 3.4.6 where I've
successfully built the Mozilla CVS branch. I haven't had time yet to
find out how to download the Hg code and test there.
Please see http://www.smedley.info/os2ports/index.php?page=gcc
--
Cheers,
Paul.
Dave Yeo
> Please see http://www.smedley.info/os2ports/index.php?page=gcc
>
(keeping on topic to Mozilla bugs:) )
Clicking the patch link consistently crashes my Seamonkey (Mozilla/5.0
(OS/2; U; Warp 4.5; en-US; rv:1.9.1b1pre) Gecko/20080907144413
SeaMonkey/2.0a1pre) anyone else see this?
Dave
ps thanks for the great job, hopefully by tomorrow will be testing a
3.4.6 built Seamonkey
Peter Brown
Seems to work fine with Mozilla/5.0 (OS/2; U; Warp 4.5; en-US;
rv:1.9.1a2pre) Gecko/20080822010658 SeaMonkey/2.0a1pre plus the 29082008
updates applied.
Just had a quick look for a later 2.0a1pre build but do not seem to be
able to find 1 in the usual places. Is 20080907144413 your own build?
Regards
Pete
Dave Yeo
> Seems to work fine with Mozilla/5.0 (OS/2; U; Warp 4.5; en-US;
> rv:1.9.1a2pre) Gecko/20080822010658 SeaMonkey/2.0a1pre plus the 29082008
> updates applied.
>
>
> Just had a quick look for a later 2.0a1pre build but do not seem to be
> able to find 1 in the usual places. Is 20080907144413 your own build?
Yes, it is my own build. Hopefully just a temporary regression
Dave
Dave Yeo
> Clicking the patch link consistently crashes my Seamonkey (Mozilla/5.0
> (OS/2; U; Warp 4.5; en-US; rv:1.9.1b1pre) Gecko/20080907144413
> SeaMonkey/2.0a1pre) anyone else see this?
Actually downloading anything is now making Seamonkey vanish :(
Dave
Peter Weilbacher
Haven't had any problems and don't see that with this (20080916232255)
SM build.
Dave Yeo
>>
>> Actually downloading anything is now making Seamonkey vanish :(
>
> Haven't had any problems and don't see that with this (20080916232255)
> SM build.
Todays build (3.4.6 hg build) doesn't crash.
Dave
Paul Smedley
On Mon, 22 Sep 2008 04:08:16 UTC, Dave Yeo <dave....@gmail.com>
wrote:
I tried the hg build today but didn't get very far...
Things fail quite quickly with a bunch of sed errors (can't
find.......) - see log at http://smedley.info/build.log
Any suggestions? Needless to say, the same setmozenv works for
cvs.......
--
Cheers,
Paul.
Walter Meinl
wrote:
> Hi Guys,
>
> > Todays build (3.4.6 hg build) doesn't crash.
>
> I tried the hg build today but didn't get very far...
>
> Things fail quite quickly with a bunch of sed errors (can't
> find.......) - see log athttp://smedley.info/build.log
>
> Any suggestions? Needless to say, the same setmozenv works for
> cvs.......
>
> --
> Cheers,
>
> Paul.
Did you remove nsprbub/configure before you started building? When you
remove it, it should be recreated correctly by autoconf
Dave Yeo
As Walter mentioned there is a configure script to delete. Occasionally
it is needed to delete all configure scripts. Also did you add something
like
mk_add_options AUTOCONF=autoconf213
where autoconf213 is the name of the autoconf 2.13 script to .mozconfig?
Dave
Dave Yeo
> As Walter mentioned there is a configure script to delete. Occasionally
> it is needed to delete all configure scripts. Also did you add something
> like
> mk_add_options AUTOCONF=autoconf213
> where autoconf213 is the name of the autoconf 2.13 script to .mozconfig?
> Dave
Should add ac_add_options --disable-ogg to .mozconfig as well
Dave
Paul Smedley
On Mon, 22 Sep 2008 23:23:25 UTC, Dave Yeo <dave....@gmail.com>
wrote:
> On 09/22/08 07:39 am, Dave Yeo wrote:
Thanks! This has me going!
--
Cheers,
Paul.
Peter Weilbacher
Good. :-)
I built SM starting last night, around 2008092214 or so. Still see the
100% CPU problem on startup with GCC 3.4.6 and in a 3.3.5-based build
I get 100% CPU for quite a while when loading pages (but startup is OK).
So not even worth uploading as a manual nightly build...
--
Please Enhanced OS/2 builds of Mozilla applications
reply in http://pmw-warpzilla.sf.net/
newsgroup
Dave Yeo
> On 22.09.2008 06:08, Dave Yeo wrote:
>> On 09/20/08 04:00 pm, Peter Weilbacher wrote:
>>>> Actually downloading anything is now making Seamonkey vanish :(
>>> Haven't had any problems and don't see that with this (20080916232255)
>>> SM build.
>> Todays build (3.4.6 hg build) doesn't crash.
>
> Good. :-)
>
> I built SM starting last night, around 2008092214 or so. Still see the
> 100% CPU problem on startup with GCC 3.4.6 and in a 3.3.5-based build
> I get 100% CPU for quite a while when loading pages (but startup is OK).
> So not even worth uploading as a manual nightly build...
Sounds like one of us has a broken tree. Be interesting to see how
Paul's build fairs.
I've built seamonkey, Thunderbird and Firefox. They all run fine though
as often happens to me, Firefox had to be launched in safe mode before
it would come up without immediately crashing.
Dave
Ilya Zakharevich
<nospam...@ilyaz.org>], who wrote in article <D82dnQOLX6QHXVfV...@mozilla.org>:
> [A complimentary Cc of this posting was NOT [per weedlist] sent to
> <pa...@smedley.id.au>], who wrote in article <POn1Xm9ddZOp-p...@smedley.info>:
> > OK - now that I have linking of Dos* symbols working correctly
>
> While this is fresh with you, can it be generalized? AFAIU, this
> addition of "_" (for an unfathomable reason) is the main
> uncompatibility with EMX-OMF... If one could remove it (optionally?),
> EMX may be used with gcc4...
Hmm, looking at
http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html#SEC2
http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code-Gen-Options
maybe just using -fno-leading-underscore is the way to go...
Yours,
Ilya
Paul Smedley
On Wed, 24 Sep 2008 00:19:17 UTC, Dave Yeo <dave....@gmail.com>
wrote:
> On 09/23/08 09:49 am, Peter Weilbacher wrote:
Firefox seems to run OK here.....
--
Cheers,
Paul.
Peter Weilbacher
> [A complimentary Cc of this posting was NOT [per weedlist] sent to
> Ilya Zakharevich
> <nospam...@ilyaz.org>], who wrote in article<D82dnQOLX6QHXVfV...@mozilla.org>:
>> addition of "_" (for an unfathomable reason) is the main
>> uncompatibility with EMX-OMF... If one could remove it (optionally?),
>> EMX may be used with gcc4...
>
> Hmm, looking at
> http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html#SEC2
> http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code-Gen-Options
> maybe just using -fno-leading-underscore is the way to go...
Seems that GCC 3.3.5 and Paul's GCC 3.4.6 do understand this flag, but
the linker cannot deal with it.
But I really haven't understood why you view the underscore as such a
big problem. Paul ports dozens of programs without having to bother
about it and I personally haven't seen any programs where it would
matter, either. Projects that need different compilers for different
parts and where one would need to add some hacks to deal with this are
really rare on OS/2 nowadays.
--
Please | Official Warpzilla Ports: http://www.mozilla.org/ports/os2/
reply in |
newsgroup | Enhanced OS/2 builds: http://pmw-warpzilla.sf.net/
Ilya Zakharevich
<moz...@weilbacher.org>], who wrote in article <RfOdnV_1y5gUVELV...@mozilla.org>:
> Seems that GCC 3.3.5 and Paul's GCC 3.4.6 do understand this flag, but
> the linker cannot deal with it.
>
> But I really haven't understood why you view the underscore as such a
> big problem. Paul ports dozens of programs without having to bother
> about it and I personally haven't seen any programs where it would
> matter, either.
If not for underscore, he would be able to port hundreds of programs
in the same time, since the EMX libraries would be already available...
> Projects that need different compilers for different
> parts and where one would need to add some hacks to deal with this are
> really rare on OS/2 nowadays.
EMX CRT is really "professionally designed". So it would be nice to
be able to use EMX CRT with newer compilers. It looks like with
-fno-underscore one should be able to use it (maybe one would need to
massage the gcc library for code which would use it...).
Thanks,
Ilya
Peter Weilbacher
> [A complimentary Cc of this posting was NOT [per weedlist] sent to
> Peter Weilbacher
> <moz...@weilbacher.org>], who wrote in article<RfOdnV_1y5gUVELV...@mozilla.org>:
>> Seems that GCC 3.3.5 and Paul's GCC 3.4.6 do understand this flag, but
>> the linker cannot deal with it.
>>
>> But I really haven't understood why you view the underscore as such a
>> big problem. Paul ports dozens of programs without having to bother
>> about it and I personally haven't seen any programs where it would
>> matter, either.
>
> If not for underscore, he would be able to port hundreds of programs
> in the same time
It seems that you really don't have a clue what you are talking about.
> since the EMX libraries would be already available...
Who cares? We have kLibc.
>> Projects that need different compilers for different
>> parts and where one would need to add some hacks to deal with this are
>> really rare on OS/2 nowadays.
>
> EMX CRT is really "professionally designed".
The only thing that is better is that it is documented for the most
part. But again, almost everything still applies to kLibc.
> So it would be nice to
> be able to use EMX CRT with newer compilers. It looks like with
> -fno-underscore one should be able to use it
How? I don't see a way to compile with GCC 3 and link to emx*.dll.
Anyway, this sub-thread is in the wrong group and I have no interest
discussing this further.
Ilya Zakharevich
Peter Weilbacher
> >> But I really haven't understood why you view the underscore as such a
> >> big problem. Paul ports dozens of programs without having to bother
> >> about it and I personally haven't seen any programs where it would
> >> matter, either.
> > If not for underscore, he would be able to port hundreds of programs
> > in the same time
> It seems that you really don't have a clue what you are talking about.
It seems that you are confused... ;-)
> > since the EMX libraries would be already available...
> Who cares? We have kLibc.
Who cares? We already had hundreds of libs compiled with EMX. To
port many applications to LIBC, one needed to port all these libs to
klibc. And when a subversion of LIBC changes, one needs to redo all
this again...
> > EMX CRT is really "professionally designed".
> The only thing that is better is that it is documented for the most
> part.
IMO, the thing which is much better is that it looks like EM knew what
he did. ALL the easily visible choices decided in design of LIBC
(e.g., underscore, version-to-start-with, DLL versioning) were done
wrong. [As I said, I have not read the LIBC source code, so can only
extrapolate from what I already know...]
> > So it would be nice to
> > be able to use EMX CRT with newer compilers. It looks like with
> > -fno-underscore one should be able to use it
> How? I don't see a way to compile with GCC 3 and link to emx*.dll.
I have no time to experiment now, but why using -fno-underscore and
library path of EMX would not do it?
(Maybe one will need to rename the -lc library and the startup
object file too... Long time ago I made a patch to emxomfld which
emits the link386 command line when linking verbosely, so one could
see which renames are needed; do not know whether it is included now.)
> Anyway, this sub-thread is in the wrong group
Quite true.
Yours,
Ilya