Before anything else: I've read and digested the wiki page on binary size, and the related FAQ entry.

I'm knocking together a couple of programs in Lazarus to do jobs relating to IBM mainframes, partly because the existing tools run only on Windows, and partly to showcase Lazarus's capabilities in the mainframe community.

A program built using (some version of) Delphi comes to about 317Kb, but even with a manual strip the best I can do with Lazarus/FPC is pushing 3Mb. Now for domestic consumption I can live with that, but I don't think it looks very good if I publish binaries for download, and by the time I've got to several different OSes, CPUs and widget sets it's taking a significant amount of storage.

The FPC I'm using has been built from source, but I see I'm not using OPT='-CX' or similar... should I be?

The Lazarus I'm using has been built from source (make bigide). Should this have extra options to force everything possible in the LCL to be smartlinkable? Or once I've got the initial IDE should I be using it to rebuild itself, and in that case are there any options to be set?

Is there anything else obvious that I'm missing?

The initial size of Lazarus applications is 1,5MB unless smartlinking fails or is off, then it will be 3MB. Which operating system and architecture are you using? Which Lazarus/fpc versions?

Did you turn smartlinking on? -XX

Should this have extra options to force everything possible in the LCL to be smartlinkable?

No, AFAIK you don't need to specify anything special for the LCL build to get down to 1,5MB

Compiling an empty form, smartlink, withdout heaptrc, and stripped (use strip.exe) should come to 1.9 Mb on Lazarus trunk.

To get it further down, find initialization sections throughout the LCL, and disable stuff you do not need.
e.g. graphics uses units for the different gfx formats, if you do not use png, comment out the registration (though I am fot sure what is needed for icons...). That can save a few 100K if you are lucky. (Having that in, is the price for using RAD) (I did test this one a few years back)

Not sure, not tested, but you may also find resources included (such as icons) and decide you can do without, or with less. (Only guessing....)

Felipe Monteiro de Carvalho wrote

The initial size of Lazarus applications is 1,5MB unless smartlinking fails or is off, then it will be 3MB. Which operating system and architecture are you using? Which Lazarus/fpc versions?

Debian Linux on x86. Lazarus 0.9.30.4 and FPC 2.6.0 (both built from source as described), gtk2.

Did you turn smartlinking on? -XX

Yes. I've just wiped and reloaded all source files, tweaked project options for smartlinking and maximum optimisation, and got a 4Mb binary which doesn't change in size if I try to strip it. Looking at Lazarus output I can see fpc invoked with -MObjFPC -Scagi -CX -O3 -XX -vewnhi -l -oawsbrowser-i386-linux-gtk2 -dLCL -dLCLgtk2

When building FPC I habitually use -O- -gl because of getting decent backtraces on various platforms.

> Should this have extra options to force everything possible in the LCL to be smartlinkable? No, AFAIK you don't need to specify anything special for the LCL build to get down to 1,5MB

I've very carefully avoided all non-standard controls and packages with the intention that anybody should be able to grab a copy of Lazarus and rebuild my source. No graphics, no embedded icons or bitmaps, a TreeView and a ListBox with a splitter between them, custom .ini file handling and bit of glue code and that's about it.

4,367,408 on 0.9.30.4, no change if stripped.

3,436,684 on trunk (a few days old), no change if stripped.

FPC 2.6.0, compiled with -O- -gl (i.e. no explicit smartlinking etc.).

Noted, but not something I'd much like to do for a project being published since it would leave me open to a lot of questions if somebody tried to recompile and got a wildly different size.

I did some tests here and I guess this is simply the normal size of an app if you use ComCtrls. 1,5MB was for a minimal app with a form and some buttons. ComCtrls alone adds 1MB You can check this in the menu Project->Show used ppu files (might be 0.9.31+ only).

Still I find it a quite small size for our days. If you were using Gtk2 directly then your Windows build would have 150MB or something like that =) About Delphi 7, remember that it is a single-platform toolkit which just wraps the Windows API for most of what it does and is from 10 years ago. The LCL has it's own code to load image files in many formats for example.

A minimal HD these days has 250GB, so it is unlikely that a program which uses 0,001% of the HD will make any difference.

The iPhone SDK size is 4GB (they make you download XCode again even if you already have it), now that's big =) Actually big enough to potentially push me over my internet limit =(

A cheap Android HTC Wildfire phone comes with 2GB of storage, so even there your app is still aprox. 0,1% of the space =)

Felipe Monteiro de Carvalho wrote

I did some tests here and I guess this is simply the normal size of an app if you use ComCtrls. 1,5MB was for a minimal app with a form and some buttons. ComCtrls alone adds 1MB You can check this in the menu Project->Show used ppu files (might be 0.9.31+ only).

I get rather larger here but I'll take another look at that later- thanks for the "Show used" hint.

I'm in two minds over this. As I said, I want the app to be a useful Lazarus showcase as well as "scratching an itch". What I've done is basically a transcription of something that somebody originally wrote for Delphi which compiles to about 150Kb, which makes the Lazarus implementation look a bit bloated. On the other hand somebody else has rewritten it using MSC++ which as well as having a 270Kb binary also requires the author's own DLLs plus runtimes from MS... which makes Lazarus look pretty damn good.

But the bottom line is that the target audience is IBM mainframe hackers, used to handcrafting assembler and punching EBCDIC with their teeth. I don't want them to say "Binaries bigger than 1Mb? NBG".

In that case I guess there is little you can do.

There would be ways to change the LCL, to get a few 100 kb size down. And I have/had a dream to it is unlikely that I will ever have the time for it.

One Idea is to introduce a unit "GraphicsBase" (or similar) with dependant units, so that no image decoders are referred in the initialization (then they should be smart linkable). That unit could be used throughout LCL and packages (making sure any unit that requires a specific image format, still uses the unit, which registers that.

The unit Graphic, would use all the "registration" units, and forward all interface declaration.

Any LCL based app uses graphics in the user unit. That would be kept default. So all existing app (and all unmodified new apps) would work 100% as they do now.

But a user can change the uses clause in his own app, and drop some balance.

However, that is a lot of work, lot of testing, lot of maintenance. And still at best a few 100 kb of size saved. Then the search would have to be continued, where else can some ballast be removed....

Martin wrote

Compiling an empty form, smartlink, withdout heaptrc, and stripped (use strip.exe) should come to 1.9 Mb on Lazarus trunk.

As I remember that was about 1.6 Mb but with win32 widgetset. Gtk2 widgetset need much work to achieve the same results (as you should remember the main problem is code like If someobject is TSomeLCLClass then ....).

Also we can split resources to add between widgetsets. For example os x widgetsets does not need drag cursors because they are built in. Gtk does not need various button images because of the same reason.

Best regards,
Paul Ishenin

And windows does not usually display button images.

So they get included, only because people can turn the property to "on"

I think, the same trick can be used.
- Have them included by a unit that is not used in the LCL (and check for failure, if trying to use them)
- But have them by default in every app's uses

Then users can strip them off, if they want

Maybe it would be better to show non-GUI executables? Those are normally much smaller. Also these might be more useful on a mainframe?

Regards,
Sven

The couple of things I'm looking at are both GUI-oriented. The first file which is an image of a mainframe tape, logs the start of each record, and then allows each to be (decoded from EBCDIC and) displayed. As far as I can tell, nobody's done this for anything other than Windows. The second is a telnet terminal for IBM's APL\1130, which can otherwise only be used by a horrible hack.

So while neither has any pretension to actually run on a mainframe, I'm still fairly sensitive to criticism if any of the "old school" starts grumbling that they're a couple of orders of magnitude larger than they need to be.

The main reason they are larger is because they contain all the cross platform abstraction... You might hold this statement under their noses ;)

Note: Executables produced by Delphi 2009 or newer in their default settings are also larger than ones produced by older Delphi compilers, because of the extended RTTI.

Regards,
Sven

Mark Morgan Lloyd wrote

Before anything else: I've read and digested the wiki page on binary size, and the related FAQ entry.

Good.

With (some version of) Lazarus, or with the current version ? :-)

Older versions are smaller, also with Lazarus. And, as with older Delphi's essentially unsupported.

Now for domestic consumption I can live with that, but I don't think it looks very good if I publish binaries for download, and by the time I've got to several different OSes, CPUs and widget sets it's taking a significant amount of storage.

Yes. 300 of them are 1 GB, about $0.1 worth of harddisk space at $100/TB. Uncompressed. About a buck if you use enterprise discs.

The FPC I'm using has been built from source, but I see I'm not using OPT='-CX' or similar... should I be?

-CX to build units and -XX to use programs (and both for a combination).

The -CX is the "compile" part, -XX is the hint to the linker.

Debug info (-Xs aka strip) and smartlinking (-CX -XX) are the main ones.

The -XXs sometimes fails with some external linker versions. When in doubt, manually use the strip command, except on windows targets.

Can't see it in trunk. Is it from an optional package?

I get rather larger here but I'll take another look at that later- thanks for the "Show used" hint.

Brought trunk up to date, compiled with 2.6.0. FPC itself is compiled with -O- -gl, ld is version 2.20.1.

On Linux x86 (Debian "Squeeze") with gtk2, freshly-created minimal project with full optimisation, no debug, optimise for minimum size and smart linking comes to 3,459,960 bytes.

That's... such a disparity from what I've been told to expect that I'd appreciate any suggestions as to where I should be looking for problems.

For clarification: 1.9 MB was for win32 exe (1.5 is an old value for w32)

As someone mentioned, other WS could differ

But the bottom line is that the target audience is IBM mainframe hackers, used to handcrafting assembler and punching EBCDIC with their teeth. I don't want them to say "Binaries bigger than 1Mb? NBG".

I wonder how mainframe applications can make use of a GUI at all?

DoDi

really? ummm... AOL is the one that stick in my mind but there is also (not compuserve) one that is now based in mexico... t'was popular way back... i was even experimenting with its protocol between old-school bbs' and custom terminals and/or add-on protocols... i just cannot think of this one but there are also others that were used between bbs door games/apps and the terminal... globalwar was one of those games and tradewars also had one ;)

From my limited experience, either all or none :-) To a much greater extent than unix-based systems they rely on having smart terminals to do all the interactive stuff, and while waiting for something to happen sit there in a halted state (on a test system here, I see a something happen every couple of minutes spinning for a couple of thousand cycles).

There's not very much difference between a 3270 terminal (and its equivalents from other manufacturers) and a classic web page with embedded forms: stuff gets sent to the terminal, the user fills fields in, changed areas get sent back. All of the frontend stuff can be wrapped in the same sort of GUI as a web browser gets, in fact IBM seem to have moved seamlessly to browsers rather than their classic terminals.

It appears than many mainframe people make a virtue of the backends being written in assembler, for efficiency and- these days- geek cred. And up until around 2000, that assembler was pretty limited, e.g. all addressing was based on 12-bit offsets. These days a mainframe can run Linux, X11 and so on, but it's not what they were designed for and probably isn't the best way of using its specialised talents.

Building FPC with similar optimisation etc. reduces the binary to 3,414,296 bytes, presumably by knocking out 40K of RTL/FTL which seems realistic.

That's... such a disparity from what I've been told to expect that I'd appreciate any suggestions as to where I should be looking for problems.

LCL is a heavy-weight toolkit (memory and size). If size is a serious issue, move over to a more "light weight" (here I mean size, not features) toolkit where you can still get > 1MB executables. This is a big plus point for older WinCE devices where you only have 64-128MB user storage. fpGUI toolkit seems popular on the WinCE platform for exactly this reason [gauging this from user feedback I have received].

Mark Morgan Lloyd wrote

Can't see it in trunk. Is it from an optional package?

No, it is part of the standard IDE. For me it is right under "Project Options".

That's why I ask - the client-server protocol doesn't deserve a GUI on the mainframe. I also assume that the protocol restricts the graphics capabilities, if there are any.

IMO every client type requires a different protocol, and specific preparation of the data to be sent to the terminals. Doesn't this require an dedicated widgetset in the LCL, for every client type?

This in turn would require to compile a Lazarus application separately, for all supported client types (widgetsets). Otherwise another layer between the (then abstract) LCL components and their transfer to specific client types had to be implemented in the LCL.

DoDi

I don't see it here, on trunk built last night. Is that [Main menu] -> Project -> Project Options... and if so which page?

Graeme Geldenhuys wrote

On 21 March 2012 12:42, Mark Morgan Lloyd <markMLl.lazarus at ....> wrote:> A program built using (some version of) Delphi comes to about 317Kb, but> even with a manual strip the best I can do with Lazarus/FPC is pushing 3Mb.> Now for domestic consumption I can live with that, but I don't think it> looks very good if I publish binaries for download, and by the time I've got> to several different OSes, CPUs and widget sets it's taking a significant> amount of storage. LCL is a heavy-weight toolkit (memory and size). If size is a seriousissue, move over to a more "light weight" (here I mean size, notfeatures) toolkit where you can still get > 1MB executables. This is abig plus point for older WinCE devices where you only have 64-128MBuser storage. fpGUI toolkit seems popular on the WinCE platform forexactly this reason [gauging this from user feedback I have received].

NO. Definitely not, under the circumstances. As I've already said: what I'm trying to do is showcase Lazarus for a community that is well-aware of Pascal but does not so far have an FPC port, if somebody wants to tinker with the programs I most definitely don't want him to have to download a hodgepodge of external libraries and packages.

I'm by no means averse to something like fpGUI for local use, particularly for Chumby-style appliances- provided obviously that they're not swept into irrelevance by iPad and Android.

It's part of the Cody package: http://wiki.lazarus.freepascal.org/Cody

Regards,
Sven

Mark Morgan Lloyd wrote

NO. Definitely not, under the circumstances. As I've already said: what

No problem, just thought I would mention it.

BTW:
[just for comparison sake]
By default a simple test app - one Form, one Button and one Label, produces a 800KB 64-bit executable under Linux using FPC 2.6.1. A 32-bit executable will probably be 30% smaller than that. This is just with smartlinking and strip enabled - no other optimizations. So I could probably reduce those sizes even more if I wanted to.

tinker with the programs I most definitely don't want him to have to download a hodgepodge of external libraries and packages.

Umm, you do know that LCL based apps have a HUGE dependency list compared to fpGUI ! So the "hodgepodge of external libraries" will be when using LCL, *not* when using fpGUI.

-----------------------------------------------
$ cd fpgui_test
$ ldd project1
linux-vdso.so.1 => (0x00007fff2f1ff000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f4968959000) libXft.so.2 => /usr/lib/libXft.so.2 (0x00007f4968744000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007f49684bd000) libc.so.6 => /lib/libc.so.6 (0x00007f496813a000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007f4967f05000) libxcb.so.1 => /usr/local/lib/libxcb.so.1 (0x00007f4967ce7000) libdl.so.2 => /lib/libdl.so.2 (0x00007f4967ae3000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007f49678d9000) libz.so.1 => /lib/libz.so.1 (0x00007f49676c1000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4968cb4000)
libexpat.so.1 => /lib/libexpat.so.1 (0x00007f4967498000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f4967294000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f496708d000)

$ cd ../lcl_test
$ ldd project1
linux-vdso.so.1 => (0x00007fff769ff000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007fb813194000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00007fb812e5e000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x00007fb812c41000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00007fb81261f000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x00007fb812372000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007fb812129000) libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x00007fb811e4b000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00007fb811c46000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00007fb811a41000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x00007fb8117f7000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00007fb811574000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x00007fb811352000) libdl.so.2 => /lib/libdl.so.2 (0x00007fb81114e000) libc.so.6 => /lib/libc.so.6 (0x00007fb810dcb000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb8133d6000)
libxcb.so.1 => /usr/local/lib/libxcb.so.1 (0x00007fb810bad000) libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0x00007fb8108fa000) librt.so.1 => /lib/librt.so.1 (0x00007fb8106f2000) libm.so.6 => /lib/libm.so.6 (0x00007fb81046e000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00007fb81025c000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007fb810052000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00007fb80fe4e000) libXi.so.6 => /usr/lib/libXi.so.6 (0x00007fb80fc3e000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00007fb80fa35000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00007fb80f82a000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00007fb80f61d000) libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0x00007fb80f41a000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x00007fb80f216000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007fb80f010000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x00007fb80ede6000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007fb80eb5f000) libz.so.1 => /lib/libz.so.1 (0x00007fb80e948000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007fb80e713000) libpcre.so.3 => /lib/libpcre.so.3 (0x00007fb80e4e4000) libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0x00007fb80e28b000) libdirectfb-1.2.so.0 => /usr/lib/libdirectfb-1.2.so.0 (0x00007fb80e007000) libfusion-1.2.so.0 => /usr/lib/libfusion-1.2.so.0 (0x00007fb80ddfd000) libdirect-1.2.so.0 => /usr/lib/libdirect-1.2.so.0 (0x00007fb80dbe4000) libpng12.so.0 => /lib/libpng12.so.0 (0x00007fb80d9bc000) libxcb-render-util.so.0 => /usr/lib/libxcb-render-util.so.0 (0x00007fb80d7b8000)
libxcb-render.so.0 => /usr/local/lib/libxcb-render.so.0 (0x00007fb80d5af000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00007fb80d3aa000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007fb80d1a4000) libresolv.so.2 => /lib/libresolv.so.2 (0x00007fb80cf8b000) libselinux.so.1 => /lib/libselinux.so.1 (0x00007fb80cd6c000) libexpat.so.1 => /lib/libexpat.so.1 (0x00007fb80cb43000)

-----------------------------------------------

for Chumby-style appliances- provided obviously that they're not swept into irrelevance by iPad and Android.

fpGUI will have Android support very soon (just waiting on my next phone upgrade). ;-)

Thanks Sven, I'll look at that one later if nobody has any quick ideas.

I beg to differ that LCL apps have huge dependencies =)

[felipe at localhost lazclock]$ ldd lazclock
linux-gate.so.1 => (0xffffe000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb774a000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb7738000) libc.so.6 => /lib/i686/libc.so.6 (0xb75d2000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb75b3000)
libdl.so.2 => /lib/libdl.so.2 (0xb75ae000)
/lib/ld-linux.so.2 (0xb789d000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb75aa000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb75a3000)

Even smaller then fpgui because LCL-CustomDrawn has it's own text rendering system =)

You can test for yourself
lazarus-ccr/applications/lazclock/lazclock.lpi against LCL-CustomDrawn

I think it's part of the "cody" package

In any event: in the current case all I'm doing is putting together a couple of developer-oriented programs that run on PCs.

I think I said above, I'm currently not
trying to have anything that runs on a mainframe, and neither am I trying to implement a general-purpose terminal emulator.

/If/ there were an FPC port to run on a mainframe, it would see something roughly comparable to stdin/stdout (possibly using EBCDIC- let's not go there).

/If/ I were trying to write a terminal emulator, then of course it would need to talk 3270 (possibly with SNA, or alternatively using the equivalent Burroughs etc. protocols).

I'm not trying to do either of those things, but if I were then the clientside stuff could obviously be wrapped in a GUI in exactly the same way that HTTP/HTML is wrapped in a GUI or in the same way that AlphaWindows assumed a smart terminal with a GUI.

Felipe Monteiro de Carvalho wrote

Even smaller then fpgui because LCL-CustomDrawn has it's own text rendering system =)

Interesting, but unfortunately it seems LCL-CustomDrawn is still far from real-world usage, so I don't think it can be counted (yet). From what I have read, it doesn't seem feature complete or stable. eg: just dropping a TLabel on a TForm, gives me an instant
$ gdb ./project1
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /tmp/test2/project1...done.
(gdb) break fpc_raiseexception
Breakpoint 1 at 0x5c7380
(gdb) run
Starting program: /tmp/test2/project1
WARNING: TLazIntfImage.ChooseRawBitsProc Unsupported BitsPerPixel=0 WARNING: TLazIntfImage.ChooseRawBitsProc Unsupported BitsPerPixel=0 WARNING: TLazIntfImage.ChooseRawBitsProc Unsupported BitsPerPixel=0 WARNING: TLazIntfImage.ChooseRawBitsProc Unsupported BitsPerPixel=0

Program received signal SIGSEGV, Segmentation fault. 0x00000000005c6934 in fpc_do_is ()
(gdb) bt
#0 0x00000000005c6934 in fpc_do_is ()
#1 0x00007fffffffcdd0 in ?? ()
#2 0x00000000004d9681 in SELECTOBJECT (this=0x7ffff7f79040, DC=140737353524096, GDIOBJ=18446744073573964480)
at ../../../../lazarus/lcl/interfaces/customdrawn/customdrawnwinapi.inc:5323 #3 0x000000000043ea23 in DRAWTEXT (this=0x7ffff7f79040, DC=140737353524096, STR=0x7ffff7ff1ad0 "Label1", COUNT=6, RECT=..., FLAGS=352) at ../../../lazarus/lcl/include/intfbasewinapi.inc:744 #4 0x00000000004c6399 in DRAWTEXT (DC=140737353524096, STR=0x7ffff7ff1ad0 "Label1", COUNT=6, RECT=..., FLAGS=352) at ../../../lazarus/lcl/include/winapi.inc:216
#5 0x00000000004939df in TEXTRECT (this=0x7ffff7f49cc0, ARECT=..., X=0, Y=0, TEXT=0x7ffff7ff1ad0 "Label1", STYLE=...)
at ../../../lazarus/lcl/include/canvas.inc:1312
#6 0x0000000000552faa in PAINT (this=0x7ffff7f98ed0) at ../../../lazarus/lcl/include/customlabel.inc:473 #7 0x00000000005288ae in WMPAINT (this=0x7ffff7f98ed0, MESSAGE=...) at ../../../lazarus/lcl/include/graphiccontrol.inc:64 #8 0x00000000005c6e41 in SYSTEM_TOBJECT_$__DISPATCH$formal () #9 0x00000000005287d8 in DESTROY (this=0x7ffff7f98ed0, vmt=0x7fffffffd338) at ../../../lazarus/lcl/include/graphiccontrol.inc:46 #10 0x000000000051c0e3 in PERFORM (this=0x7ffff7f98ed0, MSG=15, ---Type <return> to continue, or q <return> to quit--- WPARAM=140737353524096, LPARAM=0)
at ../../../lazarus/lcl/include/control.inc:1402
#11 0x000000000050ca3f in PAINTCONTROLS (this=0x7ffff7f407f0, DC=140737353524096, FIRST=0x0)
at ../../../lazarus/lcl/include/wincontrol.inc:4826 #12 0x000000000050c7d0 in PAINTHANDLER (this=0x7ffff7f407f0, THEMESSAGE=...) at ../../../lazarus/lcl/include/wincontrol.inc:4744 #13 0x00000000005115b7 in WMPAINT (this=0x7ffff7f407f0, MSG=...) at ../../../lazarus/lcl/include/wincontrol.inc:6606 #14 0x0000000000528f7d in WMPAINT (this=0x7ffff7f407f0, MESSAGE=...) at ../../../lazarus/lcl/include/customcontrol.inc:112 #15 0x00000000005c6e41 in SYSTEM_TOBJECT_$__DISPATCH$formal () #16 0x0000000000528f38 in ?? ()
#17 0x00007ffff7f407f0 in ?? ()
#18 0x0000000000000001 in ?? ()
#19 0x000000000000000f in ?? ()
#20 0x00007fffffffd910 in ?? ()
#21 0x00007ffff7f407f0 in ?? ()
#22 0x0000000000000001 in ?? ()
#23 0x00007fffffffdbc8 in ?? ()
#24 0x00007fffffffe250 in ?? ()
#25 0x0000000000000000 in ?? ()
(gdb)
----------------------------------------------

Removing the TLabel and replacing it with a TButton does work however. Though it produces some nasty X11 errors when I quit the application.

------------------------------------------
$ ./project1
WARNING: TLazIntfImage.ChooseRawBitsProc Unsupported BitsPerPixel=0 WARNING: TLazIntfImage.ChooseRawBitsProc Unsupported BitsPerPixel=0 WARNING: TLazIntfImage.ChooseRawBitsProc Unsupported BitsPerPixel=0 WARNING: TLazIntfImage.ChooseRawBitsProc Unsupported BitsPerPixel=0 X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 4 (X_DestroyWindow) Resource id in failed request: 0x840decc0
Serial number of failed request: 127
Current serial number in output stream: 128
------------------------------------------

Either way, interesting none the less. Just a quick glans at the LCL-CustomDrawn text code. It seems like a Object Pascal implementation of the FreeType library. Correct? Who did that work? And how up to date is it with the actual FreeType library? Are all FreeType library features implemented? glyph vector data extraction, bitmap fonts, anti-alias hinting, kerning, text rotation etc..

Depending on the license, I might just take a look at that code too. ;-)

Graeme Geldenhuys wrote

Interesting, but unfortunately it seems LCL-CustomDrawn is still far from real-world usage, so I don't think it can be counted (yet). From what I have read, it doesn't seem feature complete or stable. eg: just dropping a TLabel on a TForm, gives me an instant me it works, strange. But I always use Mageia, never Ubuntu,

probably LazFreeType failled to find the fonts in your system.

Could you show me the output of "locate .ttf" ? (a stripped down version ideally with each dir occuring only once)

http://wiki.lazarus.freepascal.org/LazFreeType

Yes, it is a modification of the original FreeType written in Pascal.

circular from the forum wrote everything so I have no idea about your questions. You can ask the questions again in the LazUtils section of the forum and maybe he will answer:
http://www.lazarus.freepascal.org/index.php/board,53.0.html

Depending on the license, I might just take a look at that code too. ;-)

http://wiki.lazarus.freepascal.org/LazFreeType#License

There are no restrictions, but want credits. Maybe I'll implement a --credits command line option and consider it fullfilled. LCL-CustomDrawn-Android currently uses native text, so is unaffected by this requirement.

Felipe Monteiro de Carvalho wrote

Even smaller then fpgui because LCL-CustomDrawn has it's own text rendering system =)

But can it do this? ;-)

[see attached screenshot]

Felipe Monteiro de Carvalho wrote

Could you show me the output of "locate .ttf" ? (a stripped down version ideally with each dir occuring only once)

I zipped the output to make it smaller. Sorry, I have no idea how to "filter" the output to only show unique directory paths. Your regex skills are probably better than mine.

http://wiki.lazarus.freepascal.org/LazFreeType Yes, it is a modification of the original FreeType written in Pascal.

Amazing what some people can do (or have time for). At least they prove that Object Pascal can do exactly what C/C++ can! :) Thanks for the information, I'll post some questions and take a close look at the code at some point.

2012/3/22 Graeme Geldenhuys :

WOW!!!
clap-clap-clap!

Marcos Douglas

Marcos Douglas wrote

WOW!!! clap-clap-clap!

:-)
I wish I could take all the credit, but I can't. Milano did some excellent work with AggPas. I then incorporated it into fpGUI as one of the standard canvas classes (and made sure it's 100% backward compatible with the previous generation of Native API canvas classes).

Can it be that you forget the attachment?

Regards,
Sven

Sven Barth wrote

Can it be that you forget the attachment?

Oops, the compression ratio was set to high. ;-)

2012/3/22 Graeme Geldenhuys :

But can it do this? ?;-)

Well, mine can read your GPS position, accelerometer info and send SMSes in Android phones =D And it also works in Mac OS X with Cocoa ...

And anyway, what people really want is the LCL, not yet another API. You can compare the download numbers and see. The Android VM Image already counts more then 2000 downloads...

Now that you have attached your file I need to say: You don't need regex skills for that. The following program would have been sufficient:

=== program begin ===

program uniquepaths;
{$mode objfpc}{$H+}
uses
   sysutils, inifiles;
var
   slist: THashedStringList;
   s: String;
begin
   slist := THashedStringList.Create;
   try
     while not Eof(Input) do begin
       Readln(s);
       s := ExtractFilePath(s);
       if slist.IndexOf(s) < 0 then begin
         slist.Add(s);
         Writeln(s);
       end;
     end;
   finally
     slist.Free;
   end;
end.

=== program end ===

Regards,
Sven

2012/3/22 Graeme Geldenhuys :

Oops, the compression ratio was set to high. ;-)

Are you using the latest Lazarus SVN?

Because if it was a font or system compatibility issue then the button would not work. So I suspect you are using an old revision.

Felipe Monteiro de Carvalho wrote

You can test for yourself lazarus-ccr/applications/lazclock/lazclock.lpi against LCL-CustomDrawn

You cheated - the clock face is a PNG image. ;-)

Here is a quick fpGUI version. :) Added features includes: anti-aliased line drawing for the clock arms. For good measure, I also added slight alpha blending (transparency) so you can see where the clock arms cross each other.

http://opensoft.homeip.net:8080/~graemeg/fpGUI_Clock.png

Next I'll work on recreating the clock face in pure Canvas painting routines (no PNG background image). I've always wanted a "clock demo" in fpGUI - what toolkit doesn't have a clock demo. :-D

PS:
Your clock demo crashes on my system when I run it, because it looks for the PNG file somewhere else in the system, instead of the current working directory 'skins'. Yes, when deploying an app, it is good practice to use the system resource folders, but for demos, they are normally self contained, so use local resources.

Sven Barth wrote

Now that you have attached your file I need to say: You don't need regex skills for that. The following program would have been sufficient:

Rolling on the floor laughing! Once again, proof that Object Pascal can do everything other languages or tools can. :)

Felipe Monteiro de Carvalho wrote

Are you using the latest Lazarus SVN?

A revision from last week. Is that too old? I'll get another Lazarus update, just in case.

PS:
I'm using 64-bit Linux with FPC 2.6.1

Graeme Geldenhuys wrote

PS: Your clock demo crashes on my system when I run it, because it looks for the PNG file somewhere else in the system

Use the "install.sh" bash script

Felipe Monteiro de Carvalho wrote

I did some tests here and I guess this is simply the normal size of an app if you use ComCtrls. 1,5MB was for a minimal app with a form and some buttons. ComCtrls alone adds 1MB You can check this in the menu Project->Show used ppu files (might be 0.9.31+ only).

You've hit it on the head. Cody shows that ComCtrls is being pulled in as part of LCLBase, even if none of its controls are being used (in the current case, the test form and associated unit are entirely empty).

Shouldn't at least some of this be excluded by smartlinking?

Cody values are before smart linking.

I heard there is a compiler flag that shows information after smart linking.

Mattias

If anybody has any thoughts as to how to enable this I'd be interested to know. Otherwise I'll just have to live with the issue, noting that in general it's a one-time overhead.

Hello,

This is clearly something from UNIXes. I just tested using LCL-Win32 and a minimal app with 1 form and 1 button has 1,62MB

In Mac OS X my result was 2,8MB

I suspect that the smartlinking is less efficient in UNIXes.

Might be because of the internal linker on Windows platforms.

Regards,
Sven

Adding -Xm to the compiler options will create a link map. This contains a long list of what references what and the functions kept or removed by the linker.

Ludo

waldo kitty wrote

are also others that were used between bbs door games/apps and the terminal... globalwar was one of those games and tradewars also had one ;)

Tradewars originally was a Turbo Pascal app (for very old WWIV versions, source is available iirc), afaik later redone in some C++ dialect (watcom?) when they moved to Martech.

OS X has a different binary format and assembler/linker from *BSD and Linux, so OS X in this way is as different from them as Windows is.

Thanks Ludo, I mis-read that to be a mode that Cody could be built to provide additional info.

I was wondering about a conventional (readable) map file... adding -Xm shows that a lot of e.g. comctrls is present in the binary from a null project even after smartlinking, so as somebody else has said this looks like a unix problem.

At least that leaves me in a position of being able to say that it's an ld issue, rather than something implicit in Lazarus.

2012/3/21 Mark Morgan Lloyd :

You must be doing something wrong. On i386-linux/GTK2 with everything smart-linkable and smart-linked and stripped I get 2MB (2113600 bytes) for a minimal application with only one button and one label. (everything compiled with -g- -O3 -CX -XX -Xs)

With upx the 2MB go down to 700kB, without smart-linking I get around 4MB.

Make sure while you are compiling your project in Lazarus you also have -CX in the options of the "build lazarus" Dialog because otherwise when compiling your project it will automatically (re-)compile the LCL without smartlinking. It will always recompile (if necessary) the LCL and all dependent units with the settings that are currently active for "build lazarus" whenever you compile a project.

(I discovered this by accident but it is quite useful: I always thought I had to explicitly recompile the entire Lazarus after changing these options but it is enough to just change the options and then only recompile your project)

Bernd

That's wrong: the LCL etc. is being built without smartlinking.

I've never looked at upx, but possibly I ought. Don't think it supports Solaris though, or SPARC.

I've complained about that rebuild in the past... all of a sudden it's starting to look useful.

(I discovered this by accident but it is quite useful: I always thought I had to explicitly recompile the entire Lazarus after changing these options but it is enough to just change the options and then only recompile your project)

OK. So starting off with an FPC 2.6.0 which has been compiled with OPT='-O3 -Os -CX -XX', I do a command-line build of Lazarus trunk as bigide without explicit options. Output shows that compiler command lines appear to be similar to

ppc386 -MObjFPC -Scghi -O1 -g -gl -vewnhi -l -dLCL -dLCLgtk2 -Fu ... -di386 lazcontrols.pas

i.e. there's no explicit reference to smartlinking (should I be adding something here, and if so how?)

I add -CX to the build options inside the IDE, set up a virgin project and build it. Binary size is 2,161,352 bytes.

So what appears to be happening is that on Linux (and possibly other unix) a make bigide results in an LCL etc. that isn't smartlinkable, and the only way to get it is to insert -CX in the IDE's Tools -> Configure "Build Lazarus" setup, despite the fact that the user isn't intentionally rebuilding.

I wonder where that leaves somebody who is trying to build a project with lazbuild, i.e. never using the IDE?

You can add it to fpc.cfg or to ~/.lazarus/miscellaneousoptions.xml

Mattias

I think that I'll at least modify the scripts I use to download/build Lazarus to warn if -CX isn't in fpc.cfg.

Are there any disadvantages to adding -CX to fpc.cfg? If it's in there as the default is there a way of disabling that on the command line?

Yes, slower build. That's why it used to be on for releases but not for svn. Snapshots depended on the packager.

I added -CX to the Configure Build Lazarus dialog for "Optimized IDE" profile on my Mint Linux 64-bit + QT mapping.
It made absolutely no difference for executable size! Why?

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120325/3dea380d/attachment.html>

Juha Manninen wrote

I added -CX to the Configure Build Lazarus dialog for "Optimized IDE" profile on my Mint Linux 64-bit + QT mapping. It made absolutely no difference for executable size! Why?

-CX compiles units with smartlinking

-XX compiles binaries with smartlinking.

When -XX is used, only units compiled with -CX will give size benefits (if relevant)

Ok, I added -XX and rebuilt Lazarus. Still the binary has exactly the same size as before.
The flags:

-O2 -g- -Xs
and
-O2 -g- -Xs -CX -XX

both produce an executable of size 23649 KB on my 64-bit Linux system using QT bindings.
Is it a Linux linker related issue?

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120326/4fbc2ded/attachment.html>

Did this also trigger a recompile of the LCL and all used packages?

Otherwise it might indeed be linker related.

Regards,
Sven

Sven Barth wrote

Did this also trigger a recompile of the LCL and all used packages? Otherwise it might indeed be linker related.

Yes, all units and packages are built automatically when the options are changed in Configure Build Lazarus window.
I also tested with "Clean All".
My compiler version is rather new FPC 2.7.1.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120326/7d9c11fe/attachment.html>

2012/3/26 Juha Manninen :

I have never found the -Xs to work under Linux. 32-bit or 64-bit. I ALWAYS have to manually do a 'strip <executable>' after compiling. I don't know if this is a FPC bug or some linker issue, but I do know the issue has been around for ages.

Graeme Geldenhuys wrote

2012/3/26 Juha Manninen :> and> -O2 -g- -Xs -CX -XX>> both produce an executable of size 23649 KB on my 64-bit Linux system using> QT bindings.> Is it a Linux linker related issue? I have never found the -Xs to work under Linux. 32-bit or 64-bit. IALWAYS have to manually do a 'strip <executable>' after compiling. Idon't know if this is a FPC bug or some linker issue, but I do knowthe issue has been around for ages.

When I was looking at this last week on x86 32-bit, I didn't have to do a manual strip. Or rather, I did it as a test and found no change (i.e. there were zero-point-zero bytes left to remove).

There's always a possibility that this depends on the binutils version, or is a 64-bit issue.

Graeme, do you have some patches for Aggpas 64bit?

Mattias

Yes I do, but the latest code sent myself a reminder to generate some patches for Lazarus on Monday.

Graeme.