Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.comp.software.seamonkey > #8626 > unrolled thread

SeaMonkey 2.53.24b(eta)1 is out now!

Back to article view | Back to alt.comp.software.seamonkey

Contents

  SeaMonkey 2.53.24b(eta)1 is out now! ant@zimage.comANT (Ant) - 2026-07-07 00:51 +0000
    Re: SeaMonkey 2.53.24b(eta)1 is out now! Gerhard Strangar <g.s@arcor.de> - 2026-07-07 12:19 +0000
      Re: SeaMonkey 2.53.24b(eta)1 is out now! frg <frgrahl@gmx.net> - 2026-07-07 19:53 +0200
    Re: SeaMonkey 2.53.24b(eta)1 is out now! Peter Müller <invalid@invalid.invalid> - 2026-07-07 17:16 +0200
      Re: SeaMonkey 2.53.24b(eta)1 is out now! frg <frgrahl@gmx.net> - 2026-07-07 19:52 +0200
        Re: SeaMonkey 2.53.24b(eta)1 is out now! Hank Rogers <Hank@nospam.invalid> - 2026-07-07 16:53 -0500
          Re: SeaMonkey 2.53.24b(eta)1 is out now! Gerhard Strangar <g.s@arcor.de> - 2026-07-08 03:49 +0000
            Re: SeaMonkey 2.53.24b(eta)1 is out now! Nuno Silva <nunojsilva@invalid.invalid> - 2026-07-08 08:06 +0100
              Re: SeaMonkey 2.53.24b(eta)1 is out now! Nuno Silva <nunojsilva@invalid.invalid> - 2026-07-08 09:10 +0100
                Re: SeaMonkey 2.53.24b(eta)1 is out now! Gerhard Strangar <g.s@arcor.de> - 2026-07-08 17:56 +0000
                  Re: SeaMonkey 2.53.24b(eta)1 is out now! frg <frgrahl@gmx.net> - 2026-07-08 21:53 +0200
                    Re: SeaMonkey 2.53.24b(eta)1 is out now! Geoff Welsh <GeeDubya@some.rr.com> - 2026-07-13 10:02 -1000
                  Re: SeaMonkey 2.53.24b(eta)1 is out now! Nuno Silva <nunojsilva@invalid.invalid> - 2026-07-20 08:57 +0100
                    Re: SeaMonkey 2.53.24b(eta)1 is out now! Gerhard Strangar <g.s@arcor.de> - 2026-07-20 18:24 +0000
                      Re: SeaMonkey 2.53.24b(eta)1 is out now! Dave Yeo <dave.r.yeo@gmail.com> - 2026-07-20 14:49 -0700
              Re: SeaMonkey 2.53.24b(eta)1 is out now! Gerhard Strangar <g.s@arcor.de> - 2026-07-08 17:51 +0000
                Re: SeaMonkey 2.53.24b(eta)1 is out now! Daniel70 <daniel47@nomail.afraid.org> - 2026-07-09 22:16 +1000
        Re: SeaMonkey 2.53.24b(eta)1 is out now! Dirk Fieldhouse <surname@gmx.net.plusremovethisandtherest.invalid> - 2026-07-08 18:29 +0100
          Re: SeaMonkey 2.53.24b(eta)1 is out now! Nuno Silva <nunojsilva@invalid.invalid> - 2026-07-20 08:43 +0100
            Re: SeaMonkey 2.53.24b(eta)1 is out now! Dave Yeo <dave.r.yeo@gmail.com> - 2026-07-20 14:41 -0700
              Re: SeaMonkey 2.53.24b(eta)1 is out now! Dirk Fieldhouse <surname@gmx.net.plusremovethisandtherest.invalid> - 2026-07-21 12:23 +0100
                Re: SeaMonkey 2.53.24b(eta)1 is out now! frg <frgrahl@gmx.net> - 2026-07-21 20:15 +0200
                  Re: SeaMonkey 2.53.24b(eta)1 is out now! Dirk Fieldhouse <surname@gmx.net.plusremovethisandtherest.invalid> - 2026-07-22 11:29 +0100
                    Re: SeaMonkey 2.53.24b(eta)1 is out now! frg <frgrahl@gmx.net> - 2026-07-22 16:24 +0200
                    Re: SeaMonkey 2.53.24b(eta)1 is out now! Dave Yeo <dave.r.yeo@gmail.com> - 2026-07-22 17:12 -0700
                      Re: SeaMonkey 2.53.24b(eta)1 is out now! Dave Yeo <dave.r.yeo@gmail.com> - 2026-07-22 19:26 -0700
                        Re: SeaMonkey 2.53.24b(eta)1 is out now! frg <frgrahl@gmx.net> - 2026-07-23 14:00 +0200
                          Re: SeaMonkey 2.53.24b(eta)1 is out now! frg <frgrahl@gmx.net> - 2026-07-23 14:03 +0200
                Re: SeaMonkey 2.53.24b(eta)1 is out now! Dave Yeo <dave.r.yeo@gmail.com> - 2026-07-21 13:44 -0700
                Re: SeaMonkey 2.53.24b(eta)1 is out now! Nuno Silva <nunojsilva@invalid.invalid> - 2026-07-22 09:31 +0100

Page 2 of 2 — ← Prev page 1 [2]

#8648

The issue is to have a build that runs on older h/w where 64-bit adds
more memory load for no benefit. In particular, I'm typing this on a 2GB
notebook where the RAM is fixed. Cross-compiling from a 64-bit would be
the only reasonable approach, I think.

Obviously platforms like this are limited but while its battery works
it's great for portability, like a smartphone but with an acceptable
user interface and no calls.

The same problem will arise for FF itself according to Moz's scheduled
removakl of x86 builds.

/df

-- 
London
UK

[toc] | [prev] | [next] | [standalone]

#8649

Dirk Fieldhouse wrote:
> The issue is to have a build that runs on older h/w where 64-bit adds
> more memory load for no benefit. In particular, I'm typing this on a 2GB
> notebook where the RAM is fixed. Cross-compiling from a 64-bit would be
> the only reasonable approach, I think.
> 
> Obviously platforms like this are limited but while its battery works
> it's great for portability, like a smartphone but with an acceptable
> user interface and no calls.
> 
> The same problem will arise for FF itself according to Moz's scheduled
> removakl of x86 builds.
> 
> /df
> 

Well I beg to differ and my stance is that anything with less that 4GB should 
be recycled unless you are a collector or need an old system for something 
special. I love older Thinkpads and one of my main laptops is an X230 from 
2012 but it is equipped with 16 GB and a 2 TB SSD. My most modern system is 
from 2018 so it is not that I push for replacing everything to run the latest 
Windows AI dross in full speed. I usually buy used but currently no need to go 
further than 6th gen Intel. 8GB and a 256 SSD is more or less the minimum 
these days unless you like self torture or confine yourself to very light 
browsing and mail only. Any media related site will eat up memory fast. You 
can get a used system from around 2010 with an early i5 or i7 for bird seed 
and it will likely consume much less energy than the old one, works well and 
pays for itself fast by reducing your energy bill.

x86 can still be cross compiled but the Windows one is currently broken 
because of a rust crate which needs a fix. At lest under Windows older gfx 
drivers before HD4000 and Nvidia Kepler are a pit too. I tossed out all AMD 
cards because of driver problems too.

ymmv
FRG

[toc] | [prev] | [next] | [standalone]

#8652

Really, if Windows 32-bit doesn't work that's just a further reason to
avoid it (LibreOffice FTW).

Until SM 2.53.21, SM 32.bit for Debian (eg) appeared automatically
(seamonkey-project.org/releases/{ver}/...linux-i686...,
seamonkey-mozilla-build for Ubuntu-alikes). But this

> Warning! The SeaMonkey version available for download from this page is outdated and may suffer from known security vulnerabilities. This page is only available for historic reference.
> We strongly advise you to download the current release instead. 

implies the need for an update that is missing.

Supposing that the over-stretched SM project won't be offering one (if
only) and assuming a sufficiently beefy cross-compiling platform, what
would I need to produce a 2.53.23-linux-i686 build?

Is it just a question of forking some repo, changing a build setting and
then fixing breakage Or is there a more fundamental blockage?

/df

-- 
London
UK

[toc] | [prev] | [next] | [standalone]

#8653

Dirk Fieldhouse wrote:
> Really, if Windows 32-bit doesn't work that's just a further reason to
> avoid it (LibreOffice FTW).
> 
> Until SM 2.53.21, SM 32.bit for Debian (eg) appeared automatically
> (seamonkey-project.org/releases/{ver}/...linux-i686...,
> seamonkey-mozilla-build for Ubuntu-alikes). But this
> 
>> Warning! The SeaMonkey version available for download from this page is outdated and may suffer from known security vulnerabilities. This page is only available for historic reference.
>> We strongly advise you to download the current release instead.
> 
> implies the need for an update that is missing.
> 
> Supposing that the over-stretched SM project won't be offering one (if
> only) and assuming a sufficiently beefy cross-compiling platform, what
> would I need to produce a 2.53.23-linux-i686 build?
> 
> Is it just a question of forking some repo, changing a build setting and
> then fixing breakage Or is there a more fundamental blockage?
> 
> /df
> 

 > would I need to produce a 2.53.23-linux-i686 build?

Set up Firefox 115 for building and SeaMonkey should be good too.

X11, Python <= 3.11 and Rust 1.73 unless you want to use the patch for later 
Rust versions:

https://bugzilla.mozilla.org/show_bug.cgi?id=1896958

frg

[toc] | [prev] | [next] | [standalone]

#8654

Dirk Fieldhouse wrote:
> Is it just a question of forking some repo, changing a build setting and
> then fixing breakage Or is there a more fundamental blockage?

I've abused the enable-optimize line in .mozconfig,
ac_add_options --enable-optimize="-march=i686 -O2"

This is on older SM that is 32 bit to begin with.
-march=pentium-m is probably needed to support SSE[2] and maybe -msse2 
also on the optimize line.
Dave

[toc] | [prev] | [next] | [standalone]

#8655

Dave Yeo wrote:
> Dirk Fieldhouse wrote:
>> Is it just a question of forking some repo, changing a build setting and
>> then fixing breakage Or is there a more fundamental blockage?
>
> I've abused the enable-optimize line in .mozconfig,
> ac_add_options --enable-optimize="-march=i686 -O2"
>
> This is on older SM that is 32 bit to begin with.
> -march=pentium-m is probably needed to support SSE[2] and maybe -msse2
> also on the optimize line.
> Dave

Forgot, you also probably need -m32 to force 32 bit, especially if you 
target a newer CPU
Dave

[toc] | [prev] | [next] | [standalone]

#8656

Dave Yeo wrote:
> Dave Yeo wrote:
>> Dirk Fieldhouse wrote:
>>> Is it just a question of forking some repo, changing a build setting and
>>> then fixing breakage Or is there a more fundamental blockage?
>>
>> I've abused the enable-optimize line in .mozconfig,
>> ac_add_options --enable-optimize="-march=i686 -O2"
>>
>> This is on older SM that is 32 bit to begin with.
>> -march=pentium-m is probably needed to support SSE[2] and maybe -msse2
>> also on the optimize line.
>> Dave
> 
> Forgot, you also probably need -m32 to force 32 bit, especially if you target 
> a newer CPU
> Dave

Should still be valid I hope:

ac_add_options --target=i686-pc-linux
ac_add_options --enable-application=comm/suite
mk_add_options MOZ_MAKE_FLAGS=-j8
ac_add_options --enable-optimize
ac_add_options --enable-release
ac_add_options --enable-jemalloc
ac_add_options --enable-js-shell
ac_add_options --enable-debug-symbols
ac_add_options --enable-tests
ac_add_options --enable-elf-hack

# ac_add_options --enable-stdcxx-compat
# ac_add_options --enable-alsa
# ac_add_options --disable-debug

ac_add_options 
--with-google-location-service-api-keyfile=/mnt/linuxdata/seamonkey/custom/google-api.key
ac_add_options 
--with-google-safebrowsing-api-keyfile=/mnt/linuxdata/seamonkey/custom/google-api.key
ac_add_options 
--with-mozilla-api-keyfile=/mnt/linuxdata/seamonkey/custom/mozilla-desktop-geoloc-api.key 


export 
COMM_HEAD_REPOSITORY=https://gitlab.com/seamonkey-project/seamonkey-2.53-comm
# export COMM_HEAD_REV=2_53_13_beta_01
export COMM_HEAD_REV=2_53_14_final
export 
GECKO_HEAD_REPOSITORY=https://gitlab.com/seamonkey-project/seamonkey-2.53-mozilla
export GECKO_HEAD_REV=2_53_14_final
export MOZ_INCLUDE_SOURCE_INFO=1

# Use ccache
ac_add_options --with-ccache=/usr/bin/ccache

# Needed to enable breakpad in application.ini
export MOZILLA_OFFICIAL=1

# Disable checking that add-ons are signed by the trusted root
MOZ_ADDON_SIGNING=0
# Disable enforcing that add-ons are signed by the trusted root
MOZ_REQUIRE_SIGNING=0

# Package js shell
export MOZ_PACKAGE_JSSHELL=1

# mk_add_options "export 
SOCORRO_SYMBOL_UPLOAD_TOKEN_FILE=/builds/crash-stats-api.token"

# Flags set for targeting x86.
export CROSS_COMPILE=1
export PKG_CONFIG_PATH=/usr/lib/pkgconfig
export MOZ_LINUX_32_SSE2_STARTUP_ERROR=1

CFLAGS="$CFLAGS -march=pentium-m -msse -msse2 -mfpmath=sse"
CXXFLAGS="$CXXFLAGS -march=pentium-m -msse -msse2 -mfpmath=sse"
#LDFLAGS="$LDFLAGS -L/usr/local/lib"
#export LD_LIBRARY_PATH=$HOME/.mozbuild/clang8/lib32:$HOME/.mozbuild/clang8/lib
#export LD_LIBRARY_PATH=$HOME/.mozbuild/gcc/lib

[toc] | [prev] | [next] | [standalone]

#8657

frg wrote:
> Dave Yeo wrote:
>> Dave Yeo wrote:
>>> Dirk Fieldhouse wrote:
>>>> Is it just a question of forking some repo, changing a build setting and
>>>> then fixing breakage Or is there a more fundamental blockage?
>>>
>>> I've abused the enable-optimize line in .mozconfig,
>>> ac_add_options --enable-optimize="-march=i686 -O2"
>>>
>>> This is on older SM that is 32 bit to begin with.
>>> -march=pentium-m is probably needed to support SSE[2] and maybe -msse2
>>> also on the optimize line.
>>> Dave
>>
>> Forgot, you also probably need -m32 to force 32 bit, especially if you 
>> target a newer CPU
>> Dave
> 
> Should still be valid I hope:
> 
...

Drat was incomplete. Copied wrong window:

mk_add_options 
MOZ_OBJDIR=/mnt/linuxdata/seabuild/release/comm-release56/i686-pc-linux-gnu
ac_add_options --with-l10n-base=/mnt/linuxdata/seamonkey/l10n/l10n-release
ac_add_options --enable-update-channel=release
ac_add_options --enable-debugqa
ac_add_options --enable-irc
ac_add_options --enable-dominspector

ac_add_options --target=i686-pc-linux
ac_add_options --enable-application=comm/suite
mk_add_options MOZ_MAKE_FLAGS=-j8
ac_add_options --enable-optimize
ac_add_options --enable-release
ac_add_options --enable-jemalloc
ac_add_options --enable-js-shell
ac_add_options --enable-debug-symbols
ac_add_options --disable-tests
# ac_add_options --enable-elf-hack

# ac_add_options --enable-stdcxx-compat
# ac_add_options --enable-alsa
# ac_add_options --disable-debug

#ac_add_options 
--with-google-location-service-api-keyfile=/mnt/linuxdata/seamonkey/custom/google-api.key
#ac_add_options 
--with-google-safebrowsing-api-keyfile=/mnt/linuxdata/seamonkey/custom/google-api.key
#ac_add_options 
--with-mozilla-api-keyfile=/mnt/linuxdata/seamonkey/custom/mozilla-desktop-geoloc-api.key 


export 
COMM_HEAD_REPOSITORY=https://gitlab.com/seamonkey-project/seamonkey-2.53-comm
# export COMM_HEAD_REV=2_53_13_beta_01
export COMM_HEAD_REV=2_53_24_final
export 
GECKO_HEAD_REPOSITORY=https://gitlab.com/seamonkey-project/seamonkey-2.53-mozilla
export GECKO_HEAD_REV=2_53_24_final
export MOZ_INCLUDE_SOURCE_INFO=1

# Use ccache
ac_add_options --with-ccache=/usr/bin/ccache

# Needed to enable breakpad in application.ini
export MOZILLA_OFFICIAL=1

# Disable checking that add-ons are signed by the trusted root
MOZ_ADDON_SIGNING=0
# Disable enforcing that add-ons are signed by the trusted root
MOZ_REQUIRE_SIGNING=0

# Package js shell
export MOZ_PACKAGE_JSSHELL=1

# mk_add_options "export 
SOCORRO_SYMBOL_UPLOAD_TOKEN_FILE=/builds/crash-stats-api.token"

# Flags set for targeting x86.
export CROSS_COMPILE=1
export PKG_CONFIG_PATH=/usr/lib/pkgconfig
export MOZ_LINUX_32_SSE2_STARTUP_ERROR=1

CFLAGS="$CFLAGS -march=pentium-m -msse -msse2 -mfpmath=sse"
CXXFLAGS="$CXXFLAGS -march=pentium-m -msse -msse2 -mfpmath=sse"
#LDFLAGS="$LDFLAGS -L/usr/local/lib"
#export LD_LIBRARY_PATH=$HOME/.mozbuild/clang8/lib32:$HOME/.mozbuild/clang8/lib
#export LD_LIBRARY_PATH=$HOME/.mozbuild/gcc/lib

[toc] | [prev] | [next] | [standalone]

#8650

Dirk Fieldhouse wrote:
> The issue is to have a build that runs on older h/w where 64-bit adds
> more memory load for no benefit. In particular, I'm typing this on a 2GB
> notebook where the RAM is fixed. Cross-compiling from a 64-bit would be
> the only reasonable approach, I think.
>
> Obviously platforms like this are limited but while its battery works
> it's great for portability, like a smartphone but with an acceptable
> user interface and no calls.
>
> The same problem will arise for FF itself according to Moz's scheduled
> removakl of x86 builds.
>
> /df
>

Yes cross compiling is likely the only way to compile the code.
The problem with the 64 bit world is 32 bit is no longer tested and may 
break at any time.
Ideally is to have someone who routinely compiles for 32 bit and ideally 
can fix issues or at least bring it up to the developers, who may or may 
not be interested in fixing the issue.
Dave

[toc] | [prev] | [next] | [standalone]

#8651

On 2026-07-21, Dirk Fieldhouse wrote:

> The issue is to have a build that runs on older h/w where 64-bit adds
> more memory load for no benefit. In particular, I'm typing this on a 2GB
> notebook where the RAM is fixed. Cross-compiling from a 64-bit would be
> the only reasonable approach, I think.

One thing where having an amd64 instead of IA-32 system running has a
positive difference is when compiling. Even if linking needs to make use
of swap and leads to thrashing, at least the per-process memory isn't
limited to 4 GiB. (But if you can cross-compile on a different system
with more resources, it's possibly not worth the trouble.)

> Obviously platforms like this are limited but while its battery works
> it's great for portability, like a smartphone but with an acceptable
> user interface and no calls.
>
> The same problem will arise for FF itself according to Moz's scheduled
> removakl of x86 builds.
>
> /df

-- 
Nuno Silva

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | alt.comp.software.seamonkey

csiph-web