[fpc-devel] FPC dynamic libraries

2007-02-07 Thread Mattias Gaertner

How can I create dynamic libs of the RTL and FCL units under Linux?


Mattias

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC dynamic libraries

2007-02-07 Thread Jonas Maebe


On 07 Feb 2007, at 19:51, Mattias Gaertner wrote:


How can I create dynamic libs of the RTL and FCL units under Linux?


In principle you should be able to do it with make shared in the  
respective directories. But I would strongly recommend against doing  
that, since the interface is by no means stable and consequently  
programs compiled against both newer and older rtl/fcl's are very  
likely to break if they use a different rtl (and possibly fcl, since  
the fcl also uses rtl functionality).



Jonas

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Patch for Symbian OS

2007-02-07 Thread Florian Klaempfl

Felipe Monteiro de Carvalho schrieb:

Hello,

The attached patch adds a internal linker for symbian os. Also the
makefile on rtl/symbian needs to be regenerated

I also added many files to rtl/symbian included attached

This is enougth to compile a empty executable, but it won´t run or do 
anything.




Thanks, applied.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC dynamic libraries

2007-02-07 Thread Mattias Gaertner
On Wed, 7 Feb 2007 20:00:20 +0100
Jonas Maebe [EMAIL PROTECTED] wrote:

 
 On 07 Feb 2007, at 19:51, Mattias Gaertner wrote:
 
  How can I create dynamic libs of the RTL and FCL units under Linux?
 
 In principle you should be able to do it with make shared in the  
 respective directories. But I would strongly recommend against doing  
 that, since the interface is by no means stable and consequently  
 programs compiled against both newer and older rtl/fcl's are very  
 likely to break if they use a different rtl (and possibly fcl, since  
 the fcl also uses rtl functionality).

That's a general problem with libs, isn't it?
We need a version system.


Mattias
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC dynamic libraries

2007-02-07 Thread Jonas Maebe


On 07 Feb 2007, at 21:45, Mattias Gaertner wrote:


In principle you should be able to do it with make shared in the
respective directories. But I would strongly recommend against doing
that, since the interface is by no means stable and consequently
programs compiled against both newer and older rtl/fcl's are very
likely to break if they use a different rtl (and possibly fcl, since
the fcl also uses rtl functionality).


That's a general problem with libs, isn't it?


Yes, but especially with libraries where the developers have not  
committed to maintaining backwards compatibility with a particular  
interface and which are often changed in an ad hoc fashion. The main  
problem is probably that we mix both general and compiler-specific  
stuff in the system unit. It should probably be split into something  
like gcc's libgcc.a (which contains compiler-specific helper  
routines) and the system's libc dynamic library (system and generic C  
language support) before the rtl is ever distributed as a shared  
library.



We need a version system.


That's not something we need, but which most OS'es need (and don't  
provide, except for hacks like symlinks or different filenames).  
Moreover, it doesn't really solve much unless you like having 20  
different versions of the same shared library on your system (which  
would more or less defeat the purpose of saving space, although it  
could still save memory if more than one FPC program is running at  
the same time).


What problem do you want to solve with having a shared library? The  
complaint that Lazarus programs are too large? Personally, I think  
switching to shared libraries will at this time introduce a lot more  
complaints that it will solve (and not because of a lack of a  
versioning system, but simply because the interface isn't anywhere  
near stable enough imho).



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] [PATCH] fpcmmain.pp: fixed FPCDIR detection on x86_64

2007-02-07 Thread Florian Klaempfl

Alexey Tourbin schrieb:


Shouldn't we simply change the ppc386 into fpc ?


---
 fpcmmain.pp |   15 +++
 1 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/fpcmmain.pp b/fpcmmain.pp
index 9a1dd3a..a2a9a90 100644
--- a/fpcmmain.pp
+++ b/fpcmmain.pp
@@ -1146,6 +1146,13 @@ implementation
 
 
 procedure TFPCMake.AddFPCDefaultVariables;

+  const
+ppc =
+{$ifdef cpux86_64}
+  'ppcx64';
+{$else}
+  'ppc386';
+{$endif}
   var
 hs,s : string;
   begin
@@ -1182,9 +1189,9 @@ implementation
  begin
 {$ifdef UNIX}
 {$ifndef NO_UNIX_UNIT}
-   if FileExists('/usr/local/bin/ppc386') then
+   if FileExists('/usr/local/bin/'+ppc) then
 begin
-  s:=ExtractFilePath({$ifdef 
ver1_0}ReadLink{$else}fpReadlink{$endif}('/usr/local/bin/ppc386'));
+  s:=ExtractFilePath({$ifdef 
ver1_0}ReadLink{$else}fpReadlink{$endif}('/usr/local/bin/'+ppc));
   if s'' then
begin
  if s[length(s)]='/' then
@@ -1194,9 +1201,9 @@ implementation
 end;
if hs='' then
 begin
-  if FileExists('/usr/bin/ppc386') then
+  if FileExists('/usr/bin/'+ppc) then
begin
- s:=ExtractFilePath({$ifdef 
ver1_0}ReadLink{$else}fpReadLink{$endif}('/usr/bin/ppc386'));
+ s:=ExtractFilePath({$ifdef 
ver1_0}ReadLink{$else}fpReadLink{$endif}('/usr/bin/'+ppc));
  if s'' then
   begin
 if s[length(s)]='/' then


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


RE: [fpc-devel] FPC dynamic libraries

2007-02-07 Thread George Birbilis
  We need a version system.
 
 That's not something we need, but which most OS'es need 
 (and don't provide, except for hacks like symlinks or 
 different filenames).  
 Moreover, it doesn't really solve much unless you like having 
 20 different versions of the same shared library on your 
 system (which would more or less defeat the purpose of saving 
 space, although it could still save memory if more than one 
 FPC program is running at the same time).

If I understand well what you mean, Vista has versioning of that kind, you
can ask to see older versions of any file and restore the one you want. A
small caveat is that for files that don't exist currently anymore (deleted)
there's no GUI to get them (or one I haven't spotted yet) and you need to
make a dummy file with same name, then right click it and go to Properties,
then ask for the older versions (there's a special tab for that on the
dialog). Not sure if the Basic version of Vista has this functionality
available (I tried it with Vista Ultimate)


George Birbilis ([EMAIL PROTECTED])
Computer  Informatics Engineer
Microsoft MVP J# for 2004-2007
Borland Spirit of Delphi
3D, QuickTime, QTVR, Java, Delphi,
ActiveX, .NET components, Robotics
http://www.kagi.com/birbilis
http://birbilis.spaces.live.com

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


RE: [fpc-devel] FPC dynamic libraries

2007-02-07 Thread George Birbilis
   We need a version system.
  
  That's not something we need, but which most OS'es need 
 (and don't 
  provide, except for hacks like symlinks or different filenames).
  Moreover, it doesn't really solve much unless you like having 20 
  different versions of the same shared library on your system (which 
  would more or less defeat the purpose of saving space, although it 
  could still save memory if more than one FPC program is 
 running at the 
  same time).
 
 If I understand well what you mean, Vista has versioning of 
 that kind, you can ask to see older versions of any file and 
 restore the one you want. A small caveat is that for files 
 that don't exist currently anymore (deleted) there's no GUI 
 to get them (or one I haven't spotted yet) and you need to 
 make a dummy file with same name, then right click it and go 
 to Properties, then ask for the older versions (there's a 
 special tab for that on the dialog). Not sure if the Basic 
 version of Vista has this functionality available (I tried it 
 with Vista Ultimate)

If you meant having many libs of different version exist side-by-side, .NET
runtime supports it, but Win32 itself doesn't

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


RE: [fpc-devel] FPC dynamic libraries

2007-02-07 Thread Michael Van Canneyt


On Thu, 8 Feb 2007, George Birbilis wrote:

We need a version system.
   
   That's not something we need, but which most OS'es need 
  (and don't 
   provide, except for hacks like symlinks or different filenames).
   Moreover, it doesn't really solve much unless you like having 20 
   different versions of the same shared library on your system (which 
   would more or less defeat the purpose of saving space, although it 
   could still save memory if more than one FPC program is 
  running at the 
   same time).
  
  If I understand well what you mean, Vista has versioning of 
  that kind, you can ask to see older versions of any file and 
  restore the one you want. A small caveat is that for files 
  that don't exist currently anymore (deleted) there's no GUI 
  to get them (or one I haven't spotted yet) and you need to 
  make a dummy file with same name, then right click it and go 
  to Properties, then ask for the older versions (there's a 
  special tab for that on the dialog). Not sure if the Basic 
  version of Vista has this functionality available (I tried it 
  with Vista Ultimate)
 
 If you meant having many libs of different version exist side-by-side, .NET
 runtime supports it, but Win32 itself doesn't

Most unixes also have it. The point is that it kind of defeats the purpose.
Having 20+ libraries called fpcrtl-xyz.dll (or fpcrtl.so.x.y.z on unixes)
defeats the purpose of a shared library: saving disk and (more importantly)
memory space by factoring out common code. 

If we'd know that the fpcrtl.so (or .dll) interface will stay the same in the 
next 5 years, it makes sense to distribute this. Since the interface changes
still wildly, it's a bad idea.

Look at Delphi packages: as soon as the interface of a package changes,
you must re-compile all the binaries that use it. The same would be true 
for FPC. I can assure you this is a major headache when distributing apps.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel