The binaries are big because they include a lot of debug information necessary for using gdb (GNU Debugger).
The compiler has an option to remove the debug information from the executable (-Xs), but due to a bug in the compiler (version 2.0.2 and earlier), this doesn't work correctly. It has been fixed in version 2.0.4 and later of the compiler.
You can use a program called "strip" to remove the debug symbols from the executable file. It is located under lazarus dir lazarus\pp\bin\i386-win32\.
Just type "strip --strip-all <your executable file with path>" on the command line.
If you want to make your program even smaller, you should try UPX too. UPX is a very good exe compressor. It includes no memory overhead due to in-place decompression. It also has a very fast decompression (~10 MB/sec on an Pentium 133).
To use upx just type "upx <your executable file with path>" on the command line.
after using both strip and upx a simple GUI Lazarus program gets:
A more detailed answer with the drawbacks of using UPX is given on Size Matters.
It's also important to note that the hello world lazarus software already includes a huge amount of features. It includes:
So it's very big, but it already includes almost everything a real world non-trivial app will need.
Lazarus executable size starts big, but grows very slowly, because of the Free Pascal compiler and the way lazarus forms operate. A c project (just an example, but applies to other languages / tools too) starts very small on the hello world, but quickly grows exponentially when you need features to write a non-trivial application.
Quick guide to Lazarus/FPC application size reduction (tested with Lazarus 0.9.26)
Strip Symbols From Executable (-Xs) -> Checked
The most important items seem to be 2. For a simple application the executable size should now be 1-3 MB instead of 15-20 MB. At this point you can also try: Project|Compiler Options|Code|Optimizations|smaller rather than faster -> Checked (Warning: this might decrease performance)
Chart of default sizes for an empty Application with various settings and operating systems
Well I ran tests I did on Lazarus 0.9.29 with FPC 2.4 (FPC 2.2.4 with Windows). Optimized compiler mean using the advices above but without using UPX. Default Lazarus means as installed from package/setup. LCL without debug informations mean after rebuilding Lazarus IDE and LCL without debug informations (-g-).
| Default Lazarus | LCL without debug informations | |||
| Ubuntu 64 bits / Lazarus 64 bits | ||||
| Default application | 13,4 Mb | 7,5 Mb / 8 | ||
| Optimized compiler | 4,4 Mb | 2,70 Mb (0.29svn FPC2.4 2,5) | ||
| Ubuntu 32 bits / Lazarus 32 bits | ||||
| Default application | 19,6 Mb | 5,7 Mb | ||
| Optimized compiler | 2,9 Mb | 1,6 Mb | ||
| Windows XP 32 bits / Lazarus 32 bits | ||||
| Default application | 11,8 Mb | 2,14 Mb | ||
| Optimized compiler | 1,62 Mb | 1,50 Mb | ||
| Windows Seven 64 bits / Lazarus 64 bits | ||||
| Default application | 12,3 Mb | 3,20 Mb | ||
| Optimized compiler | 2,14 Mb | 2,16 Mb | ||
This problem is fixed in FPC 2.2 and Lazarus 0.9.24. Please update your Lazarus. For older versions read text below.
Generally speaking, compilation on Windows takes more time then other platforms because the GNU Linker utilized by Free Pascal is slow on this platform. This problem only affects Windows, and is only bad on relatively old computers (less then 1Ghz) and computers with little RAM (128MB or less).
Also, if you smartlink LCL the linking will be much slower. A study about this is located here: File size and smartlinking
A internal linker was developed, and is ready, but will only be available when Free Pascal 2.2 is released (of course it's also available via subversion). It decreases the linking time dramatically.
Note: In 2.1.1 Windows uses an internal linker for win32/64/ce which speeds the process up a bit. A Lazarus recompile then eats about 280MB.
You only need fpc.cfg. This way the compiler knows where to find the libraries.
Do something like this:
$ cd lazarus
$ make clean all
If you can't use the IDE to build your applications, use lazbuild. This is a command line version of the IDE to build lazarus projects and packages. If you want to build LCL applications without the IDE and without the lazbuild, add the following lines to the end of your fpc.cfg
# searchpath for other toolkits (Linux)
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/{YourToolKit}
# searchpath for other toolkits (Windows)
-Fu/{YourLazarusDirectory}/components/units/{YourToolKit}
Hint: Don't forget to install the development packages for your toolkit otherwise you might a receive something like: Linker message: cannot find -l.
Version 2.2.4 for all operating systems.
It means the compiler can not find the file 'interfaces.ppu' or it means it found one, but it is wrong or outdated.
This unit can be found in {LazarusDir}\lcl\units\{TargetCPU}-{TargetOS}\{LCLWidgetSet}\interfaces.ppu. For example: /home/username/lazarus/lcl/units/i386-linux/gtk/interfaces.ppu.
Make sure, it is only there. If you have multiple versions of interfaces.ppu, then you probably have a wrong configuration (for instance you added a lcl directory to a search path). Remove all interfaces.ppu, but the one in the directory above.
If you selected a different widgetset than you used to build lazarus, you need to build the LCL for this widgetset.
If it is there, but you get this error, you are using a different compiler / rtl for compiling your project than you used for compiling your Lazarus IDE. You can do one of the following
Lazarus (or better Linux) doesn't know about resources, so you can't use them in the way Delphi/Win32 does. However Lazarus uses a method pretty compatible with this. You can still use your Delphi layouts (.dfm files) if you use the following steps:
initialization
{$I yourform.lrs}
Please keep in mind that not all properties in the dfm are supported yet by lazarus, so you might get a crash.
Edit: Since FPC 2.4.0, Delphi style resources are supported, so you don't need to change anything. Even Lazarus svn already uses it as default projects. Note: it's still advised that you use Lazarus' Delphi project converter as there might still be unsupported properties.
When creating a form Lazarus automaticaly add some extra units to the uses section of your form unit. During the conversion of a delphi unit to a Lazarus unit this does not happen. So you need to add LResources to the Uses section of your form unit.
Make sure, in the Project -> Project Inspector, that your project depends on the package 'LCL' and that you have installed the FPC sources.
Lazarus is the IDE and the visual components library LCL. All other stuff, like IO, Database, FCL and RTL are provided by FPC. The IDE needs the paths to all sources.
The FPC source path can be set via: Environment -> Environment Options -> Files -> FPC source directory
For example:
/your/lazarus/path/tools/lazres sound.lrs sound1.wav sound2.wav ...
will create sound.lrs from sound1.wav and sound2.wav.
Then include it *behind* the form lrs file:
...
initialization
{$i unit1.lrs} // this is main resource file (first)
{$i sound.lrs} // user defined resource file
end.
In your program you can then use:
Sound1AsString:=LazarusResources.Find('sound1').Value;
The Lazarus Tutorial#The Lazarus files explains some extensions by an example. Here is a brief list:
*.lpi *.lpr *.lfm *.pas file) *.pas or *.pp *.lfm file) *.lrs *.ppu *.lpk
The TControl class has a Text property. In a method of a form, that has higher visibility, the Text type from the system unit. You can use the TextFile type, which is just an alias for the Text type or you can add the unit to the type definition.
var
MyTextFile: TextFile;
MyText: System.Text;
A similar name clash exists with assigning and closing a text file. TForm has a assign and a Close method. You can use AssignFile and CloseFile or add the unit name System.
The unit Printers must be added to the uses section.
The Printer4Lazarus package must be added to your project requirement in the IDE under: Project|Project Inspector|Add|New Requirement|Package Name:
If the package Printer4Lazarus package is not in the list when opening the dropdown box it must be installed. The package is part of the Lazarus installation and can be found in: [lazarus installed directory]\components\printers
If you used the default installation directories [lazarus installed directory] is:
The same solution also applies to the exception you can get when referencing Printer.Printers
The TForm.Width/Height do no include the frame, because there was no way to retrieve the frame size on all platforms. Without a reliable way, the LCL would move the forms around on the screen or resize them endlessly.
Eventually when there is a reliable way to get the size and position of a window with its frame on all platforms, then it will be changed. To keep compatibility with older LCL forms, a version number and some extra methods will be added.
The LCL has in the LCLProc unit two procedures to write debug output. They are named:
In normal circumstances the output is written to stdout. If stdout is closed, (for example when the application is {$AppType Gui} or compiled with -WG on Windows), no output is written.
Debug output can also be written to file. The initialization code of the LCLProc unit checks Lazarus.exe's command line parameters for '--debug-log=<file>'. On finding this parameter any subsequent debug output is sent to <file>.
If no '--debug-log' command line parameter has been given, it next checks if an operating system environment variable xxx_debuglog exists, where xxx is the program file name without extension. For Lazarus this would be lazarus_debuglog. If such an environment variable exists, it uses the file specified in the lazarus_debuglog environment variable as file to receive debug output. Example: if you do:
set lazarus_debuglog=c:\lazarus\debug.txt
debug output will be written to c:\lazarus\debug.txt.
Since this is implemented in lclproc, every application using lclproc, can use this output facility.
You have to use the latest FPC from trunk (2.5.1) or 2.4 once it is released.
If you compile your application using -gw (dwarf debug info), you should be able to inspect properties.
Note this is only true for properties that map directly to a variable (the "read" declaration points to a member, not a function).
If your property returns the value of a function it is very dangerous to evaluate/inspect it. It would require this function to be called, and very often it would change the values of some of your variables. This would mean it would alter the state of your application in the debugger, and any further code-execution, debugging or inspections would return incorrect results.
The optional ability to explicitly inspect the results of functions (with the risks described) , and therefore calling code from the debugger is not yet implemented
For problems debugging: - properties
- Array of ... (Dynamic Array)
- Variables in Nested Procedures
- "no such symbol in context"
- "incomplete type"
Please see GDB Debugger Tips
FCL components and classes are built without debug information by default and as a result, gdb cannot access component methods or properties. To build package components they must be rebuilt with a debug-line information "-gl" switch.
This example assumes you have a Linux distribution with /usr/local/ installation prefix and that the Database package fcl-db is what is needed to contain debug-line information. While the fcl-db is used in this example, you may issue this make command from ANY of the included packages.
Before you begin, you need to locate your FPC path by examining your FPC configuration file. The file (fpc.cfg) is located at /etc/fpc.cfg. Display the contents of fpc.cfg and find your fpc installation path. Look for a line starting with -Fu in the fpc.cfg:
-Fu/usr/local/lib/fpc/$fpcversion/units/$fpctarget/*
Make scripts are installing units into INSTALL_PATH/lib/fpc/$fpcversion/units/$fpctarget/, so you must be sure that /usr/local is the installation path, and should be assigned to INSTALL_PREFIX, otherwise the Make scripts will place units where they don't belong or the Make script will fail.
Step 1: Open a shell terminal
Step 2: cd /user/local/share/src/fpc-2.3.1/fpc/fcl-db/
Step 3: sudo make clean all install INSTALL_PREFIX=/usr/local OPT=-gl
Note: INSTALL_PREFIX parameter should be properly configured for units to be installed. In the sample below /usr/local is a default fpc path for Linux, but may vary on other OSes.
make clean all install INSTALL_PREFIX=/usr/local OPT=-gl
Finally, after rebuilding any FCL units you may want to rebuild LCL as well.
Such patches will not be applied, because they only implement a small part of the needed docking. The goal is to create a complete dock manager and use that. A complete dock manager can dock all IDE windows and it allows to let the user define how to dock. For example dock the messages window above or below the source editor or ... or not at all. For instance:
------------------- --
|menu || |
------------------- | |
-- --------------- | |
|PI|| Source Editor ||CE|
-- | || |
-- | || |
| | --------------- --
|OI| -------------------
| ||messages |
-- -------------------
The dock manager can store the layout and restore it on next load. Preferably the dock manager can dock in pages too. The dock manager does not need to use drag and drop. All patches implementing docking without a dock manager makes it harder to implement a real dock manager and will be rejected.
As a temporary solution you can use this IDE extension: Manual Docker
Create a patch and send it to the developers. For details see Creating A Patch.
First of all: you must learn about Lazarus, to prove your knowledge and skill. Start by reading the wiki articles, read the Lazarus source code, giving a look at the Lazarus Bug-Tracker, fix some bugs, and if you think you are ready, contact the developers on the mailing list.
Virtual key constants are defined in LCLType. Add LCLtype to your uses.
You can invoke identifier completion by pressing [ctrl][space]. Under the menu item Environment -> Editor Options -> Code Tools -> Automatic Features you can set how quick this should happen automatically.
First of all you need a debugger. gdb is the standard debugger under linux and there are several GUI-frontends available. One common frontend is ddd, which is part of most common distributions. To compile lazarus/lcl with debug-information you should then use the following commands to start a debug session:
$ make clean; make OPT=-dDEBUG
$ ddd lazarus
Be warned however, that ddd is not as comfortable as e.g. the Lazarus debugger. Specially if it comes to view the contents of a variable you have to take into account that ddd/gdb are case sensitive whereas Pascal is case-insensitive. Therefore you have to type all variable names in uppercase to see their contents. For more information take a look into the fpc-manuals.
This is a path-related problem with either gdb or ddd. You can avoid this by
directory /your/path/to/lazarus
directory /your/path/to/lazarus/lcl
directory /your/path/to/lazarus/lcl/include
[]$ urpmf lib<somelib>.so
[]$ apt-file search lib<somelib>.so
[]# cd /usr/local/lib && ln -s libglib-12.so libglib12.so
[]# cd /usr/X11R6/lib && ln -s libgtk-12.so libgtk12.so
[]# cd /usr/X11R6/lib && ln -s libgdk-12.so libgdk12.so
Nearly the same way as converting a Kylix project into a Delphi/VCL project.
The LCL (Lazarus Component Library) tries to be compatible to Delphi's VCL. Kylix's CLX tries to be QT compatible. Here are some general hints:
initialization
{$I unit1.lrs}
1. Check a clean rebuild: do a 'make clean all'
2. Check if the compiler has the correct version (2.0.4 or higher)
3. Check if the compiler is using the right config file. The normal installation creates /etc/fpc.cfg. But fpc also searches for ~/.ppc386.cfg, ~/.fpc.cfg, /etc/ppc386.cfg and it uses only the first it finds.
4. Check if the config file (/etc/fpc.cfg) contains the right paths to your fpc libs. There must be three lines like this:
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/rtl
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/*
5. Check that the config file (/etc/fpc.cfg) does not contain search paths to the lcl source files (.pp, .pas):
forbidden: -Fu(lazarus_source_directory)/lcl
forbidden: -Fu(lazarus_source_directory)/lcl/interfaces/gtk
-Fu(lazarus_source_directory)/lcl/units/$fpctarget
-Fu(lazarus_source_directory)/lcl/units/$fpctarget/gtk
6. Check if the missing unit (glib.ppu) exists in your fpc lib directory. For example the gtk.ppu can be found in /usr/lib/fpc/$fpcversion/units/i386-linux/gtk/. If it does not exists, the fpc lib is corrupt and should be reinstalled.
7. Check if the sources are in a NFS mounted directory. In some cases the NFS updates created files incorrectly. Please, try to move the sources into a non NFS directory and compile there.
8. If you are still not succeeded try to use samplecfg script as follows:
# cd /usr/lib/fpc/version/
# sudo ./samplecfg /usr/lib/fpc/\$version /etc
Note! Do not put - / - after etc because if you do that the system will create a file - /etc/fpc.cfg/fpc.cfg. In fact we want that samplecfg make a file - /etc/fpc.cfg - not the folder /etc/fpc.cfg.
Probably you are using a newer fpc package, than that used for building the lazarus binaries. The best solution is to download the sources and compile lazarus manually. You can download the source snapshot or get the source via svn:
$ bash
$ svn checkout http://svn.freepascal.org/svn/lazarus/trunk lazarus
$ cd lazarus
$ make clean all
Make sure that lazarus get the new source directory: Environment->General Options->Files->Lazarus Directory Top
Install the gdk-pixbuf library for gtk1.x:
Where to find the gdk-pixbuf library:
RPMs: http://rpmfind.net/linux/rpm2html/search.php?query=gdk-pixbuf&submit=Search ...&system=&arch=
Debian packages: libgdk-pixbuf-dev
Sources: ftp://ftp.gnome.org/pub/gnome/unstable/sources/gdk-pixbuf/
External Links: termpapers
Ubuntu 8.10:
If you are compiling Lazarus with GTK 2.0 you'll get a "libgdk-pixbuf2.0" not found error. Just install libgtk2.0-dev using apt on this way:
apt-get install libgtk2.0-dev
Older SuSE versions (before SuSE 11) install the gtk devel libs under /opt/gnome/lib (or /opt/gnome/lib64 for 64 bits), which is not in the standard lib path. Simply add it to your /etc/fpc.cfg (-Fl/opt/gnome/lib).
After I installed a component, Lazarus crashes with the following message:
Threading has been used before cthreads was initialized.
Make cthreads one of the first units in your uses clause.
Runtime error 211 at $0066E188
How can I fix this?
Your freshly installed component is using threads. FPC on *nix doesn't automatically include threading support, but it must be intialized. This initialization is done in the cthreads unit. Every application using the component needs to add this unit to the uses clause of the main program. Lazarus itself is no exception. This can be done in two ways:
1) Open the package. In the package editor click on Options. Under page Usage add to the custom options -dUseCThreads. Then rebuild the IDE. This way the cthreads unit will be automatically used by the IDE under unix and the cthreads are initialized.
2) In order to avoid modifying package, a fpc compiler option could be used directly. Open menu Tools->Configure "build Lazarus". Configure "build Lazarus" dialog will be shown, in field "Options:" type -Facthreads and then press "OK" button. The next step is to install the package. Lazarus will be built with option -Facthreads which means that it will treat main program as if unit cthreads where first in uses clause.
Hint: Maybe your old (non-crashing) lazarus executable is stored as lazarus.old in the same directory as the crashing lazarus executable.
See also Multithreaded_Application_Tutorial#Units_needed_for_a_multithreaded_application
The complete error message is:
This binary has no thread support compiled in.
Recompile the application with a thread-driver in the program uses
clause before other units using thread.
Runtime error 232
Solution: Add cthreads as first unit to the uses clause of your main program, usually the .lpr-file.
If Lazarus is compiled with Gtk1.2, the settings in Gnome Preferences/Font don't have any effect as they are related to Gtk2. You could try this solution: Create a file named .gtkrc.mine in your home directory (if it's not already there) and add these lines to it:
style "default-text" {
fontset = "-*-arial-medium-r-normal--*-100-*-*-*-*-iso8859-1,\
-*-helvetica-medium-r-normal--*-100-*-*-*-*-*-*"
}
class "GtkWidget" style "default-text"
If this is not enough try and create also a .gtkrc symlink to .gtkrc.mine . It worked in this way under Xubuntu 7.10, Mandriva 2009.0 KDE3.
Option a) Name the rc file yourprogram.gtkrc and put it in the same directory where the executable is.
Option b) Use unit GtkInt and call GTKWidgetSet.SetRCFilename('your_preferred_rc_file'); Best done before Application.Initialize in the .lpr file with {$IFDEF LCLGtk}.
Option c) Use unit gtk2 and call gtk_rc_parse('your_rc_file')); and gtk_rc_reparse_all;.
Ubuntu has a problem with not creating all the symbolic links that you'll need even when the libraries are installed. Make sure that all missing libraries when trying to link for Gtk2 have their appropriate links. For instance, you might need to do:
cd /usr/lib
sudo ln -s libgdk-x11-2.0.so.0 libgtk-x11-2.0.so
Make sure that the [whatever].so symbolic links are created and point to the actual libraries.
At the moment, the Gtk2 compiled IDE is a little unstable, but you can compile software for Gtk2 using the Gtk1 IDE.
To start with recompile LCL for Gtk2. Go to the menu "Tools"->"Configure Build Lazarus" and set LCL to clean build and everything else to none.
Now click Ok and go to the menu "Tools"->"Build Lazarus"
Now you can compile your software with Gtk2 going on the Compiler options and changing the widgetset to Gtk2.
Since revision 10535 (0.9.21) this message doesn't exist anymore. Previously it was used to warn that a UTF-8 encoding was used. The internal keyhandling routines for the gtk1 widgetset couldn't handle such encoding for keypresses, with the result that keypresses with for instance accented chars were not or wrong detected.
(original text for older versions of lazarus)
This warning message indicates that your locale enconding is set to utf-8. If you are using Gtk 1 this can be a serious problem and prevent the correct working of Lazarus or software created with Lazarus.
To work around this, just change your locale to a non utf-8 before executing the program on the command line, like this:
export LC_CTYPE="pt_BR"
export LANG="pt_BR"
export LANGUAGE="pt_BR"
./lazarus
Substitute pt_BR with the locale for your country. You can create a script to automate this.
In the compiler directory there is an OS2 scriptfile named make.cmd. Different versions of Windows also see this as a script file, so remove it since what is needed for OS2 becomes a hindrance on Windows.
I don't know why but somehow make has lost its path. Try to cycle with a basedir set like: make cycle BASEDIR=your_fpc_source_dir_herecompiler
You need to upgrade your make.
Make sure you didn't install FPC in a path with spaces in the name. The Makefile doesn't support it.
Project -> Project Options -> Check 'Use manifest to enables themes'.
Specify the -WG argument (Windows GUI) on the command line of the compiler or in the Lazarus IDE check the Windows GUI check box on the compiler options dialog box (Project menu -> Compiler Options -> Linking -> target OS Specific options.
Dead code stripping is not supported by the assembler and linker before Xcode 1.5 (available for Mac OS X 10.3.9). Disable the compiler options
Yes, the LCL is licensed under the LGPL with an exception, which allows you to link to it statically without releasing the source of your application. Modifications and enhancements to the LCL must be distributed with source. Lazarus, the IDE, is licensed under the GPL. The LCL consists only of the code in the directory named "lcl", other code may not be covered by this statement.
Lazarus comes with additional components, that were developed by third parties. Those are under various other Licenses. If you wish to use them you need to see the License within the source files of those packages. Most of those 3rd party components are in the directory "components".
All LCL units are in the directory "lcl". A List of units belonging to the LCL can be found here http://lazarus-ccr.sourceforge.net/docs/lcl/ . If you code uses units not listed on this page, you may have used a component that is not part of the LCL.
Yes, the IDEIntf part of the IDE is licensed under the LGPL with the same exception, so that shared data structures in this part will not force you to license your plug-in or design-time package under the GPL. You are free to choose a plug-in of any license; we don't want to limit your choice. Therefore non-GPL compatible plug-ins are allowed. Note that it's not allowed to distribute a precompiled Lazarus with these non-GPL-compatible plugins included statically; however, we do not see this as a severe limitation, since recompiling Lazarus is easy.
Java-bytecode target added to the Free Pascal compiler.
August 20, 2011
A new target has been added to Free Pascal compiler. It is now possible to compile applications to Java bytecode. This means that these Free Pascal applications can run in a Java Virtual Machine (JVM), so that it can run on any platform that has Java support.
Dutch Pascal conference 2011.
June 12, 2011
After the success from last year, the Dutch Pascal Users Group organizes the second Dutch Pascal Conference on June 18th. Last year it was mainly focused on Lazarus, this year there will also be some topics about Delphi.
-- Alexander Grau, Germany