On Tuesday 14 February 2006 04:56, Henrique de Paula Faria wrote:
> Vincent, can you give some tip on how to configure the publish project to
> strip and upx the executable ?
>
> Henrique.
>
>
You can strip and upx from the project options as well, (using the postbuild
command and the compiler settings in conjunction).
But it is NOT an answer !
Strip - rips out debugging code - NOT static linking !
UPX compresses the executable - in a NOT AS COMPATIBLE/SAFE AS THEY SAY way.
I know, I used to use UPX, I have seen how badly it goes wrong when it does -
apps that simply won´t run after being compiled...
These are work-arounds to the REAL issue which is that by default lazarus
links statically. Smartlinking takes longer but it is the right way(tm).
You should STILL strip any program you are distributing but THAT is just
standard software distribution policy - debugging symbols are for building,
not for shipping.
In other words, it´s the size of the executable AFTER stripping we should be
concerned about. An outside executable compresor may or may not be usefull
to you but depending on one is a bad thing(tm) and CERTAINLY not as a
work-around for static linking. The fact that lazarus is meant to be
multiplatform and that the number of support platforms are increasing makes
this doubly important.
I know that ppc386 can take a commandline option to tell it whether or not to
smartlink, though I don´t know if this can just disable compiler directives
for smartlinking or if it can replace them.
Correctly used however, that is the answer, publish project should smartlink
the code, if smartlinking is to slow then the normal run-build-run version
should static link your program. The LCL needs to be smart linkable, but I
don´t think it always needs to be smartlinked.
You should be able to static link during development.
Ciao
A.J.
PS. Dynamic linking is not even an option to me - the last thing I want is for
my lazarus programs to start behaving like kylix programs and insist you load
about 12 other library packages which may or may not have been built for your
glibc depending on whether borland was in a good mood that day.
--
"80% Of a hardware engineer's job is application of the uncertainty principle.
80% of a software engineer's job is pretending this isn't so."
A.J. Venter
Chief Software Architect
OpenLab International
http://www.getopenlab.com | +27 82 726 5103 (South Africa)
http://www.silentcoder.co.za| +55 118 162 2079 (Brazil)
_
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
