View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0012492 | FPC | RTL | public | 2008-10-26 18:26 | 2009-11-01 17:55 |
Reporter | Pierre Pede | Assigned To | Jonas Maebe | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | assigned | Resolution | open | ||
Product Version | 2.2.2 | ||||
Summary | 0012492: RTL does not compile with CREATESHARED=1 under Linux i386 | ||||
Description | When i try to compile the rtl package i get the following errors: /usr/lib/fpc/2.2.2/ppc386 -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../i386 -Fi../unix -Fii386 -FE. -FU/home/main/build/fpc-2.2.2-shared/fpcsrc/rtl/units/i386-linux -Cg -Aas -di386 -dRELEASE -Us -Sg system.pp syscall.inc(84,18) Error: Generating PIC, but reference is not PIC-safe syscall.inc(89,14) Error: Generating PIC, but reference is not PIC-safe syscall.inc(106,19) Error: Generating PIC, but reference is not PIC-safe syscall.inc(111,14) Error: Generating PIC, but reference is not PIC-safe syscall.inc(131,19) Error: Generating PIC, but reference is not PIC-safe syscall.inc(136,14) Error: Generating PIC, but reference is not PIC-safe syscall.inc(158,19) Error: Generating PIC, but reference is not PIC-safe syscall.inc(163,14) Error: Generating PIC, but reference is not PIC-safe syscall.inc(188,19) Error: Generating PIC, but reference is not PIC-safe syscall.inc(193,14) Error: Generating PIC, but reference is not PIC-safe syscall.inc(222,19) Error: Generating PIC, but reference is not PIC-safe syscall.inc(227,14) Error: Generating PIC, but reference is not PIC-safe syscall.inc(260,19) Error: Generating PIC, but reference is not PIC-safe syscall.inc(265,14) Error: Generating PIC, but reference is not PIC-safe fastmove.inc(109,41) Error: Generating PIC, but reference is not PIC-safe fastmove.inc(242,41) Error: Generating PIC, but reference is not PIC-safe fastmove.inc(859,21) Error: Generating PIC, but reference is not PIC-safe fastmove.inc(861,21) Error: Generating PIC, but reference is not PIC-safe i386.inc(1342,20) Error: Generating PIC, but reference is not PIC-safe system.pp(344) Fatal: There were 19 errors compiling module, stopping Fatal: Compilation aborted make[2]: *** [system.ppu] Fehler 1 make[2]: Leaving directory `/home/main/build/fpc-2.2.2-shared/fpcsrc/rtl/linux' make[1]: *** [linux_all] Fehler 2 make[1]: Leaving directory `/home/main/build/fpc-2.2.2-shared/fpcsrc/rtl' make: *** [rtl] Fehler 2 | ||||
Additional Information | OS: Linux x86 | ||||
Tags | dynamic library, shared | ||||
Fixed in Revision | 13672,13703 | ||||
FPCOldBugId | 0 | ||||
FPCTarget | |||||
Attached Files |
|
related to | 0008119 | resolved | Florian | Compiling linux/i386 shared libraries using -Cg fails |
parent of | 0013829 | closed | Jonas Maebe | math - IsZero - Internal error 200502052 |
parent of | 0014958 | closed | Jonas Maebe | Cannot unload shared library |
related to | 0015175 | closed | Jonas Maebe | Mixed FPC/C++ program crashes in the std C++ library |
|
I'm on a good way. I have fixed rtl to compile rtl with shared library support (make clean shared install ...). After install i have a library in fpc lib path: 1777970 1. Jun 15:14 libfprtl-2.3.1.so The size of a simple test program is now about 6kb instead of 310kb. tstshared.pas: ---<schnipp>--- program tstshared; uses sysutils, baseunix; var i: integer; begin writeln(ParamStr(0)); // testing command line argv0 for i := 1 to ParamCount do begin writeln(inttostr(i)+' '+ParamStr(i)); // testing command line args end; writeln('getenv SHELL '+baseunix.fpgetenv('SHELL')); // testing operatingsystem_environment bla readln; halt(1); // testing return value end. ---<schnapp>--- 1.) compiled without -XD -rwxr-xr-x 1 daily fpc 310916 1. Jun 17:23 tstshared 2.) compiled with -XD (i patched fpcmake) -rwxr-xr-x 1 daily fpc 5644 1. Jun 17:22 tstshared Next test Programm is about dynamic loading lib files. The source come from fpc manual about shared libraries. ---<schnipp>--- library subs; function SubStr(CString: PChar;FromPos,ToPos: Longint): PChar; cdecl; var Length: Integer; begin Length := StrLen(CString); SubStr := CString + Length; if (FromPos > 0) and (ToPos >= FromPos) then begin if Length >= FromPos then SubStr := CString + FromPos - 1; if Length > ToPos then CString[ToPos] := #0; end; end; exports SubStr; end. ---<schnapp>--- && ---<schnipp>--- program testsubs; Type TSubStrFunc = function(const CString:PChar;FromPos,ToPos: longint):PChar;cdecl; Function dlopen(name: pchar;mode: longint):pointer;cdecl;external 'dl'; Function dlsym(lib: pointer; name: pchar):pointer;cdecl;external 'dl'; Function dlclose(lib: pointer):longint;cdecl;external 'dl'; var s: PChar; FromPos, ToPos: Integer; lib : pointer; SubStr : TSubStrFunc; begin s := 'Test'; FromPos := 2; ToPos := 3; lib:=dlopen('libsubs.so',1); Pointer(Substr):=dlsym(lib,'SubStr'); WriteLn(SubStr(s, FromPos, ToPos)); dlclose(lib); end. ---<schnapp>--- 1.) compiled without -XD -rwxr-xr-x 1 daily fpc 158920 1. Jun 17:38 libsubs.so -rwxr-xr-x 1 daily fpc 165804 1. Jun 17:38 testsubs 2.) compiled with -XD (i patched fpcmake) -rwxr-xr-x 1 daily fpc 2375 1. Jun 17:39 libsubs.so -rwxr-xr-x 1 daily fpc 3348 1. Jun 17:39 testsubs Both programs works fine. I had to move FPC_LIB_EXIT alias from system.inc to si_dll to get it work in "shared library way". If FPC_LIB_EXIT is not called from si_dll i get an exception because of wrong frame context. The System LIB_EXIT calls the InternalExit function which dones some cleanup things. I have published InternalExit function though an alias and called the function from dll in exit code. I also have removed alias FPC_LIB_EXIT (for linux i386 only) from system.inc. Without removing i got the following error: ---<schnipp>--- /home/daily/daily/bin/ppc386 -Fu/home/daily/daily/lib/fpc/2.3.1/units/i386-linux/rtl -FE. -FUunits/i386-linux -di386 src/subs.lpr Target OS: Linux for i386 Compiling src/subs.lpr Linking ./libsubs.so /home/daily/daily/lib/fpc/2.3.1/units/i386-linux/rtl/si_dll.o: In function `FPC_LIB_EXIT': si_dll.pp:(.text+0x70): multiple definition of `FPC_LIB_EXIT' /home/daily/daily/lib/fpc/2.3.1/units/i386-linux/rtl/system.o:system.pp:(.text+0x15b10): first defined here Error: Error while linking Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted make: *** [subs] Fehler 1 ---<schnapp>--- If i have finished my implementation, i think, we have to talk about this. After removing alias from system all is fine. But now to my questions: 1.) The units which i have really good testet are: file linux/i386/si_prc.inc (Prog: tstshared.pas) file linux/i386/si_dll.inc (Prog: subs && testsubs) Wtf i have to do to link the following other units ? file linux/i386/si_c21g.inc file linux/i386/si_c21.inc file linux/i386/si_c.inc file linux/i386/si_g.inc file linux/i386/si_uc.inc TIA |
|
Ok, found -cg switch, which should enable gprof monitoring. match for file linux/i386/si_c21g.inc i also fixed assember code for si_c21g.inc. But i go an exception on program exit which is caused by write_mon function from glibc. I got the same error with unpached rtl. Looks like it is not working in the moment or may be a compiler switch issue. |
|
-pg is indeed currently broken for Linux, see 0013052 |
|
Well, si_c21g.inc works fine now. I'm now able to compile testprograms using -cg compilerswitch with and without -Cg -XD switch. Profiling works in both cases. I now have some questions to other missing units for pic support. 1.) Any idea in which cases units: file linux/i386/si_c21.inc file linux/i386/si_c.inc file linux/i386/si_g.inc file linux/i386/si_uc.inc are used ? 2.) - file linux/i386/si_c21.inc I think it's glibc elf startup without profiling support. I will try to rewrite si_c21g.inc for si_c21.inc without gmon startup code. What i have to do for linking si_c21.o ? 3.) file linux/i386/si_c.inc file - linux/i386/si_g.inc I think it's for standard libc. (and si_g.inc for libc profiling) What i have to do for linking si_c.o/si_g.o ? 4.) file linux/i386/si_uc.inc Looks like uClib. How to test ? 5.) And my last question is: Where i have to send my PIC patch for i386 linux ? |
|
2) add {$linklib c} to your program 3) compile on a linux/i386 machine where the dynamic linker is /lib/ld-linux.so.1 instead of /lib/ld-linux.so.2 (and then add {$linklib c} resp. compile with -pg) 4) compile on a uclibc system (the dynamic linker should be called /lib/ld-uClibc.so.0) 5) you can attach them to this bug report. Thanks. |
|
OK, i was able to fix point 2). I really have problems to test point point 3). ld-linux.so.1 is outdated. I found a old slackware 2 version (retro linux distro) but it not recognize my harddisk my virtual machine. I rewrited code for si_c.o and si_g.o but i was not able to test. I suggest to release from old burdens. You should set libc5 to deprecated. Point 4) is not easy too. I did not find a i386 distro thas is based on uClibc. I will try to test and link in an chroot environment on my centos system. Hints are welcome. |
|
uClibc is mostly used in embedded environments. I indeed don't think there is any regular Linux distribution that ships with uClibc. As far as I am concerned, no longer supporting libc5 is fine. |
|
If you have any patches, please attach them too. |
|
I'm still testing. I think i will finish sunday. |
2009-06-30 01:07
|
|
|
I have attached my initial patch. Look into README.txt inside. Sorry for delay. |
2009-07-01 22:34
|
fpc-13198-pic-ppumove.patch (1,470 bytes)
--- fpc-13198/compiler/utils/ppumove.pp 2009-06-29 21:57:20.000000000 +0200 +++ fpc/compiler/utils/ppumove.pp 2009-07-01 21:58:29.000000000 +0200 @@ -43,9 +43,9 @@ getopts; const - Version = 'Version 2.1.1'; + Version = 'Version 2.3.1'; Title = 'PPU-Mover'; - Copyright = 'Copyright (c) 1998-2007 by the Free Pascal Development Team'; + Copyright = 'Copyright (c) 1998-2009 by the Free Pascal Development Team'; ShortOpts = 'o:e:d:i:qhsvb'; BufSize = 4096; @@ -248,6 +248,8 @@ ext, s : string; ppuversion : dword; + i : integer; + wasNumeric : boolean; begin DoPPU:=false; If Not Quiet then @@ -404,11 +406,20 @@ { strip lib prefix } if copy(s,1,3)='lib' then delete(s,1,3); + ext:=ExtractFileExt(s); - if ext<>'' then - delete(s,length(s)-length(ext)+1,length(ext)); + wasNumeric := true; + while wasNumeric and (ext<>'') do + begin + for i := 1 to length(ext) do + wasNumeric := (ext[i] in ['0'..'9']); + if (ext<>'') then + delete(s,length(s)-length(ext)+1,length(ext)); + ext:=ExtractFileExt(s); + end; - libs:=libs+' -l'+s; + if (length(s)>0) then + libs:=libs+' -l'+s; outppu.putlongint(m); end; |
|
Any reason for the SYSENTER_SUPPORT define? |
|
Regarding the FPC_LIB_EXIT stuff: please do not change the generic code there. If you need a special case for Linux in certain cases, you can change the name of the used init/fini routine in compiler/systems/t_linux.pas (search for "-fini"). |
|
Ok, sorry for delay. It's holiday time. I also have installed virtual environment now. I hope to have better environment for testing now. @Florian - Any reason for the SYSENTER_SUPPORT define Not clear. If there is a explizit {$DEFINE SYSENTER_SUPPORT} it was for testing. {$DEFINE SYSENTER_SUPPORT} should come from os config if os supports sysenter call's instead of syscall. @Jonas. ok i will change that in next patch 1.) I had problems to compile some packages. Sometimes there were development packages missing or i had problems to get outdated packages working. I am not sure about the development tree layout. It's a hard job to compile fpc dir in one step if there are some errors in packages. It would be great if there is a way to compile and install fpc dir without packages and then compile and install packages in a second step. It looks like a "make shared" insite packages dir does not have the same environment if it is called through "make all" from fpc dir. A other missing feature is something like "make check" in fpc dir which should tell missing development libraries for dynamic linking. What do you think ? 2.) A other good idea may be to try to compile packages. If there is NO error make create a i386-linux.compiled in the package dir. If there is an error make will not create somethink like i386-linux.error. If make check dependencies it will not only look for Package.fpc, is also looks for i386-linux.compiled or i386-linux.error. if i386-linux.error is found in regarding package dir, make will skip package because of error compile status file. if make does not find any compile status file it will try to compile reference package before them self. What do you think ? |
|
1) I don't understand. You should not need to have any libraries installed to compile the packages directory, because the libraries are only necessary during linking (and compiling units does not require any linking). At least one difference between doing "make all" in the top dir and "make shared" in the packages dir, is that "make all" in the top dir will add "RELEASE=1" to the make command in the packages dir. The "make check" would first require a) someone to actually test the packages on all supported platforms. In general, the packages directory is a mess and many packages have not been tested on most platforms b) someone to write test programs for all packages 2) I disagree about the skipping in case of error. An error is an error and either the package needs to be disabled for the platform, or fixed. Automatically compiling dependencies should already happen if you use "make" inside the packages directory, because the Makefile there should define all dependencies. |
|
Part 1 ------ ok, may be i overshoot the mark. The normal way to build fpc sources is to have a fpc binary distribution, checkout fpc sources and invoke a 1#) "make all" in fpc dir. The whole distribution is build static. After this you invoke a 2#) "make install". The result is that all binaries (compiler, utils) and all other runtime files (rtl ppu,o and package ppu,o) files are installed to target dir. If you now change fpc environment to new target dir (fpc.cfg and FPC_* env) you can start custom development and you will work with new fpc binaries. So far so good. My first milestone was to rebuild rtl shared by entering rtl directory and invoke 3#) "make clean shared". The result is rtl is build with -Cg flag and create the library libfprtl-2.3.1.so is linked. If i now invoke a 4#) "make install" from shared compiled rtl directory the libfprtl-2.3.1.so and the shared ppu,o files are installed into target dir. You now can compile very small custom binaries that are using shared rtl (linked against libfprtl-2.3.1.so). At this point packages ppu,o are not working anymore because system.ppu signature has changes because of recompiling rtl dir. But this was only the first milestone to find a start. I hope you agree with me that rebuild rtl shared in a second step is no solution. By the way for my better unterstanding (answer as 5# please). A "make all" in fpc dir is a compiler cycle. The first round is used to build rtl and compiler using old preinstalled compiler (may be also utils, i'm not sure). In the second round the new compiler is rebuilding rtl and all packages (may be also utils, i'm not sure). Part 2 ------ ok, next milestone was to integrate shared rtl in "make all" from fpc dir. What i now did was to patch Makefile.fpc (fpc-13198-pic-Makefile.patch) from fpc dir. ---<schnipp>--- --- fpc-13198/Makefile.fpc 2009-06-29 22:04:16.000000000 +0200 +++ fpc-13198-pic/Makefile.fpc 2009-06-28 18:32:48.000000000 +0200 @@ -95,8 +95,8 @@ ALLTARGET=all else ifndef ALLTARGET -SHAREDTARGETS= -SMARTTARGETS=win32 go32v2 linux freebsd netbsd openbsd netware netwlibc darwin +SHAREDTARGETS=linux +SMARTTARGETS=win32 go32v2 freebsd netbsd openbsd netware netwlibc darwin ifneq ($(findstring $(OS_TARGET),$(SHAREDTARGETS)),) ALLTARGET=shared else ---<schnapp>--- In looks like the exactly this was the idea to compile shared. (Please correct if i am wrong (6#)) What i now have recognized is that if you now invoke a "make clean all" in fpc dir. The first cycle compiles rtl (no -Cg in lines) and compiler static (not sure about utils) and in a second step rtl and packages with "make shared". And now i come to my previous post 1). In this case shared linking is done for rtl and all packages in the "make all" from fpc dir. I now can say around 80% of packages compile fine but it's a hard way to come through all packages. There are some that are outdated ( i had problems to get libbla-devel packages ). Some have reference failures. And now why i come to 2). For every single error i have rebuild whole fpc dir with "make all" which does compiler cycle and then rebuilding shared rtl and shared packages. If i make a "make shared" in package dir it looks like this is not enough (-Fu switches looks wrong). I agree with you that an error is an error an should be fixed. But in case of packages (i mean only packages, not compiler or rtl) there should be an flexible error management. But thanks for "RELEASE=1" hint. I will try that from package dir and give feedback. |
|
You're correct about 5#) 6# indeed also seems correct, although I don't know whether it has ever been really tested (since shared linking has been broken since quite a while now) Using "make all RELEASE=1" in the packages dir you should be able to get exactly the same result as with "make all" in the the top dir (and continue where the previous compilation stopped because of an error), and not have to completely restart the "make all" process in the top directory. |
|
"make all RELEASE=1" does not work in package dir but was able to solve by introducing a new build target in main Makefile.fpc. "make buildother" restart building packages and utils because some utils depends on some packages. But i now have a bigger problem with "make install". Whole fpc path is compiled fine. rtl and package dirs are filled with ppu,o and libfpc*bla*.so files. I now want to install files into fresh target dir. I set INSTALL_PREFIX to /home/daily/fpc-2.3.1-shared. when i now invoke "make install" i can see that fresh dir is filled with compiler. but rtl makes problems. 1#) "make install" try to rebuild some parts of rtl. In Makefile.fpc of fpc Makefile a "make install" do: ---<schnipp>--- install: $(BUILDSTAMP) $(MAKE) installbase $(INSTALLOPTS) $(MAKE) installother $(INSTALLOPTS) ---<schnapp>--- which is is detail for installbase: ---<schnipp>--- installbase: # create dirs $(MKDIR) $(INSTALL_BASEDIR) $(MKDIR) $(INSTALL_BINDIR) # install compiler+rtl $(MAKE) compiler_$(INSTALLTARGET) $(INSTALLOPTS) $(MAKE) rtl_$(INSTALLTARGET) $(INSTALLOPTS) ---<schnapp>--- In detail for "$(MAKE) rtl_$(INSTALLTARGET) $(INSTALLOPTS)": ---<schnipp>--- make rtl_distinstall FPC=/home/daily/build/fpc/compiler/ppc386 ZIPDESTDIR=/home/daily/build/fpc FPCMAKE=/home /daily/build/fpc/utils/fpcm/fpcmake make rtl_distinstall FPC=/home/daily/build/fpc/compiler/ppc386 ZIPDESTDIR=/home/daily/build/fpc FPCMAKE=/home/dail y/build/fpc/utils/fpcm/fpcmake make rtl_distinstall FPC=/home/daily/build/fpc/compiler/ppc386 ZIPDESTDIR=/home/daily/build/fpc FPCMAKE=/home/dail y/build/fpc/utils/fpcm/fpcmake make[2]: Entering directory `/home/daily/build/fpc' make -C rtl distinstall make[3]: Entering directory `/home/daily/build/fpc/rtl' make -C linux all make[4]: Entering directory `/home/daily/build/fpc/rtl/linux' /home/daily/build/fpc/compiler/ppc386 -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../i386 -Fi../unix -Fii386 -FE. -FU/home/dai ly/build/fpc/rtl/units/i386-linux -di386 -dRELEASE ../inc/ctypes.pp ~~~ and so on ~~~ ---<schnapp>--- This kills my fresh build shared ppu,o files Any idea how to solve this (Answer 1# please)? 2#) Is there a plan where to put shared or debug files in fpc dir layout ? Current fpc target layout is: fpc/bin fpc/lib/fpc/2.3.1/units/i386-linux/fcl-bla fpc/lib/fpc/2.3.1/units/i386-linux/rtl ok, looks good so far. But where to integrate other object files ? For example: fpc/bin fpc/lib/fpc/2.3.1/units/i386-linux/fcl-bla fpc/lib/fpc/2.3.1/units/i386-linux/rtl fpc/lib/fpc/2.3.1/debug/i386-linux/fcl-bla fpc/lib/fpc/2.3.1/debug/i386-linux/rtl fpc/lib/fpc/2.3.1/shared/i386-linux/fcl-bla fpc/lib/fpc/2.3.1/shared/i386-linux/rtl fpc/lib/fpc/2.3.1/shared-debug/i386-linux/fcl-bla fpc/lib/fpc/2.3.1/shared-debug/i386-linux/rtl I saw an old example where path was changed in /etc/fpc.cfg by DEFINES. So it would be possible to has RELEASE and DEBUG files or also STATIC and SHARED units in different pathes. 3#) The current "make shared" target produces "make all CREATESHARED=1 LINKSHARED=1 CREATESMART=1" I'm not sure if CREATESMART=1 is in the right place when building shared. Is PIC code needed for smart linking ? My feeling told me that the one part should be "make smart" which should produce "make all CREATESMART=1" ( smartlinking on base of static units ) and "make shared" something like "make all CREATESHARED=1 LINKSHARED=1". Please bring light in the darkness (answer 3#). |
|
---<ok, forget 3#. In the moment it is needed because of static linking in some packages. For example unit strutils is not in library libfprtl-2.3.1.so. If a packages is linked with "make all CREATESHARED=1 LINKSHARED=1" strutils.o is not linked correctly.>--- Not sure about that. I got linker errors when CREATESMART=1 is activeded. |
|
At the moment i have gone back to "make all CREATESHARED=1 LINKSHARED=1". Looks better now. I was able to compile the rest after disabling a few outdated packages. A "make install" insite fpc build directory create the following shared libs unter /bla/fpc-2.3.1/lib ---<schnipp>--- fpc libfpfcl-net-2.3.1.so libfpldap-2.3.1.so libfppxlib-2.3.1.so libfpa52-2.3.1.so libfpfcl-passrc-2.3.1.so libfplibxml2-2.3.1.so libfpregexpr-2.3.1.so libfpaspell-2.3.1.so libfpfcl-process-2.3.1.so libfpmad-2.3.1.so libfprsvg-2.3.1.so libfpcairo-2.3.1.so libfpfcl-registry-2.3.1.so libfpmodplug-2.3.1.so libfprtl-2.3.1.so libfpcdrom-2.3.1.so libfpfcl-res-2.3.1.so libfpncurses-2.3.1.so libfpsdl-2.3.1.so libfpchm-2.3.1.so libfpfcl-web-2.3.1.so libfpoggvorbis-2.3.1.so libfpsvgalib-2.3.1.so libfpdbus-2.3.1.so libfpfcl-xml-2.3.1.so libfpopenal-2.3.1.so libfpsyslog-2.3.1.so libfpfastcgi-2.3.1.so libfpfpgtk-2.3.1.so libfpopengl-2.3.1.so libfpunixutil-2.3.1.so libfpfcl-async-2.3.1.so libfpfpmkunit-2.3.1.so libfpopenssl-2.3.1.so libfpunzip-2.3.1.so libfpfcl-base-2.3.1.so libfpfv-2.3.1.so libfppasjpeg-2.3.1.so libfputmp-2.3.1.so libfpfcl-db-2.3.1.so libfphash-2.3.1.so libfppaszlib-2.3.1.so libfpuuid-2.3.1.so libfpfcl-fpcunit-2.3.1.so libfphttpd13-2.3.1.so libfppcap-2.3.1.so libfpzlib-2.3.1.so libfpfcl-image-2.3.1.so libfphttpd20-2.3.1.so libfpproj4-2.3.1.so libfpfcl-json-2.3.1.so libfphttpd22-2.3.1.so libfppthreads-2.3.1.so ---<schnapp>--- Looks like the rest are linking errors because missing or wrong package implementations. i try to get lazarus working :) |
|
I wonder why some units are not shared. Some newer units like FGL are. IOW, it might be pure coincidence if strutils is not in rtl.so. (and several other units too). I think all units that don't reference external libs (like cthreads etc) can be included. Test, and if it works fine we can add them. |
|
For the moment rtl should not be the problem anymore. I currently put all units into shared section (no loaders and sysinit units). Looks good. The problem i now have are some packages when i try to build shared. For example when i try to link lazbuild i got some errors regarding fcl-db. Looks like package layout is the problem. The Makefile.fpc insite fcl-db dir does not have units section. Only dirs sections. The result is that a "make shared" only call "make shared" for its subparts and after build there is no shared linking because there are no units defined. Each subpart created its own shared library with the same package name. So after the whole build each ppu known that is linked to libfpfcl-db-2.3.1.so but libfpfcl-db-2.3.1.so does only contain units from last subpart. The solution could be to do shared linking only if package is no subpart. It should be easy to detect because each subpackage does contain: ---<schnipp>--- [package] main=fcl-db ---<schnapp>--- I tried to fix it by adding: ---<schnipp>--- [shared] build=n ---<schnapp>--- Now linking is skipped but i have problems to put all together. The first problem is that "shared" part is not executed in main Makefile.fpc I tied to fix it by adding a extra rule for shared. Now it is called but it does not work in correct way. ---<schnipp>--- sharedbuild: $(MAKE) all CREATESHARED=1 LINKSHARED=1 sharedlink: $(PPUMOVE) -q $(wildcard units/$(FULL_TARGET)/*.ppu) -i$(COMPILER_UNITTARGETDIR) -o$(SHARED_FULLNAME) -d$(COMPILER_UNITTARGETDIR) shared: sharedbuild sharedlink ---<schnapp>--- The problem is that $(wildcard units/$(FULL_TARGET)/*.ppu) is wrong or to early. I tried to put it in prerules but this is to early. The units files are not build at this moment. Looks like the simplest way is to add them constant. Better way would be to add a collect stage in ppumove or before ppumove. What do you think ? |
|
ok, looks like shared support for packages is not really working for packages other than rtl at the moment. I go on with finishing this issue. My current status is that building rtl shared is working fine. The result a shared library with name libfprtl-2.3.1.so. Lazarus works fine when linking against libfprtl-2.3.1.so. The binary sizes are reduced about 2MB when linking -XD. Sizes of binaries that are build with lazarus are also reduced and working. I go on writing tests for libraries linked to si_dll. |
|
Thanks a lot for the status update and for your great work! |
|
Calling a function from a dynamically library does also work fine (dlopen). ppumove a unit into shared lib is fine too. I plan to update my tree to current svn revision and verify my tree against current version. I have seen that there is a test framework inside fpc dir. First i had problems to run tests but i was able start a "make full" by calling "make full FPCDIR=/home/daily/build/fpc FPC=/home/daily/build/fpc/compiler/ppc386 TEST_FPC=/home/daily/build/fpc/compiler/ppc386" I hope where is nothing missing is my call. I get to following result: ---<schnipp>--- utils/digest output/i386-linux/log Total = 4795 (54:4741) Total number of compilations = 2801 (40:2761) Successfully compiled = 2163 Successfully failed = 598 Compilation failures = 38 Compilation that did not fail while they should = 2 Total number of runs = 1994 (14:1980) Successful runs = 1980 Failed runs = 14 Number units compiled = 99 Number program that should not be run = 66 Number of skipped tests = 106 Number of skipped graph tests = 10 Number of skipped interactive tests = 22 Number of skipped known bug tests = 6 Number of skipped tests for other versions = 10 Number of skipped tests for other cpus = 13 Number of skipped tests for other targets = 45 ---<schnapp>--- Looks like i have to install some libraries to reduce compilation errors :) Now i have some questions about that. 1) Is there a daily build for target i386-linux and is there an automatic started test, so that i can verify against that ? 2) Are the tests managed ? 3) For what i have to look for when checking stats ? 4) Tips are welcome |
|
ok, i was able to find a bug regarding lib_exit in my implementation. I now have the same result when running tests against non patched tree :) ---<schnipp>--- utils/digest output/i386-linux/log Total = 5081 (27:5054) Total number of compilations = 2942 (16:2926) Successfully compiled = 2326 Successfully failed = 600 Compilation failures = 14 Compilation that did not fail while they should = 2 Total number of runs = 2139 (11:2128) Successful runs = 2128 Failed runs = 11 Number units compiled = 99 Number program that should not be run = 83 Number of skipped tests = 115 Number of skipped graph tests = 10 Number of skipped interactive tests = 22 Number of skipped known bug tests = 7 Number of skipped tests for other versions = 16 Number of skipped tests for other cpus = 14 Number of skipped tests for other targets = 46 ---<schnapp>--- |
|
Congratulations!! :) Can you attach your latest patches? |
|
yes i will do. Currently i test shared tree in x86-64 environment. Look good too. I also got a shared library for rtl. First i got an error while running test. utils/dotest told me that libfprtl-2.5.1.so was missing. i am not sure the there is an equivalt to LD_LIBRARY_PATH in x86-64 environment. Then i have seen that the binaries under tests/utils are not deleted when invoke a make clean. so i tried to execute i386-linux tools under x86_64 linux. i am sure that should work to but i have changed my lib to x86_64 library. i cleanly checked out test patch in revision 13601 and now test is running ... :) |
|
Indeed, you have to use "make distclean" to also delete the test utilities. |
|
Tests are finished. Looks like the same tests failed than in i386 environment. With clean revision i got: ---<schnipp>--- /home/daily/build/fpc/tests Total = 4765 (109:4656) Total number of compilations = 2812 (93:2719) Successfully compiled = 2130 Successfully failed = 589 Compilation failures = 91 Compilation that did not fail while they should = 2 Total number of runs = 1953 (16:1937) Successful runs = 1937 Failed runs = 16 Number units compiled = 97 Number program that should not be run = 77 Number of skipped tests = 243 Number of skipped graph tests = 10 Number of skipped interactive tests = 22 Number of skipped known bug tests = 5 Number of skipped tests for other versions = 16 Number of skipped tests for other cpus = 151 Number of skipped tests for other targets = 39 ---<schnapp>--- With patched tree i got: ---<schnipp>--- utils/digest output/x86_64-linux/log Total = 4826 (45:4781) Total number of compilations = 2812 (27:2785) Successfully compiled = 2196 Successfully failed = 589 Compilation failures = 25 Compilation that did not fail while they should = 2 Total number of runs = 2014 (18:1996) Successful runs = 1996 Failed runs = 18 Number units compiled = 97 Number program that should not be run = 82 Number of skipped tests = 243 Number of skipped graph tests = 10 Number of skipped interactive tests = 22 Number of skipped known bug tests = 5 Number of skipped tests for other versions = 16 Number of skipped tests for other cpus = 151 Number of skipped tests for other targets = 39 ---<schnapp>--- I think i have to call external symbol "FPC_LIB_EXIT" instead of "lib_exit" in dllprt0.as. i think after fix that problem the time is ripe to release the patch. Looks like for other linux targets there is no implementation aboult shared libraries. But i am also not able to test (arm,m68k,powerpc,powerpc64,sparc) |
|
Failed runs = 17 :) ---<schnipp>--- utils/digest output/x86_64-linux/log Total = 4833 (37:4796) Total number of compilations = 2812 (20:2792) Successfully compiled = 2203 Successfully failed = 589 Compilation failures = 18 Compilation that did not fail while they should = 2 Total number of runs = 2021 (17:2004) Successful runs = 2004 Failed runs = 17 Number units compiled = 97 Number program that should not be run = 82 Number of skipped tests = 243 Number of skipped graph tests = 10 Number of skipped interactive tests = 22 Number of skipped known bug tests = 5 Number of skipped tests for other versions = 16 Number of skipped tests for other cpus = 151 Number of skipped tests for other targets = 39 ---<schnapp>--- i think i now have to go in detail for the last error. But not today ;) |
|
ok, found the problem. when running tests ppcx64 need to have set TEST_OPT=-Cg if i look in fpcmake.ini specs there is a section is an info that -Cg is enabled by default. This should be default when running tests too. |
|
Then i come to: ---<schnipp>--- utils/digest output/x86_64-linux/log Total = 4832 (37:4795) Total number of compilations = 2812 (21:2791) Successfully compiled = 2203 Successfully failed = 588 Compilation failures = 18 Compilation that did not fail while they should = 3 Total number of runs = 2020 (16:2004) Successful runs = 2004 Failed runs = 16 Number units compiled = 97 Number program that should not be run = 83 Number of skipped tests = 243 Number of skipped graph tests = 10 Number of skipped interactive tests = 22 Number of skipped known bug tests = 5 Number of skipped tests for other versions = 16 Number of skipped tests for other cpus = 151 Number of skipped tests for other targets = 39 ---<schnapp>--- libraries without -Cg does not work because of PASCALMAIN@PLT call in dllprt0.as |
|
That's a very good result, the current results are this: http://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?action=1&run1id=42709&run2id=&noskipped=1&failedonly=1 Note that the line to look at in the output you pasted is this one: Total = 4832 (37:4795) It means that a total of 4832 tests were checked, and that 37 failed (either because compilation failed while it should have succeeded or vice versa, or because running failed while it should have succeeded or vice versa) and 4795 succeeded. You're right that for other Linux targets shared libraries are not supported anyway, so you don't have to care about them in your patch. |
|
Looks like that there is a problem in your test testup. Or it may be the operating system. i use centos 5.3. I like it :) I use: export TEST_OPT=-Cg alias do_tests='make $1 FPCDIR=$FPCBUILD FPC=$FPCBUILD/compiler/$FPCC TEST_FPC=$FPCBUILD/compiler/$FPCC TEST_OPT=$TEST_OPT' to start "do_tests full" in test dir Unpatched i come to : ---<schnapp>--- Total = 4832 (36:4796) Total number of compilations = 2812 (21:2791) Successfully compiled = 2203 Successfully failed = 588 Compilation failures = 18 Compilation that did not fail while they should = 3 Total number of runs = 2020 (15:2005) Successful runs = 2005 Failed runs = 15 Number units compiled = 97 Number program that should not be run = 83 Number of skipped tests = 243 Number of skipped graph tests = 10 Number of skipped interactive tests = 22 Number of skipped known bug tests = 5 Number of skipped tests for other versions = 16 Number of skipped tests for other cpus = 151 Number of skipped tests for other targets = 39 ---<schnapp>--- And now patched the same: ---<patched>--- /home/daily/build/fpc/tests Total = 4832 (36:4796) Total number of compilations = 2812 (21:2791) Successfully compiled = 2203 Successfully failed = 588 Compilation failures = 18 Compilation that did not fail while they should = 3 Total number of runs = 2020 (15:2005) Successful runs = 2005 Failed runs = 15 Number units compiled = 97 Number program that should not be run = 83 Number of skipped tests = 243 Number of skipped graph tests = 10 Number of skipped interactive tests = 22 Number of skipped known bug tests = 5 Number of skipped tests for other versions = 16 Number of skipped tests for other cpus = 151 Number of skipped tests for other targets = 39 ---<patched>--- So my testing was only to check that shared libs are running is the same was then i386. Looks ok now for releasing. But i run into a other problem. I tested unpatched tree in Revision r13601 to build lazarus. ---<schnipp>--- [daily@localhost lazarus]$ make make -C lcl all make[1]: Entering directory `/home/daily/lazarus/lcl' /bin/rm -f units/x86_64-linux/alllclunits.ppu /home/daily/fpc-2.5.1/bin/ppcx64 -gl -Fu. -Funonwin32 -Fuforms -Fuwidgetset -Fu/home/daily/fpc-2.5.1/lib/fpc/2.5.1/units/x86_64-linux/rtl -Fiinclude -FE. -FUunits/x86_64-linux -Cg -dx86_64 alllclunits.pp Free Pascal Compiler version 2.5.1 [2009/09/02] for x86_64 Copyright (c) 1993-2009 by Florian Klaempfl Target OS: Linux for x86-64 Compiling alllclunits.pp Compiling graphutil.pp Compiling graphics.pp Compiling intfgraphics.pas Compiling themes.pas Compiling graphics.pp Compiling intfgraphics.pas Compiling graphics.pp canvas.inc(1436,22) Error: Call by var for arg no. 1 has to match exactly: Got "TRegion" expected "TObject" canvas.inc(1437,33) Error: Call by var for arg no. 1 has to match exactly: Got "TFPList" expected "TObject" graphics.pp(2502) Fatal: There were 2 errors compiling module, stopping Fatal: Compilation aborted make[1]: *** [alllclunits.ppu] Fehler 1 make[1]: Leaving directory `/home/daily/lazarus/lcl' make: *** [lcl] Fehler 2 ---<schnapp>--- Same with patched tree. Then i tried 2.2.4 x86_64 release without any errors. Yesterday i updated to 13637 but the error is still there. So there is something going wrong with current revision. But i think this is not part of my bug. I will going on to release patch. |
|
The lazarus errors are because your lazarus revision is too old. Those errors were fixed in Lazarus revision 20000+. Maybe you are checking out an old branch of Lazarus (use "svn info" to see which branch you have checked out). Try switching to Lazarus trunk, or the fixes_0_9_28 branch. |
|
Well, you are right. Svn trunk compiles fine. |
|
ok, lazarus is working fine. Testproject is also reduced in filesize. ---<schnipp>--- -rwxrwxr-x 1 daily daily 13874283 3. Sep 21:11 project1-shared -rwxrwxr-x 1 daily daily 15451411 3. Sep 20:48 project1-static ---<schnapp>--- :) |
|
Congratulations (again :) |
|
ok. Here is my final patch for this issue. I hope to see my work in the next upcoming release. |
2009-09-05 11:47
|
|
|
I don't know whether it will still make 2.4.0. But the one after that should be no problem. I have however a first question about your patch: diff --exclude-from=/home/daily/.excludes -Naur fpc-r13637/compiler/dbgstabs.pas fpc-r13637-pic/compiler/dbgstabs.pas --- fpc-r13637/compiler/dbgstabs.pas 2009-08-27 20:32:29.000000000 +0200 +++ fpc-r13637-pic/compiler/dbgstabs.pas 2009-08-23 18:50:58.000000000 +0200 @@ -1464,7 +1464,7 @@ current_asmdata.asmlists[al_stabs].concat(tai_symbol.Createname_global(make_mangledname('DEBUGINFO',current_module.localsymtable,''),AT_DATA,0)); end else - new_section(current_asmdata.asmlists[al_stabs],sec_code,GetSymTableName(current_module.localsymtable),0); + new_section(current_asmdata.asmlists[al_stabs],sec_data,GetSymTableName(current_module.localsymtable),0); { write all global/local variables. This will flag all required tdefs } if assigned(current_module.globalsymtable) then That change only affects Darwin targets, so I'm not sure why you made it? (and stabs works fine under Darwin, also with shared libraries) |
|
no, remove this from patch. This was for testing with other DEBUG Symbol issue. |
|
ok, i going on with milestone 2. (Making packages shared). I found out that there is only one package in packages dir that makes a real problem. The problem is that fcl-db package is a package that have only subpackages. Layout . |-- src | |-- base | |-- codegen | |-- datadict | |-- dbase | |-- export | |-- memds | |-- paradox | |-- sdf | |-- sqldb | | |-- examples | | |-- interbase | | |-- mysql | | |-- odbc | | |-- oracle | | |-- postgres | | `-- sqlite | `-- sqlite |-- tests `-- units `-- i386-linux for each subdir "make shared" is called which causes each dir to create it's own shared library with the same name (libfpfcl-db.2.5.1.so). every ppu knows that symbols should be in libfpfcl-db.2.5.1.so but only the ppu files of the last packages are in this library. I changed fpcmake not to make a shared library when [package] main=fcl-db is declared. But if [shared] libname=base is declared in Makefile.fpc, a shared library is created with compination of package name and libname. Now each subpackage habe its own library file. libfpfcl-db-base-2.5.1.so instead of libfpfcl-db-2.5.1.so. Compiling package dir gives now the following result : ---<schnipp>--- fpc libfpfcl-db-paradox-2.5.1.so libfpfv-2.5.1.so libfppcap-2.5.1.so libfpa52-2.5.1.so libfpfcl-db-sdf-2.5.1.so libfphash-2.5.1.so libfpproj4-2.5.1.so libfpaspell-2.5.1.so libfpfcl-db-sqldb-2.5.1.so libfphttpd13-2.5.1.so libfppthreads-2.5.1.so libfpcairo-2.5.1.so libfpfcl-db-sqlite-2.5.1.so libfphttpd20-2.5.1.so libfppxlib-2.5.1.so libfpcdrom-2.5.1.so libfpfcl-fpcunit-2.5.1.so libfphttpd22-2.5.1.so libfpregexpr-2.5.1.so libfpchm-2.5.1.so libfpfcl-image-2.5.1.so libfpldap-2.5.1.so libfprsvg-2.5.1.so libfpdbus-2.5.1.so libfpfcl-json-2.5.1.so libfplibxml2-2.5.1.so libfprtl-linux-2.5.1.so libfpfastcgi-2.5.1.so libfpfcl-net-2.5.1.so libfpmad-2.5.1.so libfpsdl-2.5.1.so libfpfcl-async-2.5.1.so libfpfcl-passrc-2.5.1.so libfpmodplug-2.5.1.so libfpsvgalib-2.5.1.so libfpfcl-base-2.5.1.so libfpfcl-process-2.5.1.so libfpncurses-2.5.1.so libfpsyslog-2.5.1.so libfpfcl-db-base-2.5.1.so libfpfcl-registry-2.5.1.so libfpoggvorbis-2.5.1.so libfpunixutil-2.5.1.so libfpfcl-db-codegen-2.5.1.so libfpfcl-res-2.5.1.so libfpopenal-2.5.1.so libfpunzip-2.5.1.so libfpfcl-db-datadict-2.5.1.so libfpfcl-web-2.5.1.so libfpopengl-2.5.1.so libfputmp-2.5.1.so libfpfcl-db-dbase-2.5.1.so libfpfcl-xml-2.5.1.so libfpopenssl-2.5.1.so libfpuuid-2.5.1.so libfpfcl-db-export-2.5.1.so libfpfpgtk-2.5.1.so libfppasjpeg-2.5.1.so libfpzlib-2.5.1.so libfpfcl-db-memds-2.5.1.so libfpfpmkunit-2.5.1.so libfppaszlib-2.5.1.so ---<schnapp>--- Same to rtl. New rtl package name of subpackage linux is libfprtl-linux-2.5.1.so instead of libfprtl-2.5.1.so With a few modifications i was able to compile lazarus shared. lazarus is working and ldd gives the following result: ---<schnipp>--- linux-gate.so.1 => (0x009b4000) libfprtl-linux-2.5.1.so => /home/daily/fpc-2.5.1/lib/libfprtl-linux-2.5.1.so (0x00dd6000) libfpfcl-db-base-2.5.1.so => /home/daily/fpc-2.5.1/lib/libfpfcl-db-base-2.5.1.so (0x00110000) libfpfcl-db-dbase-2.5.1.so => /home/daily/fpc-2.5.1/lib/libfpfcl-db-dbase-2.5.1.so (0x00b4f000) libfpfcl-base-2.5.1.so => /home/daily/fpc-2.5.1/lib/libfpfcl-base-2.5.1.so (0x00177000) libfpfcl-image-2.5.1.so => /home/daily/fpc-2.5.1/lib/libfpfcl-image-2.5.1.so (0x0093d000) libfppaszlib-2.5.1.so => /home/daily/fpc-2.5.1/lib/libfppaszlib-2.5.1.so (0x00a5a000) libfphash-2.5.1.so => /home/daily/fpc-2.5.1/lib/libfphash-2.5.1.so (0x00885000) libfppasjpeg-2.5.1.so => /home/daily/fpc-2.5.1/lib/libfppasjpeg-2.5.1.so (0x00204000) libX11.so.6 => /usr/lib/libX11.so.6 (0x02d3c000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x03f9b000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x046d4000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x03e73000) libgobject-2.0.so.0 => /lib/libgobject-2.0.so.0 (0x00d7e000) libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x0024a000) libgthread-2.0.so.0 => /lib/libgthread-2.0.so.0 (0x0041e000) libgmodule-2.0.so.0 => /lib/libgmodule-2.0.so.0 (0x002ea000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x03e02000) libpthread.so.0 => /lib/i686/nosegneg/libpthread.so.0 (0x00d3d000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x03f0d000) libfpcairo-2.5.1.so => /home/daily/fpc-2.5.1/lib/libfpcairo-2.5.1.so (0x00648000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0x03f2b000) libdl.so.2 => /lib/libdl.so.2 (0x00d37000) libfpfcl-xml-2.5.1.so => /home/daily/fpc-2.5.1/lib/libfpfcl-xml-2.5.1.so (0x00423000) libfpfcl-process-2.5.1.so => /home/daily/fpc-2.5.1/lib/libfpfcl-process-2.5.1.so (0x002ed000) libfpfcl-registry-2.5.1.so => /home/daily/fpc-2.5.1/lib/libfpfcl-registry-2.5.1.so (0x003c1000) libc.so.6 => /lib/i686/nosegneg/libc.so.6 (0x004ed000) libncurses.so.5 => /usr/lib/libncurses.so.5 (0x0035a000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x03d4f000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x036c3000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00dbf000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00d76000) libm.so.6 => /lib/i686/nosegneg/libm.so.6 (0x00d0e000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x03f02000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x03dd1000) libXext.so.6 => /usr/lib/libXext.so.6 (0x00dc4000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0x0031b000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x0032d000) libXi.so.6 => /usr/lib/libXi.so.6 (0x00332000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x03402000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x03033000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00326000) librt.so.1 => /lib/i686/nosegneg/librt.so.1 (0x00d56000) /lib/ld-linux.so.2 (0x0033e000) libz.so.1 => /usr/lib/libz.so.1 (0x00d61000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x003ce000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x03e43000) libexpat.so.0 => /lib/libexpat.so.0 (0x003f4000) ---<schnapp>--- Looks like lcl and gtk2 packages currently are not designed create a shared library. So the file sized on shared compiled X11 programs are not reduced so high. if you think that this could be a solution for my subpackage problem i will provide a patch for that. |
2009-09-08 20:46
|
|
|
I have uploaded a new archive that also enable shared package building. Feel free to play around with it. The second patch should only show that it work's. For enable shared packages building by default i currently would say it is not stable enough. Some package need to be refinded in structure. For example interbase package. Dynamic loading unit and static linked units are put together. |
Date Modified | Username | Field | Change |
---|---|---|---|
2008-10-26 18:26 | Pierre Pede | New Issue | |
2009-05-26 11:53 | Jonas Maebe | Relationship added | parent of 0013829 |
2009-06-01 18:15 | Pierre Pede | Note Added: 0028212 | |
2009-06-01 18:16 | Pierre Pede | Note Edited: 0028212 | |
2009-06-01 18:17 | Pierre Pede | Note Edited: 0028212 | |
2009-06-01 18:18 | Pierre Pede | Note Edited: 0028212 | |
2009-06-02 21:04 | Pierre Pede | Note Added: 0028237 | |
2009-06-03 11:45 | Jonas Maebe | Note Added: 0028250 | |
2009-06-04 21:15 | Pierre Pede | Note Added: 0028293 | |
2009-06-05 16:32 | Jonas Maebe | Note Added: 0028308 | |
2009-06-06 13:40 | Jonas Maebe | Note Edited: 0028308 | |
2009-06-12 21:18 | Pierre Pede | Note Added: 0028505 | |
2009-06-12 21:20 | Pierre Pede | Note Edited: 0028505 | |
2009-06-13 11:06 | Jonas Maebe | Note Added: 0028515 | |
2009-06-22 23:03 | Florian | Note Added: 0028687 | |
2009-06-27 10:39 | Pierre Pede | Note Added: 0028786 | |
2009-06-30 01:07 | Pierre Pede | File Added: patch-13198-pic.tar.bz2 | |
2009-06-30 01:09 | Pierre Pede | Note Added: 0028867 | |
2009-07-01 22:34 | Pierre Pede | File Added: fpc-13198-pic-ppumove.patch | |
2009-07-05 19:43 | Florian | Note Added: 0028930 | |
2009-07-05 20:01 | Jonas Maebe | Note Added: 0028932 | |
2009-07-13 22:29 | Pierre Pede | Note Added: 0029081 | |
2009-07-13 22:31 | Pierre Pede | Note Edited: 0029081 | |
2009-07-13 22:34 | Pierre Pede | Note Edited: 0029081 | |
2009-07-14 09:46 | Jonas Maebe | Note Added: 0029088 | |
2009-07-14 23:22 | Pierre Pede | Note Added: 0029104 | |
2009-07-15 18:10 | Jonas Maebe | Note Added: 0029112 | |
2009-07-17 16:18 | Jonas Maebe | Relationship added | related to 0008119 |
2009-07-21 23:41 | Pierre Pede | Note Added: 0029202 | |
2009-07-21 23:41 | Pierre Pede | Note Edited: 0029202 | |
2009-07-21 23:42 | Pierre Pede | Note Edited: 0029202 | |
2009-07-22 22:33 | Pierre Pede | Note Added: 0029213 | |
2009-07-25 16:37 | Pierre Pede | Note Edited: 0029213 | |
2009-08-03 22:49 | Pierre Pede | Note Added: 0029508 | |
2009-08-04 10:28 | Marco van de Voort | Note Added: 0029514 | |
2009-08-04 21:54 | Pierre Pede | Note Added: 0029536 | |
2009-08-04 22:36 | Pierre Pede | Note Edited: 0029536 | |
2009-08-22 20:16 | Pierre Pede | Note Added: 0030081 | |
2009-08-22 21:03 | Jonas Maebe | Note Added: 0030082 | |
2009-08-26 21:33 | Pierre Pede | Note Added: 0030185 | |
2009-08-26 21:35 | Pierre Pede | Note Edited: 0030185 | |
2009-08-31 21:37 | Pierre Pede | Note Added: 0030275 | |
2009-08-31 21:38 | Pierre Pede | Note Edited: 0030275 | |
2009-08-31 22:28 | Jonas Maebe | Note Added: 0030276 | |
2009-08-31 23:02 | Pierre Pede | Note Added: 0030277 | |
2009-08-31 23:09 | Jonas Maebe | Note Added: 0030278 | |
2009-08-31 23:24 | Pierre Pede | Note Added: 0030279 | |
2009-08-31 23:44 | Pierre Pede | Note Added: 0030280 | |
2009-09-01 22:36 | Pierre Pede | Note Added: 0030299 | |
2009-09-01 22:37 | Pierre Pede | Note Edited: 0030299 | |
2009-09-01 22:47 | Pierre Pede | Note Added: 0030302 | |
2009-09-02 18:03 | Jonas Maebe | Note Added: 0030334 | |
2009-09-03 09:34 | Pierre Pede | Note Added: 0030356 | |
2009-09-03 09:35 | Pierre Pede | Note Edited: 0030356 | |
2009-09-03 09:52 | Jonas Maebe | Note Added: 0030357 | |
2009-09-03 20:40 | Pierre Pede | Note Added: 0030382 | |
2009-09-03 21:15 | Pierre Pede | Note Added: 0030383 | |
2009-09-03 23:46 | Jonas Maebe | Note Added: 0030386 | |
2009-09-05 11:47 | Pierre Pede | Note Added: 0030442 | |
2009-09-05 11:47 | Pierre Pede | File Added: fpc-r13637-pic-final.tgz | |
2009-09-07 21:37 | Jonas Maebe | Note Added: 0030520 | |
2009-09-07 21:54 | Pierre Pede | Note Added: 0030521 | |
2009-09-07 23:36 | Pierre Pede | Note Added: 0030524 | |
2009-09-08 20:46 | Pierre Pede | File Added: fpc-r13637-pic-final-with-packages.tgz | |
2009-09-08 20:48 | Pierre Pede | Note Added: 0030548 | |
2009-09-08 21:50 | Pierre Pede | Note Edited: 0030548 | |
2009-09-12 21:55 | Jonas Maebe | Status | new => assigned |
2009-09-12 21:55 | Jonas Maebe | Assigned To | => Jonas Maebe |
2009-09-13 00:00 | Jonas Maebe | FPCOldBugId | => 0 |
2009-09-13 00:00 | Jonas Maebe | Fixed in Revision | => 13672,13703 |
2009-11-01 17:55 | Jonas Maebe | Relationship added | parent of 0014958 |
2009-11-11 21:42 | Marco van de Voort | Tag Attached: shared | |
2009-11-11 21:46 | Marco van de Voort | Tag Attached: dynamic library | |
2009-11-24 18:22 | Jonas Maebe | Relationship added | related to 0015175 |