Re: [lazarus] I still have an ifdef request
Yesterday I posted a request for a way to improve ifdef handling, but the discussion was led astray by my example, and turned into widgesets, which was not the real issue. So I repeat my request: Sometimes ifdefs are unavoidable, as when they're used to turn on and off customer options. But IDE and fpc are unaware of conditional dependencies, so changing a conditional doesn't force a recompile of some units as it would be required. Of course a Build All is the solution, but if one forgets, one may end up with a program which compiles properly, but has a number of inconsistencies sometimes hard to detect. Is there a way to overcome this problem? Am I the only one to see it as a problem? I would gladly contribute an upgrade to implement this feature, but advice from experts on where to start from, what to look at, if hooks are already available in .lpi or in .ppu or .o files, etc. would be highly appreciated. It has been tried in the past. And it created very confusion situations so it was disabled. There are no plans to re-add this feature because it will cause more questions and problem reports than it solves. And also how often is a define changed. In those couple of cases you can simply press the Build All or use the command line option -B. Peter _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Solution to the BIG compiled file issue!
At 18:37 16-1-2008, you wrote: Hi, 2008/1/16, Christian U. [EMAIL PROTECTED]: OK guys now I OFFICIALLY close this very long, long thread! :) Are you trying to create an patch ? If not please inform me than i will do. I have just found a method to move ALL the debug data and symbols to an external .dbg file, obtaining a just stripped compiled file and the full debug functionalities (only with the .dbg file presents). Currently I must execute 3 steps to obtain this (after every compilation). I'm working to can do all with a single step (just on beta testing)! :) I can see only 2 steps: $ objcopy -R .text -R .data lazarus.exe lazarus1.dbg $ strip lazarus.exe Resulting files: -rwxr-xr-x 1 peter None 41551141 Jan 16 18:50 lazarus.dbg -rwxrwxrwx 1 peter None 7610368 Jan 16 18:51 lazarus.exe And for debugging: $ gdb lazarus.exe (gdb) br main No symbol table is loaded. Use the file command. (gdb) symbol-file lazarus1.dbg Reading symbols from /cygdrive/d/lazarus/lazarus.dbg...done. (gdb) br main Breakpoint 1 at 0x401bf9: file lazarus.pp, line 77. (gdb) Peter _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Rebuilding RTL and FCL inside LazIDE
At 18:53 16-1-2008, you wrote: Al Boldi wrote: Christian U. wrote: RTL and FCL are never build while building lazarus its a bit hard to add an option for this i think. Assume I have both debug and release versions build myself. Mattias, what is needed to add rebuilding RTL/FCL from within the IDE? This is goining into the wron direction. I don't think this is a good idea to add to an IDE. Because recompiling the RTL means that you need to recompile all installed units. For fpc we are working on a package system that can help in this dependency issue. This can maybe included as an tool, but the functionalitiy should not be included in the IDE. Peter _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Solution to the BIG compiled file issue!
$ gdb lazarus.exe (gdb) br main No symbol table is loaded. Use the file command. (gdb) symbol-file lazarus1.dbg Reading symbols from /cygdrive/d/lazarus/lazarus.dbg...done. (gdb) br main Breakpoint 1 at 0x401bf9: file lazarus.pp, line 77. (gdb) I need 3 steps because I don not change the mode lazarus call the GDB. After my changes just a lazarus run to can use a stripped (as --strip-all) compiled file with all the debug data in an external file (and is possible debug also the LCL). Peter Wait a moment ! If this is possible with command line gdb, then it must be possible also from Lazarus IDE,right ? Or from executable itself to create stacktrace ? Could I just strip executable and provide external file .dbg and still get full stacktrace in case of exception ? Thread continued on fpc-devel. Peter _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Solution to the BIG compiled file issue!
1)...the additional options are needed to can debug the project; 2)...just do a simple strip --strip-all filename reduce drastically the final size (an empty project go from 12.5Mb to 1.2 Mb). I think to have found a really simple solution to can continue to debug our project with a really little size increasing. Just remove all the debug-info from all the LCL object files to reduce the final compiled file from 12.5Mb to ONLY 2Mb (on Windows). If the debugger gdb can support the dwarf debug info the size of the binary will be already a lot smaller. So it isn't a problem of FPC but of the debuggers what debuginfo is supported. See below what the difference on the lazarus binary: ~/lazarus ls -l lazarus-* -rwxr-xr-x 1 pvreman kmem 25630931 Jan 15 13:00 lazarus-dwarf -rwxr-xr-x 1 pvreman kmem 74177091 Jan 15 13:02 lazarus-stabs -rwxr-xr-x 1 pvreman kmem 9423528 Jan 15 13:00 lazarus-stripped _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Solution to the BIG compiled file issue!
If the debugger gdb can support the dwarf debug info the size of the binary will be already a lot smaller. So it isn't a problem of FPC but of the debuggers what debuginfo is supported. See below what the difference on the lazarus binary: ~/lazarus ls -l lazarus-* -rwxr-xr-x 1 pvreman kmem 25630931 Jan 15 13:00 lazarus-dwarf -rwxr-xr-x 1 pvreman kmem 74177091 Jan 15 13:02 lazarus-stabs -rwxr-xr-x 1 pvreman kmem 9423528 Jan 15 13:00 lazarus-stripped So why do not use the dwarf debug format (excuse my ignorance) ? First: Please reply at the bottom of the messages. The answer to your question was already in my reply quoted above. The debugger gdb support for dwarf was not good enough and not supported on all platforms (especially windows). It is improving, but it needs to be tested well before we can make dwarf debuginfo for some platforms the default in fpc. Peter _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Benchmarks
At 17:01 1-1-2008, you wrote: Vincent Snijders wrote: willem schreef: Benchmark results from : http://shootout.alioth.debian.org/gp4/benchmark.php?test=sumcollang=all#about Conclusion : It would be good to have a compiler switch that optimizes for speed. That is a wrong conclusion. All these programs were compiled for speed and not for low memory use. Vincent No I mean a new G1 switch who optimizes 30% better at the expensive of memory usage. The memory usage may be ten times greater than the G switch. I think your view is a bit too simplistic. Optimizing code is a complex task and we are continuusly working on it. Ofcourse patches to improve the optimizer of the compiler are always welcome. Simply refering to a couple of, already known, benchmarks will not help to get things improved. Besides that Free Pascal does a fairly good job against the other commericially funded compilers. Peter Peter _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Unit output directory (-FU) is wrong in Compiler Options
On 21/06/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: If I leave the target filename blank (which I must), this gets handled correctly for me. Otherwise I need to manually rename the files for different platforms. This is not a valid reason, because if set the Target file name in the project options to 'test', it will create a test.exe on windows. Strangely I never knew that! Thanks. :) Ok, so that solves half of the issue... I still think it is weird and confusing that 'Unit output directory (-FU)' = units gives a different result compared to the exact same compiler switch -FUunits in the 'Other' tab. Maybe the (-FU) hint in the label should be removed from the Paths tab so that it doesn't mislead you into thinking that it works the same as the -FU switch. To me 'Unit' mean the *.pas file and not the project executabe. I guess I'm the only one that thinks like that. FPC's command line help clearly says: -FEx set exe/unit output path to x There is a difference between exe and unit. The -FE is exe and units. If in addition to -FE also a -FU is supplied you can control the location of the units to be in a different path than the exe. To control only the location of the executable and leave the units location unchanged you can use the -o option and specify the full path and name of the exe. Peter _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] FindFirst/FindNext or FPReadDir
*Dear Colleagues,* Can you help me to solve a problem? I want to scan entire file system, for example - / and put the results into TTreeView. So, what will be faster - to use FindFirst/FindNext circle or to use FPReadDir function? I am completing now the 3rd page of my SysInfo for Linux program that will show File System, size and usage information for all locally mounted FS. If need performance and only need to have the filename you can use fpgetdents or the deprecated fpreaddir. If you need all file information like size and modified timestamp then better use the portable findfirst/findnext. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] FindFirst/FindNext or FPReadDir
At 21:30 21-6-2007, you wrote:
Am Donnerstag, den 21.06.2007, 20:49 +0200 schrieb Marco van de Voort:
On Thu, Jun 21, 2007 at 09:48:56PM +0400, Alex Smirnov wrote:
Peter Vreman ?:
If need performance and only need to have the filename you can use
fpgetdents or the deprecated
fpreaddir. If you need all file information like size and modified
timestamp then better use the
portable findfirst/findnext.
*Thank you, Peter!
* Can you. please, help me to understand Dir structure, i.e
The FreeBSD source has some comments
dir = packed record
dd_fd : cint; // file descriptor associated
with directory
dd_loc: clong;// offset in current buffer
dd_size : clong;// amount of data returned by
getdirentries
dd_buf: pchar;// data buffer
dd_len: cint; // size of data buffer
{$ifdef netbsdpowerpc}
dd_pad1 : cint;
dd_seek : cint64;// magic cookie returned by
getdirentries
{$else}
dd_seek : clong;// magic cookie returned by getdirentries
{$endif}
dd_rewind : clong;// magic cookie for rewinding
dd_flags : cint; // flags for readdir
end;
TDir= dir;
pDir= ^dir;
However I would vote against using it. Sure it saves a stat here and there,
but it is way less portable (even amongst *nixes in time) than findfirst.
While we're at it: what does the following comment want to say? I've
been fiddling with that stuff, but that was quite a while ago and I've
forgotten the details.
from fpc-2.0.4/src/rtl/unix/sysutils.pp:
Function FindFirst (Const Path : String; Attr : Longint; out Rslt :
TSearchRec) : Longint;
Var
GlobSearchRec : PGlobSearchRec;
begin
New(GlobSearchRec);
GlobSearchRec^.Path:=ExpandFileName(ExtractFilePath(Path));
GlobSearchRec^.GlobHandle:=Glob(Path);
Rslt.ExcludeAttr:=Not Attr and (faHidden or faSysFile or
faVolumeID or faDirectory); //!! Not correct !!
Rslt.FindHandle:=GlobSearchRec;
Result:=DoFind (Rslt);
end;
If it's wrong, why is it in the code?
And, more important, what would be correct?
The code in the 2.1.4 is already completly rewritten. It is not in
the same style as the findfirst in the Dos unit for unix that is also
in 2.0.4. Please look at that code and forget the code above.
Peter
Peter
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] strip utility
Hi, btw. there is a newer UPX version available (see http://upx.sourceforge.net/). Is there any reason, that not the latest version is included? It is not verified if that works stable enough. Also UPX is mainly used for win32 and there are not that much improvements for it so there is no real need to upgrade. Peter _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Patch: debugger breakpoints
At 18:03 18-2-2007, you wrote: From: Marc Weustink [EMAIL PROTECTED] Yury Sidorov wrote: Hi, Here is a patch: * Set debugger breakpoint on main/entry point using decimal number. It fixes executing application without debug info under gdb. I encountered problems at least with gdb 6.0 for win32 bundled with Lazarus. It dont accept pascal hexadecimal string $ as address for breakpoint even if language is set to Pascal. It seems like bug in gdb, but this patch workarounds this bug. It's indeed a bug in gdb. But I don't understand really what is going on here. The reason I used the unparsed value is that I got 0x... values reported and not $ So I assumed that when GDB reports the address as 0x... it will understand it as address and when it reports $... it will understand that. I dont understand it also. gdb reports addresses as $..., but accept address in breakpoint only as 0x... or decimal value. Anyway this patch avoids this problem. This is a known issue with pascal support gdb that can't be solved. It was already discussed a couple of years ago when Pierre Muller extended my initial pascal patch for gdb. The $... is used to display registers. E.g. 'print $eax'. Peter _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] those fixed calling conversions in wince...
At 21:44 4-1-2007, you wrote: roozbeh gholizadeh schreef: I saw yury has changed lots of stdcalls to cdecl in wince header files. And also vinced changed two callbacks to cdecl. So,was the previous ones wrong?and if so how did they worked before. i mean if calling conversions wrong why didnt programs earlier crash so soon? And so from now on what should CALLBACK and WINAPI be translated to? I have heard, that for arm cdecl and stdcall are the same. But not for i386. Yuri made those fixes to support i386-wince. For all non-i386 we follow the standard conventions and that means that cdecl=stdcall=register Peter _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] FPC 2.1.1 and latest svn Lazarus doesn't play together
Hi, I compiled FPC 2.1.1 (latest svn) just fine. I then got latest Lazarus (svn) and did a clean all and make all and get the following output. Is this normal? Also after Lazarus is build, I run the new executable and Lazarus fails to load with a error: Error reading SplashScreen.Left: Unknown property: Left. and then Lazarus dies completely. This is a known issue _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus 0.9.18 and compilation speed (what does it look for?)
On Sun, 01 Oct 2006 16:31:30 +0400 Alex Smirnov [EMAIL PROTECTED] wrote: Felipe Monteiro de Carvalho ?: How do you know it spends more then 99% of compilation time in this search} Also consider that showing output on the screen costs time, and without showing messages the search will be shorter. The answer is very simple. My project compilation log file consists of 31491 lines of text. And the number of the lines with not found string is 23286. The number of lines with found string is 383. I think, this discussion is missing some numbers. Here are some: On a normal linux system the compiler searches 55 directories. Compiling one simple LCL application with -vewnhi: Time: 1.225s Not found: 29071 With 55 additional paths in the fpc unit directory: Time: 1.493s Not found: 55699 With 1000 additional paths in the fpc unit directory: Time: 5.843s Not found: 520639 This gives about 4.8ms per additional unit path. So, the search overhead for the 55 standard paths costs about 0.27s or about 22%. I will add some directory caching in the compiler. That should at least reduce the number of system calls. I created a mantis issue 7515 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus 0.9.18 and compilation speed (what does it look for?)
*IDE version:* Lazarus 0.9.18 (fresh installation) *OS:* Windows XP and Linux(Mandriva 2006) - same problem. *Problem description:* While Lazarus tries to compile something, it starts to search for several files - PPUs, Libraries, source files, etc.But IMHO, it searches things in a wrong (not optimal) way. And as a result it spends more then 99% of compilation time in this searching process. Here is the example: /(SYSTEM) Loading unit SYSTEM Unitsearch: System.ppu ... Unitsearch: System.pp Searching file System.pp... not found ... Unitsearch: System.pas Searching file System.pas... not found ... Unitsearch: System.ppu Searching file System.ppu... not found ... ... Unitsearch: C:\lazarus\fpc\2.0.4\units\i386-win32\rtl\System.ppu Searching file C:\lazarus\fpc\2.0.4\units\i386-win32\rtl\System.ppu... found/ SYSTEM.PPU is a basic unit. But Lazarus first tries to find file System.pp in the project root directory! And it takes Lazarus 23 attempts (!!!) ONLY to find System.ppu. More over, every time I will build the same project - Lazarus will spend 23 attempts to find System.ppu. First of all I think, it should be a list of system modules(libraries) to find them every time in the same place. If this is a compiler issue - we should put system units search path at the top of unit search list. Next, I think it is a good idea to store some search results in project file (like Project.lpi) to speedup the compilation process. I mean that all *.PPU/*.PAS/*.PP/*.A etc files that are parts of a project should be stored in Project.lpi with full path. So compiler will try to search them ONLY when they will be not found with this stored paths. This is searching is in the compiler and it is there by design and will not be changed. It allows you to override units in your local tree. Also note that for the compiler there is no difference if a unit is part of the RTL of LCL or your own project. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus 0.9.18 and compilation speed (what does it look for?)
Peter Vreman ?: This is searching is in the compiler and it is there by design and will not be changed. It allows you to override units in your local tree. Also note that for the compiler there is no difference if a unit is part of the RTL of LCL or your own project. Sorry for that, but, I think you are not right. So, when I try to make some compilation using make file - it will be more faster :-) - it will NOT search system.ppu for 23 times. I can create make file for my project and calculate the time needed to make all of it - both with Lazarus IDE and with simple make all There is a big difference with what the compiler needs to do and what you want. See the 'my project' in your paragraph. This is not the case for the compiler. The compiler needs to working in general for everybody. It can be that this is maybe not the optimimal issue for your specific situation. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus 0.9.18 and compilation speed (what does it look for?)
Also - what is the problem to search for *.pas and next to *.PAS file? Is it possible to make case insensitive search? It was really a surprise for me to see DIFFERENT search requests for *.pas and *.PAS files! This is already fixed in the 2.1.1 compiler. For case aware filesystems (=Windows) only one search for *.pas will be done. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus 0.9.18 and compilation speed (what does it look for?)
Thus I think that all this 111 seconds is almost wasting time that was spent in FindFirst/FindNext circle. I think that is wrong. But you can test that by copying all the needed .ppu and .o files into one directory and replace the -Fu lines for fpc.cfg with -Fudirectory_with_all_needed_units. I think most time is spent creating the executable from the 383 units it needs, getting code, data and debug sections from the 383 units and putting it in the final executable. Vincent *Yes, You are right.* When I set Compiler Options - Messages to Show summary only it takes 15 seconds to make all project and also to link it. Ok. But 15 seconds is also very large time. Sorry for that - I mean Delphi. It is faster in all cases. So I think it is a good idea to speedup compilation process. May be for Windows only - if you will set the file search process to be case insensitive it will decrease the quantity of requests in 4 times! Maybe, but the linking process still takes the biggest time. The external linker (ld) simply _is_ slow, and there is nothing we can do about it. Maybe you should try the lazarus development snapshot that is compiled with the 2.1.1 compiler. This has the case-insensitive search and an internal linker for win32. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: 2.0.4-rc3 available
At 09:43 16-8-2006, you wrote: Hi, The access permissions is wrong: 700, the file is accessible for the owner only. Gabor Michael Van Canneyt írta: Try ftp://ftpmaster.freepascal.org/pub/fpc/beta/2.0.4-rc3/i386-win32/fpc-2.0.4.i386-win32.exe That should work. Fixed Peter _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Why not remove revision.inc from svn repository?
ok, I think I understand now.
But is it necessary to increase the revision when Lazarus is built?
How does that bring a correct revision? You build Lazarus after each
patch?
Maybe we could have a script to update revision.inc
Have a look at the Makefile.fpc of the compiler. It creates a revision.inc
on the fly and adds a define that is used in the sources. See below for
the fragments:
REVINC:=$(wildcard revision.inc)
ifneq ($(REVINC),)
override LOCALOPT+=-dREVINC
ifeq ($(REVSTR),)
SVNVERSION:=$(wildcard svnversion$(EXEEXT))
REVSTR:=$(shell svnversion .)
export REVSTR
endif
endif
function full_version_string:string;
begin
full_version_string := version_nr+'.'+release_nr+'.'+patch_nr+minorpatch
{$ifdef REVINC}
+'-r'+{$i revision.inc}
{$endif REVINC}
;
end;
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus in Google summer of code 2006 ?
Would you be interested in a whole ressource editor intégrated into the ide or in a separate tool ? (icons/xpms/bmp/windows ressources/etc...) I hope I speak for the whole Lazarus/FPC team when I say that as a separate tool, this would be great to have. The resource workshop from Colin Wilson could be adapted for this (he gave permission to the CrossFPC people), or you could make your own. It would be nice if backend of the resource tool also supports reading/writting different formats like RC, RES, COFF, ELF (fpc-specific) resouces. This way we don't depend anymore on windres from binutils. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] x86_64-win46
Another question: does the current win32 lazarus snapshot already contain the internal linker (compiling time 2.34 sec.)? The internal linker also shows code and data size: 31 lines compiled, 1.1 sec, 222768 bytes code, 47744 bytes data _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] x86_64-win46
Another question: does the current win32 lazarus snapshot already contain the internal linker (compiling time 2.34 sec.)? The internal linker also shows code and data size: 31 lines compiled, 1.1 sec, 222768 bytes code, 47744 bytes data The current compiliation with win32 lazarus snap failed with -Xi option. Including the error message that you might be a good idea. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
RE: [lazarus] Dependencies under Linux
On Mon, 10 Apr 2006, Panagiotis Sidiropoulos wrote: I think you should check what are the dependiences for empty TForm application on your system .Later check by adding one by one each control and test which makes such big dependiences and report as a bug. I did this, adding components one by one. From empty form up to adding all components, I got only following dependencies while compiling for gtk. When compiled for gtk2 I go all that list included in my first post. linux-gate.so.1 = (0xe000) libglib-1.2.so.0 = /usr/lib/libglib-1.2.so.0 (0xb7fb2000) libgdk-1.2.so.0 = /usr/lib/libgdk-1.2.so.0 (0xb7f7a000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0xb7eb3000) libgtk-1.2.so.0 = /usr/lib/libgtk-1.2.so.0 (0xb7d6b000) libXi.so.6 = /usr/X11R6/lib/libXi.so.6 (0xb7d63000) libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0xb7d54000) libm.so.6 = /lib/tls/libm.so.6 (0xb7d2e000) libgdk_pixbuf.so.2 = /usr/lib/libgdk_pixbuf.so.2 (0xb7d1a000) libdl.so.2 = /lib/tls/libdl.so.2 (0xb7d16000) libc.so.6 = /lib/tls/libc.so.6 (0xb7bdf000) libgmodule-1.2.so.0 = /usr/lib/libgmodule-1.2.so.0 (0xb7bdc000) /lib/ld-linux.so.2 (0xb7feb000) This is a normal list which cannot be reduced, AFAIK. That GTK2 uses more libraries is probably a 'feature' of GTK2, which cannot be solved completely by FPC... See the output of 'ldd /usr/lib/libgtk-x11-2.0.so' _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Error compile lazarus version 9051
On 3/30/06, Adriano Frare [EMAIL PROTECTED] wrote:
I have compiled lazarus release 9051 with fpc 2.0.0, but it don't
compile.
You need fpc = 2.0.2 to compile Lazarus now. If you try to compile it
with 2.1.x, then you will need a very recent svn version.
Maybe it is a good idea to add the following code in alllclunits.
{$if defined(ver2_0) and (fpc_patch2)}
{$fatal Lazarus requires at least FPC 2.0.2}
{$endif}
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Patch for new resourcestrings in fpc trunk
Attached is a patch to make lazarus work with fpc trunk r2987 resstr.diff.gz Description: GNU Zip compressed data
[lazarus] Patch for solaris support
This patch adds support for building lazarus for sparc-solaris. solaris.diff.gz Description: GNU Zip compressed data
Re: [lazarus] Patch for new resourcestrings in fpc trunk
At 16:49 20-3-2006, you wrote: Peter Vreman schreef: Attached is a patch to make lazarus work with fpc trunk r2987 To test this patch, I updated to revision 2988. Compilation of a new compiler failed: D:/lazarus/source/fpc/2.1/compiler/ppc1.exe -Ur -Xs -O2 -n -Fui386 -Fusystems -FuD:/lazarus/source/fpc/2.1/rtl/units/i386-win32 -Fii386 -FE. -FUi386/units/i386-win32 -dRELEASE -CX -XX -gl -di386 -dGDB -dBROWSERLOG -Fux86 pp.pas An unhandled exception occurred at $49572F3A : EAccessViolation : Access violation $49572F3A TINDEXARRAY__REPLACE, line 2347 of windows.pp $00414DF6 DONELINKER, line 974 of link.pas $0040922A DONECOMPILER, line 260 of compiler.pas $00408Fatal: Compilation aborted CD2 COMPILE, line 392 of compiler.pas $00404030 main, line 212 of pp.pas make.exe[4]: *** [ppc386.exe] Error 217 Fixed, r2990 Peter _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] call stack and debugging problems
Hi! When I debug a file. That is , the debugger stops and I look at the call stack, I cannot see filename and linenumber In other words, the debugging is made harder. I heard it was related to the freepascal compiler was not able to cooperate with gdb as the generated stack frame format changed... I wonder if one can write a debugger that could get the calls off the stack properly. Does the compiler place sufficient information in the stack to deduce the calls backwards when an exception occurs? Is that format predictable? What is the timeframe in which this problem may be fixed? All required information for Call frame unwinding is available in the executable. Only gdb is not able to handle it. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Compiler Option Dialog
The compileroptionsdlg is still a hardcoded form. This dialog still needs to be converted to LFM, which is planned anywhere soon. Perhaps you could do the conversion of this form? At the same time you can improve the aligment and anchoring. For more details see: http://wiki.lazarus.freepascal.org/index.php/GUI_design FYI. I just commited a patch to fpc (2.1.1) trunk that changes the Optimizer options. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] OT: fast vector and matrix math
Hello everyone, I know this is probably the wrong list to ask such thing but as I am not on the fpc list and many people on this list know alot more about coding than I do I just ask here. I exclusively do (real time) graphics programming (on a hobby level) and for most stuff freepascal is fast enough. But now I have come to a point where I'd really like to have some faster vector/matrix math. So I ask you guys if anybody knows of a way to achieve this. I have read that SSE/3DNow are the way to go but AFAIK there is no support for that in fpc. I don't know much about interaction with other languages but would it be possible to use/write a SSE/3DNow math lib in C and then use this for my calculations. (I hate C but more speed is more speed and if it is only the real low level stuff, I think I can deal with it). I am open for any suggestion esp. the ones not involving any C coding. Sorry, but the internal assembler of fpc already supports SSE/SSE2/3Dnow since years. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] compiling Lazarus 0.9.12 consumes a lot of memory
Alexander Todorov wrote: Hello, I have just installed Lazarus 0.9.12 / SVN Revision 8700 from source forge. When I try to compile an old application the following happens : 1) click on Run - Build all 2) all source files in the project are compiled 3) linking begins 4) ld.exe begins to consume a lot of memory In task manager I see ld.exe consuming over 100MB and still growing. After a while my machine becomes unstable and have to kill lazarus.exe, ld.exe and ppc386.exe The application is not compiled. Running it gives a black screen, after that a dos prompt is shown for a while with a message Program too big to fit in memory. Tested on Windows XP, FPC 2.0.2 (I suppose, the one that comes with Lazarus installer). I have used Lazarus 0.9.8 from 03.02.2006 /from source forge/ with FPC 2.0.2 on Linux and had no such problems. Compairing Linux and Windows is compairing apples and oranges. The linker has the same name, but the windows linker is far less efficient. Also linking on windows is more demanding because of the smartlinking necessary for the windows unit. Because many people requested to have small executables, I made smartlinkable compilable units available for the fpc units and the lcl. This was not the case in 0.9.10. So, all in all, I am not surprised. It is a problem of the GNU linker. There is better way (--gc-sections) to do the smartlinking that requires less memory but it is not implemented for the Windows target (pe-i386) in the linker. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] SVN problem
And I thought I was the only one experiencing this issue. No, I haven't found a solution yet. Been downloading the complete snapshots every couple of days, to stay current. :-( I even joined the SubVersion and FPC mailing list, to see if someboby could explain what that error message means. Still no answer! Who maintains the FPC and Lazarus svn repository? Could we contact them and ask if any settings have been changed on the server in the last two weeks (that's when this problem started). Nothing has changed on the server. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Can't make lazarus
Yes I checked and now the subdir /usr/local/bin is in the PATH but if I go to this subdir and execute directly ppcppc it doesn't recognize the command, but if I use ./ppcppc the it works, and I don't know why... You need to login again probably. Also try 'echo $PATH' to see what the current path is. Maybe other configuration files also set the PATH. Also the fpc executable needs to be in the path. This is needed to find out that ppcppc needs to be used, becuase the fallback is to ppc386 which is invalid for powerpc. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
At 09:26 15-1-2006, you wrote: What do PPU files contain? symbolic links or hard links? See below: - The .TPU format doesn't contain symbolic links to other units, it contains hard links to particular offsets in the interface part of other .TPU files. If those other units change their interface, the .TPU is made obsolete and needs to be recompiled. - Any reasonable update beyond a minor bug fix release is likely to change the interface of some commonly used units like SYSTEM. This makes everything obsolete. - Borland chose to do things this way because it leads to drastic speedups in linking. Essentially all the work involved in linking a unit to the units it uses gets done during compile time, and doesn't need to be repeated again when the program is linked. PPU contains hard-links to symbol numbers. See the output of ppudump. But PPU information is only used for compilation. For the linker standard .o files are generated. Peter _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
At 20:16 15-1-2006, you wrote: On Sun, 15 Jan 2006, L505 wrote: What do PPU files contain? symbolic links or hard links? They don't contain links at all. The accompagnying .o files contain symbolic links, as they are standard elf or pecode object files. Michael. Ahh I see.. does microsoft visual studio create similar pecode object files? I'm thinking maybe one reason borland delphi compiler/linker is so fast is because of these hard links - but I'm no compiler guru yet. As for C++ Builder I'm not sure, I've heard it was slow compiler/linker. Yes, delphi and tp7 are fast because it has an internal linker and the dcu/tpu files contain everything needed to do incremental linking. FPC is slower because it needs to write PPUs for its own and write .o files for the linker. Then the linker is called as external program requiring also program startup and it needs to read the .o file. So in short: The only way to get a major speedup in linking is to have an internal linker so the .o is not needed anymore and can be stored in the ppu. But i don't have the time to code such an internal linker so don't expect anything before 2007. Peter _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
At 20:40 15-1-2006, you wrote: So in short: The only way to get a major speedup in linking is to have an internal linker so the .o is not needed anymore and can be stored in the ppu. But i don't have the time to code such an internal linker so don't expect anything before 2007. And I wonder about the Windows.a and Windows.o file, do you think borland uses some magic tricks there or do they actually just treat the windows.tpu/windows.dcu file just like any other dcu file. I guess I will look at the DCU file and report back with more information, but it is hard to say whether they place the entire dcu file into memory or whether they have some other magic tricks up their sleeves. All those external references to DLLs are generated by the linker and don't need to be stored in the dcu. For FPC we can do the same since ld now also supports direct linking to DLL files. When the FPC port to win32 started that was not the case. Peter _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
At 22:29 15-1-2006, you wrote: All those external references to DLLs are generated by the linker and don't need to be stored in the dcu. For FPC we can do the same since ld now also supports direct linking to DLL files. When the FPC port to win32 started that was not the case. I remember that was discussed in the article you pointed out, thanks for clearing this up. I wonder how much this will improve speed, I think the article said 10-25 percent. Only experimenting will tell I guess :-) You can expiriment yourself, use the 2.1.1 compiler from today and compile everything with option -WI-. Peter _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
Florian Klaempfl wrote: Units imported from dlls require import entries. This would increse the size of executables significantly Yes, was afraid of that. We would need to make a wincommon or so, with all those that LCL uses (or any other measure of common), winextra, win2k, winxp, etc, Hmmm... Some interesting stuff about ld can be found at http://sourceware.org/binutils/docs-2.16/ld/WIN32.html under direct linking to a dll _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Compiler speed?
At 18:04 13-1-2006, you wrote: It's the linker and it is GNU's fault not FPC. Lazarus is a lot faster on Linux compared to Windows. Is this because of GNU linker ported to Win32 ? 1. Windows DLL requires imports libraries those are huge 2. Windows is slower in I/O Peter _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
Of course it is probably the Win32 linker that is the real slow one, and I don't know why that is - so any mailing lists threads or sites you know of please post them here and/or discuss. I guess part of the slowness is the use of GROUP() and the large libpwindows.a _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
Vincent Snijders wrote: An extra handicap for the linker is the fact that the windows unit, which is rather large is always smartlinked, resulting in (I estimate) ten thouands of object files (archived in the .a file). You probably won't have this amount of .o files in c programs. Can we seperate the windows unit in a unit that has function declarations that all versions of windows have, and one that only WinNT/2k/others have? Or is this not practical ? You'll get an executable that has a lot of DLL dependencies. And that is therefor also a lot larger. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Changes for latest fpc-trunk
Hi all, in revision r2020 of fpc the basic-generics support is added. But with that patch double identifiers aren't allowed anymore, it seems. That double identifiers were not reported was an error. It was upto the order of definition. If the property was defined before the procedure in the class declaration then it would also fail in the old situation. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Snapshot and latest subversion very unstable
On Sun, 18 Dec 2005 21:52:55 +0100 SALVATORE COPPOLA [EMAIL PROTECTED] wrote: I experienced that on opening a project or a package Lazarus give an AV error with the follow BackTrace: Program received signal SIGSEGV, Segmentation fault. $0085e395 in SYSTEM_SYSGETMEM_FIXED$LONGINT$$POINTER () That's all? Only one line? Can you try a stable compiler release? Don't spend time on debugging crashes of code compiled with current FPC 2.1.1. There is a known issue with ansistrings. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Re: Big size of W32 *.exe files
May be it is impossible to compilate Lazarus wit Smart Linking? No, it is not. Acctually I never tryed to recompile lazarus IDE with smart linking, but the LCL, the code that is acctually put inside your program surely can be compiled with smart linking. I bet this will bring the exe size down. Make sure you have a lot of memory (1+ GB) available and expect much longer linking times. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Re: Big size of W32 *.exe files
- Why I must use strip to cut off debug information both in Linux and in Windows, even if I set Strip Symbols From Executable(-Xx) to True in Compiler options? Because -Xx is buggy? Just tested on Lazarus 0.9.10 on Linux and it did not strip my executable. Is there already a bug report for this? Acctually I think the bug report should go to FPC For Linux it should work. For Win32 it is a known issue that ld is buggy. Sending a bug report to fpc doesn't help, we can't solve it. Better report it to the GNU binutils. Peter _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Re: Big size of W32 *.exe files
For Linux it should work. For Win32 it is a known issue that ld is buggy. Sending a bug report to fpc doesn't help, we can't solve it. Better report it to the GNU binutils. How about the internal linker for FPC. Is there any outlook on when this could be implemented, or are there no concrete plans yet?? Don't expect anything at all before second half of 2006. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] OT: Did any onw saw Delphi 2005?
I can create an internal linker. But i don't have time for fpc for the rest of 2005. The most challenging and time consuming part of creating a linker is the debugging/analysing of problems with faulty generated applications. How hard do you think it is to create such a beast ? Depends on your knowledge about the subject. But it will not be a simple addition. Some steps are: - Read about linkers and loaders at, a good book can be found at http://www.iecc.com/linker/ - Get familiar with the fpc sources - Analyse what is already available in the fpc sources. A couple of years ago i already got a basic linker working for go32v2. - Start coding, the first thing to add is a scriptable memory/file layout, like the ld-scripts. - Add PE coff support - Add static ELF support - Add shared ELF support - Add optimizations for smartlinking - Add internal object format I added this list also to the wiki http://www.freepascal.org/wiki/index.php/Internal_Linker _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] OT: Did any onw saw Delphi 2005?
I know the linker is verry slow but the compiler isn't verry fast either, this can be clearly seen on slower machines, Delphi somehow manages to compile and link everything verry fast, about 10x faster wich is impressive with all the bloat it has, while using Lazarus i can see when linker gets into action or i think i do, can someone tell me what's the best way of knowing when the linker gets into action, i Compiling with -E will skip the linking part. That will give you an idea how fast the compiler itself is. But the main priority for fpc is maintainability and only after that comes speed. There are a couple of know places that could be optimized for speed, but for now it is don't change things that work. don't know who could make a better linker cause this one has support for many app types, a compiler with a built-in linker would probably do a better job. I can create an internal linker. But i don't have time for fpc for the rest of 2005. The most challenging and time consuming part of creating a linker is the debugging/analysing of problems with faulty generated applications. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
