SeaMonkey 1.18 static builds
SeaMonkey 1.18 static builds
A chap in France named Phillipe Martinez has a website at http://www.lamorelle.org. He's been doing and hosting static builds of SeaMonkey 1.18 and some other Mozilla products. Unfortunately, the SeaMonkey builds are browser only.
In response to a query, he was kind enough to produce static builds of the full SeaMonkey suite in both Gtk1 and Gtk2 versions.
The main repository is at http://www.lamarelle.org/mo-zi-lla/mozilla.php#smf
Direct download links are:
Gtk1: http://www.lamarelle.org/seamonkey/1.1. ... k1.tar.bz2
Gtk2: http://www.lamarelle.org/seamonkey/1.1. ... 86.tar.bz2
Update:
Phillipe has now done a static build of the full SeaMonkey 2.02 Gtk2 suite. Get it here:
2.02: http://www.lamarelle.org/seamonkey/2.0. ... 86.tar.bz2
Update: 02/21/2010
Phillipe now has a static build of SeaMonkey 2.03
2.03: http://www.lamarelle.org/seamonkey/2.0. ... 86.tar.bz2
Static builds tend to load faster on the sort of lower end hardware Puppy runs on, so these might be nice additions to the Puppy kit.
Phillipe is interested in feedback, so if you grab these, drop him a note at his website at http://www.lamarelle.org/lammail.php with your comments.
Update: 02/27/10
It looks like Puppy fans like this stuff. Phillipe mentioned in email that previously folks had downloaded his Firefox builds, and he'd seen about 6 downloads. In February, 28 people grabbed static SeaMonkey builds. I have to assume they were all Puppy users who saw my post here.
He also asked if I'd be interested in static builds of full SeaMonkey 2.X and Firefox 3.X. The answer was an emphatic "Yes! Merci beaucoup!", so I expect more nice things forthcoming in the next few days.
______
Dennis
In response to a query, he was kind enough to produce static builds of the full SeaMonkey suite in both Gtk1 and Gtk2 versions.
The main repository is at http://www.lamarelle.org/mo-zi-lla/mozilla.php#smf
Direct download links are:
Gtk1: http://www.lamarelle.org/seamonkey/1.1. ... k1.tar.bz2
Gtk2: http://www.lamarelle.org/seamonkey/1.1. ... 86.tar.bz2
Update:
Phillipe has now done a static build of the full SeaMonkey 2.02 Gtk2 suite. Get it here:
2.02: http://www.lamarelle.org/seamonkey/2.0. ... 86.tar.bz2
Update: 02/21/2010
Phillipe now has a static build of SeaMonkey 2.03
2.03: http://www.lamarelle.org/seamonkey/2.0. ... 86.tar.bz2
Static builds tend to load faster on the sort of lower end hardware Puppy runs on, so these might be nice additions to the Puppy kit.
Phillipe is interested in feedback, so if you grab these, drop him a note at his website at http://www.lamarelle.org/lammail.php with your comments.
Update: 02/27/10
It looks like Puppy fans like this stuff. Phillipe mentioned in email that previously folks had downloaded his Firefox builds, and he'd seen about 6 downloads. In February, 28 people grabbed static SeaMonkey builds. I have to assume they were all Puppy users who saw my post here.
He also asked if I'd be interested in static builds of full SeaMonkey 2.X and Firefox 3.X. The answer was an emphatic "Yes! Merci beaucoup!", so I expect more nice things forthcoming in the next few days.
______
Dennis
Last edited by DMcCunney on Sun 28 Feb 2010, 00:15, edited 7 times in total.
Hi DMcCunney
I noticed Phillipe has the Seamonkey-2.02 gGtk2 static build (browser only) so I downloaded it in Quirky 006 and it works fine, better than the compile I made of Seamonkey-2.0 built in Puppy 430.
Thanks for the link.
I noticed Phillipe has the Seamonkey-2.02 gGtk2 static build (browser only) so I downloaded it in Quirky 006 and it works fine, better than the compile I made of Seamonkey-2.0 built in Puppy 430.
Thanks for the link.
Puppy Linux Blog - contact me for access
He asked if I'd be interested in static builds of the full SeaMonkey 2.0 suite, and of Firefox 3.X, and I said an enthusiastic yes to both, so I expect we'll see more things coming.01micko wrote:Hi DMcCunney
I noticed Phillipe has the Seamonkey-2.02 gGtk2 static build (browser only) so I downloaded it in Quirky 006 and it works fine, better than the compile I made of Seamonkey-2.0 built in Puppy 430.
You're welcome. Drop Phillipe a note and let him know. He put up his stuff because the Gtk1 builds all seemed to disappear from the official archives in short order once Gtk2 was out. I think he was a little pleased that someone else happened upon his stuff and had a good use for it. If he gets an assortment of downloads and comments from Puppy users, it should encourage further efforts.Thanks for the link.
______
Dennis
Most Linux applications rely on shared libraries - collections of code that may be used by more than one program. Rather than include the code in every program, it's placed in a library. When the program is compiled, instructions to the compiler tell it "look in these external libraries for anything referenced that is not part of the code in the program." This sort of build is known as a "dynamic build". Library dependencies are resolved and linking happens when the program is run.DaveS wrote:What is meant by 'static build'?
When the program is run on a user's system, it looks for external libraries it was compiled to use and links against them. If the library isn't installed on the user's system, the program will fail to run, with an error indicating unresolved symbols in the missing libraries
A "static build" is one in which as much as possible of the code is compiled into the program itself, instead of being called from an external library file. Programs built "static" are much larger than dynamic builds, because most code is in the program itself instead of in external library files, but static builds tend to load faster on the sort of low end hardware commonly used for Puppy. Loading just requires loading the program itself with a few dependencies, instead of having to find and link against an assortment of external libraries. For example, the static build of Opera 10.10 on my Puppy box tends to load almost twice as fast as the dynamic build of Firefox 3.6, even though the total size of the programs are similar. The Firefox program itself is fairly small, and most of the code is in a number of external libraries
______
Dennis
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
One thing that DM did not emphasize is that ONLY the code REQUIRED is compiled into the static binaries. This basically means that if you have a 1MB dynamically linked program with 1000 lib dependencies that are 1MB each, but each one only has 1kb of code used by the program, then your static binary would only be about 2MB. A potential net SAVINGS of up to 998MB, but many would likely be useful to other programs so it will vary depending on your package selection.
It is not always as cut and dry as (almost all) the linux community has tried to make it. Even upx'd (compressed) down to <1MB, the static program will typically start and run faster and use less ram than the dynamic one.
One true downfall of static binaries is really a security issue. If libXYZ gets a bugfix/security update, you only have to update that one library and all of the programs linked against it are (usually) fixed. For static binaries all programs linked against it would need to be recompiled. Just hope it isn't libc, libz or some other library that most of your system shares.
Its not hard to overcome this if you keep the source trees - typically just delete the binary and do make, make install to relink and reinstall it, but then you have to repackage and redistribute all ## of the binaries that are linked against libXYZ... maybe 100-200MB worth of static binaries compared to a single 1MB library.
Given that most distros are distributed initially as a large single iso, it becomes a matter of simple logistics that you are going to save tons of server bandwidth and time repackaging by dynamically linking your libraries. Its not really an issue of size as it is time- especially now that hard drives are much larger and cheaper. The solution to this would be to distribute the source trees and "DEV" files instead of prelinked binaries. The only active distro planning static builds is "stali" (STAtic LInux) as far as I know, they may know something better.
Anyhow I said all of that to say this. Mozilla "static" builds are not completely static. Only the libraries inside the Seamonkey(Firefox no longer supports --enable-static) are built statically - the system libraries are linked dynamically (unless you add -Bstatic to your LDFLAGS) This mixed method is a good compromise because it adds the least amount of size to an existing system while also boosting the speed (especially since it is unlikely that other programs will need to link against libraries inside your seamonkey folder, since it is not typically in your LD_LIBRARY_PATH).
It possible to do mixed builds like this for any program by deleting the .so and leaving the .a or by compiling the libraries you want statically linked with --enable-static --disable-shared (your linker will do this automatically, first looking for lib*.so and then lib*.a). Barry does this for gparted and the large gtkmm pangomm atkmm... libraries since it is the only program in puppy that needs them. I have libboost* libICU libwebkit and some others statically compiled because of their size and because only a few programs need them (It also makes sharing packages more convenient when you don't have to track separate dependency libs)
I apologize if this was more confusing than informational. Is it still clear now?
It is not always as cut and dry as (almost all) the linux community has tried to make it. Even upx'd (compressed) down to <1MB, the static program will typically start and run faster and use less ram than the dynamic one.
One true downfall of static binaries is really a security issue. If libXYZ gets a bugfix/security update, you only have to update that one library and all of the programs linked against it are (usually) fixed. For static binaries all programs linked against it would need to be recompiled. Just hope it isn't libc, libz or some other library that most of your system shares.
Its not hard to overcome this if you keep the source trees - typically just delete the binary and do make, make install to relink and reinstall it, but then you have to repackage and redistribute all ## of the binaries that are linked against libXYZ... maybe 100-200MB worth of static binaries compared to a single 1MB library.
Given that most distros are distributed initially as a large single iso, it becomes a matter of simple logistics that you are going to save tons of server bandwidth and time repackaging by dynamically linking your libraries. Its not really an issue of size as it is time- especially now that hard drives are much larger and cheaper. The solution to this would be to distribute the source trees and "DEV" files instead of prelinked binaries. The only active distro planning static builds is "stali" (STAtic LInux) as far as I know, they may know something better.
Anyhow I said all of that to say this. Mozilla "static" builds are not completely static. Only the libraries inside the Seamonkey(Firefox no longer supports --enable-static) are built statically - the system libraries are linked dynamically (unless you add -Bstatic to your LDFLAGS) This mixed method is a good compromise because it adds the least amount of size to an existing system while also boosting the speed (especially since it is unlikely that other programs will need to link against libraries inside your seamonkey folder, since it is not typically in your LD_LIBRARY_PATH).
It possible to do mixed builds like this for any program by deleting the .so and leaving the .a or by compiling the libraries you want statically linked with --enable-static --disable-shared (your linker will do this automatically, first looking for lib*.so and then lib*.a). Barry does this for gparted and the large gtkmm pangomm atkmm... libraries since it is the only program in puppy that needs them. I have libboost* libICU libwebkit and some others statically compiled because of their size and because only a few programs need them (It also makes sharing packages more convenient when you don't have to track separate dependency libs)
I apologize if this was more confusing than informational. Is it still clear now?
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
It shouldn't. If the libraries are already installed, adding a static build of SeaMonkey won't remove them. It simply may not use them, as the code may be compiled into the SeaMonkey executable.mikeb wrote:yepI apologize if this was more confusing than informational. Is it still clear now?
One thought that entered my mind...would this affect gxine which is dependent on one or more mozilla librarie(s)?
If the libraries aren't installed, Gxine won't run.
______
Dennis
The static builds I linked to are tar.bz2 archives. The easiest install method is to extract them over the existing SeaMonkey installation directory. That will replace SeaMonkey, but shouldn't trash existing libraries.mikeb wrote:Well I was thinking about the scenario whereby someone replaces their existing seamonkey with a static build if they liked it and then find gxine not working....
mike
You could also choose to extract the SeaMonkey directory from the archive somewhere else for testing, and run it from there.
And I recall one complaint about Puppy was that the package manager provided no way to remove packages pre-installed in the distro. I don't think that's changed in the current distro. so it's not clear to me how a user could remove libs Gxine needed without deliberately trying to do so.
______
Dennis
- Colonel Panic
- Posts: 2171
- Joined: Sat 16 Sep 2006, 11:09
Thanks for the link dennis. I've now downloaded both the 1.1.18 and 2.0.3 static builds and they work really well - fast and stable with spell checking too.
Gigabyte M68MT-52P motherboard, AMD Athlon II X4 630, 5.8 GB of DDR3 RAM and a 250 GB Hitachi hard drive running Ubuntu 16.04.6, MX-19.2, Peppermint 10, PCLinuxOS 20.02, LXLE 18.04.3, Pardus 19.2, exGENT 200119, Bionic Pup 8.0 and Xenial CE 7.5 XL.
Note that Philippe now has static Gtk1 and Gtk2 builds of SeaMonkey 1.1.19, in full suite and browser only versions. It contains a few more security fixes but no new features.Colonel Panic wrote:Thanks for the link dennis. I've now downloaded both the 1.1.18 and 2.0.3 static builds and they work really well - fast and stable with spell checking too.
I posted about the release and provided links here.
1.1.19 is an end-of-life release, and will be the last release of the 1.1 branch. No one was contributing patches, and the machines hosting the build process were actually living in the basement of one of the engineers. He wanted to turn them off and take them out of service.
A SeaMonkey 2.04 release is out from Mozilla. I expect Phillipe will have 2.04 builds up fairly soon, and I'll note them here when he does.
______
Dennis
- Colonel Panic
- Posts: 2171
- Joined: Sat 16 Sep 2006, 11:09
Thanks and for the info Dennis. The 2 series updates itself automatically (just as Firefox does) so I doubt I'll need to download the 2.04 version.
Gigabyte M68MT-52P motherboard, AMD Athlon II X4 630, 5.8 GB of DDR3 RAM and a 250 GB Hitachi hard drive running Ubuntu 16.04.6, MX-19.2, Peppermint 10, PCLinuxOS 20.02, LXLE 18.04.3, Pardus 19.2, exGENT 200119, Bionic Pup 8.0 and Xenial CE 7.5 XL.
You may want to grab it. I believe the default Mozilla builds are dynamic, and I'm not sure what a dynamic build update of a static build installation would result in.Colonel Panic wrote:Thanks and for the info Dennis. The 2 series updates itself automatically (just as Firefox does) so I doubt I'll need to download the 2.04 version.
______
Dennis
- Colonel Panic
- Posts: 2171
- Joined: Sat 16 Sep 2006, 11:09
Thanks Dennis, you could well be right. I've had some trouble with downloading from Philippe's site on my own machine though (the download stops and starts a lot), so I tend to wait until I can access my local community centre's computers and do a couple of downloads at once.
Gigabyte M68MT-52P motherboard, AMD Athlon II X4 630, 5.8 GB of DDR3 RAM and a 250 GB Hitachi hard drive running Ubuntu 16.04.6, MX-19.2, Peppermint 10, PCLinuxOS 20.02, LXLE 18.04.3, Pardus 19.2, exGENT 200119, Bionic Pup 8.0 and Xenial CE 7.5 XL.
Makes sense. I have fast broadband and don't see DL issues, but others experience will differ. I don't see any great hurry, however. Nothing earthshaking will happen if you don't happen to grab SM 2.04 immediately.Colonel Panic wrote:Thanks Dennis, you could well be right. I've had some trouble with downloading from Philippe's site on my own machine though (the download stops and starts a lot), so I tend to wait until I can access my local community centre's computers and do a couple of downloads at once.
______
Dennis
I downloaded 1.19 browser only and built it in to a 4.3.1 variant that I stripped the previous Seamonkey from first. The download INCLUDES the libs gxine needs. Load time is very fast. No compatibility issues, it was even fine using my previous profile.
Flashblock and Newsfox both work fine. Not sure what I gained but it was an interesting exercise
Flashblock and Newsfox both work fine. Not sure what I gained but it was an interesting exercise
Spup Frugal HD and USB
Root forever!
Root forever!