Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
> Just a binary distribution right? I did not see the sources in ports, > which would have to be patched to fix the lib naming errors. Yes but one guy said he's working on source based one. > Are you saying that code produced by this Lazarus/FPC setup will not run > properly on older freebsd systems? Yes > > Seems to me that FPC-2.0.2 is broken as far as freebsd is concerned. It > can't be just lazarus which needs those libs properly defined; so what > we have here is essentially a bug fix to FPC itself. Seems to me that FreeBSD is broken as far as everything which uses those libnames... it's not only fpc problem. Old binaries won't work on new freeBSD and vice versa. It's their idiocy not our, we didn't rename those libs 2x. You don't have a bugfix, you can't ifdef ports version. It doesn't depend on OS version of FreeBSD but on the fact that the person has new ports or not. If someone on 6.0 updates his ports he'll have the new "-" version of glib and others. Same for 5.4. > I don't understand, why not just fix the missing "-" in the IFDEF > FreeBSD statement, and produce a working FPC? See above. > > Bob Your signature is broken. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] errore.msg changes
Hi, errore.msg keep on changing (and that's a good thing). The problem is that the people who translate it to other languages should be notified about any changes, so we could add them to the translated version as well, instead of diffing the errore.msg to with our copy ... So I have a request to be notified when such changes happens, so I could add this changes in order to update the translated version. I'm guessing that other translators would like to know that as well. Thanks, Ido ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
> Greetings to the Fpc-Devel list: > > the following libraries were not found by ld: glib12, gdk12, and gtk12. This is a know issue without good solution, since the problem originates in the FreeBSD ports management. The best solution is: - for 2.0.2 manually create relevant symlinks to the libs. - for 2.0.4, use linkaliasing > Funny! I moved away from Linux mainly because of Library-Hell issues :-) Me too. I really hate the mentality behind this change. It made me reconsider my stance on ports tree usage of FPC. (read: give it up) (from a mail to sb else explaining this, I'll be adding this to the wiki today in a modded form): What happens is that all xxx12 libs were renamed to xxx-12 (note that this is STILL different from conventional xxx-1.2) FreeBSD Ports put this change silently in a doc in nov 2005, and removed the old names in feb 2006 in -STABLE, and refuses to fix the port with a symlink and thus have a longer grace period. The only way you can know, inside the port building, is to test what name of gtk lib exists (libgtk12 or libgtk-1.2, same for gdk12 and glib12). THE CHANGE DOESN'T FOLLOW ANYT VERSION LINES IF YOU TRACK -STABLE. They refer to pkgconfig or keep on using the -RELEASE ports branch (which is security only), Of course I can't take a tool that emits gcc parametes seriously (since some ad hoc parsing will probably break on the first gcc change). So I consider calling pkgconfig/gtkconfig a way to fragile solution long term, I decided to solve it differently, and have some form of config options for them. This because FPC wasn't entirely innocent too, in that library names in sourcecode ($LINKLIB xxx) couldn't be changed after compilation, this is now fixed in 2.0.4. The 2.0.4 sourcecode defaults to the new library naming. If you install FPC on a system with gtk compiled from the pre februari portstree (like a stock 6.0 release), you need to add -XLAglib-12=glib12 -XLAgdk-12=gdk12 -XLAgtk-12=gtk12 to the 2.0.4 fpc.cfg It is also the most neutral choice. People that disagree with me can try to hack up something to query pkgconfig and install that into fpc.cfg, without risking breakage of the compiler due to some pkgconfig problem. Note that the a 2.0.4 FreeBSD rc2 will become available today for testing. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
Aleš Katona wrote: > Hi Bob and welcome to the world of crap. > > Seriously and honestly, the FreeBSD porters made a big bad pile of crap > when they some years ago decided to name "gtk-12" and others as "gtk12". > > Welcome to the world of shit.. eh sorry I ment unix. > > It was written in C what would you expect? This is not a C based problem, you can do the same thing using FPC, but only few people make libraries with FPC in the first place. This issue is a typical source-based distribution problem, because when you recompile everything from scratch every day (or, often) anyway, you can change a whole lot more without breaking things than if you need to keep binary packages in sync with each other. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Win32 API call GetSystemInfo in {$Mode Delphi} fails
Hi,
The win32 API call, GetStartupInfo() fails under FPC with {$Mode
Delphi} and no preceding @ sign in the parameter. Under Delphi 7 you
can call GetStartupInfo as show below.
-- Delphi [System.pas]
procedure GetStartupInfo(var lpStartupInfo: TStartupInfo); stdcall;
external kernel name 'GetStartupInfoA';
example of usage:
function GetCmdShow: Integer;
var
SI: TStartupInfo;
begin
Result := 10;
GetStartupInfo(SI);
if SI.dwFlags and 1 <> 0 then
Result := SI.wShowWindow;
end;
--- FPC [ascfun.inc] --
procedure GetStartupInfo(lpStartupInfo:LPSTARTUPINFO); external
'kernel32' name 'GetStartupInfoW';
Under FPC it must be called as follows, it DELPHI mode or ObjFPC mode.
[ ... ]
GetStartupInfo(@startupinfo);
[ ... ]
Under FPC the GetStartupInfo parameter is defined differently to
Delphi. Is this a bug in FPC?
Regards,
Graeme.
--
There's no place like 127.0.0.1
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
> Ale? Katona wrote: > > Hi Bob and welcome to the world of crap. > > > > Seriously and honestly, the FreeBSD porters made a big bad pile of crap > > when they some years ago decided to name "gtk-12" and others as "gtk12". > > > > Welcome to the world of shit.. eh sorry I ment unix. > > > > It was written in C what would you expect? > > This is not a C based problem, you can do the same thing using FPC, but > only few people make libraries with FPC in the first place. > > This issue is a typical source-based distribution problem, because when > you recompile everything from scratch every day (or, often) anyway, you > can change a whole lot more without breaking things than if you need to > keep binary packages in sync with each other. This has nothing to do with source based vs binary. If e.g. debian renamed libs tomorrow inside a branch, it would have the same effect. Note that the problems are the same in FreeBSD, source based or not. It is simply bad release management. Probably they want to keep this 5.x and 6.x compat and feel that the hard way will convert most installations quickly. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] errore.msg changes
ik wrote: Hi Ido, > errore.msg keep on changing (and that's a good thing). The problem is > that the people who translate it to other languages should be notified > about any changes, so we could add them to the translated version as > well, instead of diffing the errore.msg to with our copy ... > > So I have a request to be notified when such changes happens, so I > could add this changes in order to update the translated version. > > I'm guessing that other translators would like to know that as well. You're right, we need to have a look at it, at least for people working directly on the level of files in SVN. Those working with the online translation tool wouldn't be able to use this information immediately at the moment due to limitations of that tool (or its current setup at least). I'd suggest the following: 1) Create a new mailing list for that purpose. 2) Prepare some automated routine sending diffs for new revisions directly to this list. In theory, this could be done two ways - either in batch mode by checking differences for e.g. the last day (or that one when the script ran last time), or using post-commit trigger in SVN. I guess that the former might be easier to maintain (although possibly somewhat more complex to prepare), but this needs to be assessed by people taking care about our SVN server. Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On Mon, 17 Jul 2006, Marco van de Voort wrote: Greetings to the Fpc-Devel list: the following libraries were not found by ld: glib12, gdk12, and gtk12. This is a know issue without good solution, since the problem originates in the FreeBSD ports management. The best solution is: - for 2.0.2 manually create relevant symlinks to the libs. - for 2.0.4, use linkaliasing Funny! I moved away from Linux mainly because of Library-Hell issues :-) Library hell exists on all platforms. Running from it is futile. Maybe the maintainers of one platform/OS distribution do slightly better than the others, but in essence the problem always exists. Even on Windows, where there is only 1 manufacturer, the problem exists. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On Mon, Jul 17, 2006 at 10:50:33AM +0200, Michael Van Canneyt wrote: > >- for 2.0.2 manually create relevant symlinks to the libs. > >- for 2.0.4, use linkaliasing > > > >>Funny! I moved away from Linux mainly because of Library-Hell issues :-) > > Library hell exists on all platforms. Running from it is futile. It is not a purely qualitative thing. You can try to minimize it. All distro's do this to some extend. > Maybe the maintainers of one platform/OS distribution do slightly better > than the others, but in essence the problem always exists. > > Even on Windows, where there is only 1 manufacturer, the problem exists. Windows native misses any library versioning, which is why it is quite notorious. .NET has quit elaborate library (assembly) versioning, but rumours are that the constant security patches can cause problems too. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Win32 API call GetSystemInfo in {$Mode Delphi} fails
> The win32 API call, GetStartupInfo() fails under FPC with {$Mode
> Delphi} and no preceding @ sign in the parameter. Under Delphi 7 you
> can call GetStartupInfo as show below.
Fixed in trunk. r4238 in case sb wants to merge it.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Win32 API call GetSystemInfo in {$Mode Delphi} fails
On 7/17/06, Marco van de Voort <[EMAIL PROTECTED]> wrote: Fixed in trunk. r4238 in case sb wants to merge it. Damn that was quick! Thanks. Graeme. -- There's no place like 127.0.0.1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On 17 Jul 2006, at 10:04, Marco van de Voort wrote: They refer to pkgconfig or keep on using the -RELEASE ports branch (which is security only), Of course I can't take a tool that emits gcc parametes seriously (since some ad hoc parsing will probably break on the first gcc change). It generates ld parameters, not gcc parameters. So you don't have to parse them unless you want to use an internal linker. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
Marco van de Voort wrote: > This has nothing to do with source based vs binary. If e.g. debian renamed > libs tomorrow inside a branch, it would have the same effect. They can't do that without breaking all other packages in the archive using this package. They don't get rebuilt automatically AFAIK, and that's where the difference is IMHO. Furthermore it's policy to change the name of the package when the ABI changes, but that's also what you said: kind of release management. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 2.0.4 release candidate 1 testing
Just a little suggestion... I think we should inform any progress of FPC development on the website. Maybe this has been informed through the Wiki, but I believe not every visitor have time to look at the Wiki. Just like what Firebird project does, they inform every RC on the website. Just my 2 cents. :) -Bee- has Bee.ography at: http://beeography.wordpress.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On Mon, Jul 17, 2006 at 11:21:36AM +0200, Micha Nelissen wrote: > Marco van de Voort wrote: > > This has nothing to do with source based vs binary. If e.g. debian renamed > > libs tomorrow inside a branch, it would have the same effect. > > They can't do that without breaking all other packages in the archive > using this package. They don't get rebuilt automatically AFAIK, and > that's where the difference is IMHO. I don't understand this. Afaik there is no difference at all. Could you be more elaborate in what you think would go wrong automatically? > Furthermore it's policy to change the name of the package when the ABI > changes, but that's also what you said: kind of release management. Same also. The problem is that this is the exception where they didn't. I suspect they simply didn't want to wait till after 6.x, and wanted to keep 5.x-6.x congruency. (if 5.x implements this change at all). There is also the matter of -RELEASE vs -STABLE, a principle that is hard to explain, since other distro's don't implement it; see it like this: a series of releases becomes STABLE when the generic advise changed to target that series as stable. x.0 versions are typically never stable (the first 4.x stable was 4.4 the first 5.x was 5.3) If they changed it only for 6.x, they might consider it minor because it is affects non-upgraded 6.0 only, and before the -STABLE moniker is applied to 6.x. However the difference is that 6.0 is (due to the large compability of 6.x to 5.x, and its stability) way more widely used for serious work than the avg FreeBSD x.0 release. (people were generally afraid of 5.0-DP, and right so :-)) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] fpc 2.0.4 rc2 and mse
Hi, MSE created some patches for fpc 2.0.4 rc1 to fix some widestring and db issues. http://svn.sourceforge.net/viewcvs.cgi/mseide-msegui/trunk/patch_fpc_2_0_4/ I seems they are not applied to rc2. Can someone with widestring and db knowledge of fpc dev take a look at this? It would be nice that for mse/fpc we do not need to apply patches to release 2.0.4 to be able to use mse. thx in advance, Den Jean ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc 2.0.4 rc2 and mse
Den Jean wrote: > Hi, > > MSE created some patches for fpc 2.0.4 rc1 > to fix some widestring and db issues. > http://svn.sourceforge.net/viewcvs.cgi/mseide-msegui/trunk/patch_fpc_2_0_4/ > > I seems they are not applied to rc2. > > Can someone with widestring and db knowledge > of fpc dev take a look at this? > > It would be nice that for mse/fpc we do not > need to apply patches to release 2.0.4 to be able > to use mse. Partly, however, e.g. the cwstring change discussion was started but no conclusion was drawn. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On Mon, Jul 17, 2006 at 11:19:22AM +0200, Jonas Maebe wrote: > > > They refer > >to pkgconfig or keep on using the -RELEASE ports branch (which is > >security > >only), > > > >Of course I can't take a tool that emits gcc parametes seriously > >(since > >some ad hoc parsing will probably break on the first gcc change). > > It generates ld parameters, not gcc parameters. So you don't have to > parse them unless you want to use an internal linker. Thnks, will improve the text for the wiki. Not that it changes much, don't like an external called from the compiler. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On 17 Jul 2006, at 11:59, Marco van de Voort wrote: It generates ld parameters, not gcc parameters. So you don't have to parse them unless you want to use an internal linker. Thnks, will improve the text for the wiki. Not that it changes much, don't like an external called from the compiler. There is no other way to properly support linking to external libraries, unless you use something like Mac OS X' frameworks (which does support transparent versioning and multi-version support, including name changes of individual libraries part of a framework even if they represent the same library version if you'd feel inclined to do that). That doesn't mean Mac OS X doesn't potentially have the same library problems though, since most open source based libraries are not distributed as a framework. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
Op Mon, 17 Jul 2006, schreef Jonas Maebe: > There is no other way to properly support linking to external libraries, > unless you use something like Mac OS X' frameworks (which does support > transparent versioning and multi-version support, including name changes of > individual libraries part of a framework even if they represent the same > library version if you'd feel inclined to do that). > > That doesn't mean Mac OS X doesn't potentially have the same library problems > though, since most open source based libraries are not distributed as a > framework. IMHO crap like *_config are only tricks used by C people used to work around defficiencies in their toolchains. There simply should be no reason why you want such complexity. A library has a name, you link to it by name, basta. If people start renaming libraries we make us resistant to library name changes. Otherwise the compiler needs to support a_config for library x and b_config for package and the end is loose. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc 2.0.4 rc2 and mse
Den Jean wrote: Hi, > MSE created some patches for fpc 2.0.4 rc1 > to fix some widestring and db issues. > http://svn.sourceforge.net/viewcvs.cgi/mseide-msegui/trunk/patch_fpc_2_0_4/ > > I seems they are not applied to rc2. . . Thanks for this information. There's been no decision made in the core team that they should / need to be included for 2.0.4 so far, nor were they submitted as issues with 2.0.4-rc1 officially (I haven't been aware of them at all personally). As a general statement (without having looked at them in detail), we need to consider their importance and associated risks carefully. Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On 17 Jul 2006, at 12:21, Daniël Mantione wrote: That doesn't mean Mac OS X doesn't potentially have the same library problems though, since most open source based libraries are not distributed as a framework. IMHO crap like *_config are only tricks used by C people used to work around defficiencies in their toolchains. There's nothing C-specific about libraries, nor about the *config scripts. At most it would be linker-specific. There simply should be no reason why you want such complexity. A library has a name, you link to it by name, basta. A library also exist in at least multiple locations, versions (both ABI-compatible and -incompatible with previous versions) and implementations (e.g. a native Mac OS X GTK and an X-based one). You can of course give everything a different name (which is what often happens in practice), but that doesn't work all that well as demonstrated by everyone's experience. If people start renaming libraries we make us resistant to library name changes. Otherwise the compiler needs to support a_config for library x and b_config for package and the end is loose. The whole point of the *config stuff is exactly to be resistant against that. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On 17 Jul 2006, at 12:33, Jonas Maebe wrote: There simply should be no reason why you want such complexity. A library has a name, you link to it by name, basta. A library can also exist in at least multiple locations, versions (both ABI- compatible and -incompatible with previous versions) and implementations (e.g. a native Mac OS X GTK and an X-based one). If people start renaming libraries we make us resistant to library name changes. Otherwise the compiler needs to support a_config for library x and b_config for package and the end is loose. The whole point of the *config stuff is exactly to be resistant against that. Against name changes of course. Supporting the multiple *config stuff could happen via a linklib-like statement in the unit sources. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc 2.0.4 rc2 and mse
On Mon, 17 Jul 2006, Den Jean wrote: Hi, MSE created some patches for fpc 2.0.4 rc1 to fix some widestring and db issues. http://svn.sourceforge.net/viewcvs.cgi/mseide-msegui/trunk/patch_fpc_2_0_4/ I seems they are not applied to rc2. Can someone with widestring and db knowledge of fpc dev take a look at this? It would be nice that for mse/fpc we do not need to apply patches to release 2.0.4 to be able to use mse. Can you send the RTL/FCL patches to me so I can have a look at it ? I tried to view them with the viewcvs, but when I request a diff, the script fails. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
Bob wrote: > Funny! I moved away from Linux mainly because of Library-Hell issues :-) You've to move away from unix then :) I made similiar experiences when porting FPC to Solaris. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On Mon, Jul 17, 2006 at 12:16:10PM +0200, Jonas Maebe wrote: > > There is no other way to properly support linking to external > libraries, unless you use something like Mac OS X' frameworks (which > does support transparent versioning and multi-version support, > including name changes of individual libraries part of a framework > even if they represent the same library version if you'd feel > inclined to do that). That's not the point. The point is that I consider a solution, that tries to collect this data automatically, worse than the current situation. IOW I consider this cure to be worse (more likely to break a release systematically and harder to support due to a lack of transparancy to end users) than the problem, specially since now we don't have to recompile FPC anymore for a lib change. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
Marco van de Voort wrote: >> They can't do that without breaking all other packages in the archive >> using this package. They don't get rebuilt automatically AFAIK, and >> that's where the difference is IMHO. > > I don't understand this. Afaik there is no difference at all. Could you be > more elaborate in what you think would go wrong automatically? My view of source based distributions (in the general software sense) is that when a package maintainer uploads a new library version (changing the library name correctly according to that distro's packaging rules) then all dependent software is automatically recompiled for the new version (and name), and thus no one notices any breakages. Except 3rd parties like us. For a binary distribution like debian, if a package maintainer uploads a (binary) package with different containing library name, bug reports will be compiled due to other packages being broken now. This package thus cannot transition to the 'testing' (RC) debian distribution, and the only possible fix is to revert the package name to the old one. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On 17 Jul 2006, at 13:42, Marco van de Voort wrote: That's not the point. The point is that I consider a solution, that tries to collect this data automatically, worse than the current situation. There's no reason why a default fallback to the current system couldn't be supported. IOW I consider this cure to be worse (more likely to break a release systematically and harder to support due to a lack of transparancy to end users) than the problem, I cannot see how this is more likely to break a release systematically. And it's only as intransparent as we make it (e.g., apart from the "compiling", "assembling" and "linking", there could just as well be a "Determining needed libraries using gtk-config..." message) specially since now we don't have to recompile FPC anymore for a lib change. I do not understand this last part. Are you talking about dynamically loading libraries at run time or so? Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Xft support for FPC
Hi, Does FPC have the headers converted for Xft support under *nix systems? I couldn't find it, so created a unit that uses Xft it my freepascal apps. Could I create a patch and send it to the mailing list to apply to FPC? If it is ok, where should in live? /src/packages/extra/xft ? Regards, Graeme. -- There's no place like 127.0.0.1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
Op Mon, 17 Jul 2006, schreef Jonas Maebe: > There's nothing C-specific about libraries, nor about the *config scripts. At > most it would be linker-specific. There is, those scripts mainly exist because a C compiler cannot determine the dependencies of a library. I.e. if you like libgtk you must also link libglib. We don't need this in Pascal, the compiler can perfectly determine the dependencies by checking the used units. So the primary reason for this cruft is void in Pascal. > > There simply should be no reason > > why you want such complexity. A library has a name, you link to it by > > name, basta. > > A library also exist in at least multiple locations, versions (both > ABI-compatible and -incompatible with previous versions) and implementations > (e.g. a native Mac OS X GTK and an X-based one). I don't see how *_config guards you against this: * In case of a version change it will simply return the new version. The .so symlink does this as well. If the new version is incompatible with the old one, bad luck. * It doesn't guard you against ABI changes, because that it determined at the compiler level. I.e. there is no way to make cdecl code using a register calling convention by using a linker option. It helps for locations, but we already have a well adequate solution for that: Putting the location in fpc.cfg. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On 17 Jul 2006, at 14:03, Daniël Mantione wrote: There's nothing C-specific about libraries, nor about the *config scripts. At most it would be linker-specific. There is, those scripts mainly exist because a C compiler cannot determine the dependencies of a library. I.e. if you like libgtk you must also link libglib. We don't need this in Pascal, the compiler can perfectly determine the dependencies by checking the used units. So the primary reason for this cruft is void in Pascal. You could support exactly the same in C with some #pragma statements in the header files. This is implementation-specific rather than language specific. A library also exist in at least multiple locations, versions (both ABI-compatible and -incompatible with previous versions) and implementations (e.g. a native Mac OS X GTK and an X-based one). I don't see how *_config guards you against this: * In case of a version change it will simply return the new version. The .so symlink does this as well. If the new version is incompatible with the old one, bad luck. But if the new version has additional (or different) dependencies or library names, everything will remain fine with the script (as e.g. with the FreeBSD problem which started this discussion). It's the same with different implementations which maybe be ABI- and API- compatible, but have different dependencies. It helps for locations, but we already have a well adequate solution for that: Putting the location in fpc.cfg. Of course you can require the user to manually specify everything in his config file or on the command line, but it's nicer if this can be avoided. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On Mon, Jul 17, 2006 at 01:56:38PM +0200, Micha Nelissen wrote: > Marco van de Voort wrote: > >> They can't do that without breaking all other packages in the archive > >> using this package. They don't get rebuilt automatically AFAIK, and > >> that's where the difference is IMHO. > > > > I don't understand this. Afaik there is no difference at all. Could you be > > more elaborate in what you think would go wrong automatically? > > My view of source based distributions (in the general software sense) is > that when a package maintainer uploads a new library version (changing > the library name correctly according to that distro's packaging rules) > then all dependent software is automatically recompiled for the new > version (and name), and thus no one notices any breakages. Except 3rd > parties like us. This is not for inbetween releases, since not all software will be automatically recompiled in all cases. And in this case specifically it doesn't matter at all. Moreover source and binary packages can be used together (and in practice, are), and there are build clusters (pointy hat) that check this. It only is true for full releases, since that forces all apps to recompile, then we get the heat. But this is also so on Linux, usually we only get the indication that something is wrong when new distro (+version) emerges. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On Mon, Jul 17, 2006 at 01:57:01PM +0200, Jonas Maebe wrote: > >That's not the point. The point is that I consider a solution, that > >tries to > >collect this data automatically, worse than the current situation. > > There's no reason why a default fallback to the current system > couldn't be supported. If it doesn't exist. But what if it fails? Or if a user pops up in the maillist with a gtk-config related error? Do you really want to support something that you don't control? _and_ at the same time have to maintain the backup too? > >IOW I consider this cure to be worse (more likely to break a release > >systematically and harder to support due to a lack of transparancy > >to end > >users) than the problem, > > I cannot see how this is more likely to break a release > systematically. And it's only as intransparent as we make it (e.g., > apart from the "compiling", "assembling" and "linking", there could > just as well be a "Determining needed libraries using gtk-config..." > message) > > >specially since now we don't have to recompile FPC > >anymore for a lib change. > > I do not understand this last part. Are you talking about dynamically > loading libraries at run time or so? No. Simple the alias stuff. See the original msg from me, last part. To - change a libname mentioned in a linklib, - to conditionally add a lib (include lib a if lib b is used, like the libgcc during 2.0.4 pkging, though maybe that must be static), - or to change order of libs, no FPC repository or fpc binary recompile is necessary anymore ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
Marco van de Voort wrote: > On Mon, Jul 17, 2006 at 01:56:38PM +0200, Micha Nelissen wrote: >> the library name correctly according to that distro's packaging rules) >> then all dependent software is automatically recompiled for the new >> version (and name), and thus no one notices any breakages. Except 3rd >> parties like us. > > This is not for inbetween releases, since not all software will be > automatically recompiled in all cases. Then a lot of users of FreeBSD tracking 6.0 or development, or how you'd call it, should have gotten into trouble as well (since there were no symlinks) ? > And in this case specifically it > doesn't matter at all. What doesn't matter and why ? > Moreover source and binary packages can be used > together (and in practice, are), and there are build clusters (pointy hat) > that check this. What do they check ? > It only is true for full releases, since that forces all apps to recompile, > then we get the heat. But this is also so on Linux, usually we only get the > indication that something is wrong when new distro (+version) emerges. Mainly I guess because we do not have manpower to check more often :-). Not that I'm saying we should have to check that often... Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On 17 Jul 2006, at 14:31, Marco van de Voort wrote: There's no reason why a default fallback to the current system couldn't be supported. If it doesn't exist. But what if it fails? The current solution also fails from time to time. And there would switch to disable this gtk-config calling (just like there are switches to disable assembling and/or linking). Or if a user pops up in the maillist with a gtk-config related error? Do you really want to support something that you don't control? Yes, I prefer that unless the existing solution is so bad it fails almost all the time, or if the alternative is at least as versatile/ compatible and has significant advantages. Most of the messages about *config failing is that the script isn't found at all by the configure script, which would be a non-issue for us. _and_ at the same time have to maintain the backup too? The "backup" must be maintained anyway for libraries which do not come with such a script. I do not understand this last part. Are you talking about dynamically loading libraries at run time or so? No. Simple the alias stuff. See the original msg from me, last part. To - change a libname mentioned in a linklib, - to conditionally add a lib (include lib a if lib b is used, like the libgcc during 2.0.4 pkging, though maybe that must be static), - or to change order of libs, no FPC repository or fpc binary recompile is necessary anymore I see this rather as complementary to supporting the *config scripts: if the *config scripts fail, and if the library names defined in the units are wrong, then you can still work around it with these options. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
Op Mon, 17 Jul 2006, schreef Jonas Maebe:
> On 17 Jul 2006, at 14:03, Daniël Mantione wrote:
>
> > > There's nothing C-specific about libraries, nor about the *config
> > > scripts. At
> > > most it would be linker-specific.
> >
> > There is, those scripts mainly exist because a C compiler cannot
> > determine
> > the dependencies of a library. I.e. if you like libgtk you must also link
> > libglib.
> >
> > We don't need this in Pascal, the compiler can perfectly determine the
> > dependencies by checking the used units. So the primary reason for this
> > cruft is void in Pascal.
>
> You could support exactly the same in C with some #pragma statements in the
> header files. This is implementation-specific rather than language specific.
In that case, there exists no need for gtk-config at all.
> > > A library also exist in at least multiple locations, versions (both
> > > ABI-compatible and -incompatible with previous versions) and
> > > implementations
> > > (e.g. a native Mac OS X GTK and an X-based one).
> >
> > I don't see how *_config guards you against this:
> > * In case of a version change it will simply return the new version. The
> > .so symlink does this as well. If the new version is incompatible with
> > the old one, bad luck.
>
> But if the new version has additional (or different) dependencies or library
> names, everything will remain fine with the script (as e.g. with the FreeBSD
> problem which started this discussion).
That is exactly what Marco's code solves, in a generic way. Solving it by
parsing gtk-config, tclConfig.sh, and so on is a work that never finishes.
> It's the same with different
> implementations which maybe be ABI- and API-compatible, but have different
> dependencies.
Solve it using Pascal:
{$ifdef platform}
uses library;
{$endif}
and the compiler will sort out the rest.
> > It helps for locations, but we already have a well adequate solution for
> > that: Putting the location in fpc.cfg.
>
> Of course you can require the user to manually specify everything in his
> config file or on the command line, but it's nicer if this can be avoided.
If there was a generic way determining library locations: yes
gtk-config can only be used to determine the location of one
library: libgtk. It is useless for libtcl, for example.
Still, you can put some autodetections in samplecfg, but the compiler
itself is really the wrong location to do so.
Daniël___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On 17 Jul 2006, at 14:57, Daniël Mantione wrote:
But if the new version has additional (or different) dependencies
or library
names, everything will remain fine with the script (as e.g. with
the FreeBSD
problem which started this discussion).
That is exactly what Marco's code solves, in a generic way. Solving
it by
parsing gtk-config, tclConfig.sh, and so on is a work that never
finishes.
As I said, you do not have to parse that unless you have an internal
linker. And even then you only have to parse linker options for the
platforms you support. Also, depending on which gtk you link against
on Mac OS X you may need to link umpteen gtk/gdk libraries, or need a
"-framework Gtk+-Cocoa" or similar linker switch (which would be
hard to support with Marco's approach).
The whole point of the *config scripts it that you do not have to
care about such implementation details at all.
It's the same with different
implementations which maybe be ABI- and API-compatible, but have
different
dependencies.
Solve it using Pascal:
{$ifdef platform}
uses library;
{$endif}
and the compiler will sort out the rest.
As explained above, a single platform may have multiple
implementations available. You can of course generate three versions
of all gtk units for Mac OS X (or even four by now), but that's not
really nice either.
Of course you can require the user to manually specify everything
in his
config file or on the command line, but it's nicer if this can be
avoided.
If there was a generic way determining library locations: yes
gtk-config can only be used to determine the location of one
library: libgtk. It is useless for libtcl, for example.
It's not just gtk which uses this, at east sdl also does. And the
fact that it doesn't solve world hunger does not mean it's not useful
to support it.
Still, you can put some autodetections in samplecfg, but the compiler
itself is really the wrong location to do so.
samplecfg only works at install time of the compiler, which is the
wrong time. People don't decide at install time which package, which
variant and which version of it they will want to use one day.
The compiler or linker is the only right place to do it (unless you
wrap the whole thing with a configure script and Makefiles, in which
case you can do it there -- but our compiler largely replaces exactly
that).
Jonas___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On Mon, Jul 17, 2006 at 02:35:41PM +0200, Micha Nelissen wrote: > Marco van de Voort wrote: > > On Mon, Jul 17, 2006 at 01:56:38PM +0200, Micha Nelissen wrote: > >> the library name correctly according to that distro's packaging rules) > >> then all dependent software is automatically recompiled for the new > >> version (and name), and thus no one notices any breakages. Except 3rd > >> parties like us. > > > > This is not for inbetween releases, since not all software will be > > automatically recompiled in all cases. > > Then a lot of users of FreeBSD tracking 6.0 or development, or how you'd > call it, should have gotten into trouble as well (since there were no > symlinks) ? Yes. But probably newer apps depend specifically on the upped version as a workaround, and not on "a gtk1" as we do. (or worse, we don't depend on gtk at all) so the amount of other breakage was probably less because of that. Also this change was at the same time as the importing of libtool (BSD ->libtool GNU libtool), there was a lot of movement already. > > Moreover source and binary packages can be used > > together (and in practice, are), and there are build clusters (pointy hat) > > that check this. > > What do they check ? building all 13000 packages. > > It only is true for full releases, since that forces all apps to recompile, > > then we get the heat. But this is also so on Linux, usually we only get the > > indication that something is wrong when new distro (+version) emerges. > > Mainly I guess because we do not have manpower to check more often :-). The core infrastructure of everything that is built on top of gcc is brought into a consistent state by the distro creators before it goes out of the door. We will never be able to 100% match this. Specially since the toolchain services are generally very gcc centric, and something else is usually not even tested. For FPC this is not done, so we have to act after the release. > Not that I'm saying we should have to check that often... We would have to have people inside the distro's to do that. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
Op Mon, 17 Jul 2006, schreef Jonas Maebe:
>
> On 17 Jul 2006, at 14:57, Daniël Mantione wrote:
>
> > > But if the new version has additional (or different) dependencies or
> > > library
> > > names, everything will remain fine with the script (as e.g. with the
> > > FreeBSD
> > > problem which started this discussion).
> >
> > That is exactly what Marco's code solves, in a generic way. Solving it by
> > parsing gtk-config, tclConfig.sh, and so on is a work that never
> > finishes.
>
> As I said, you do not have to parse that unless you have an internal linker.
> And even then you only have to parse linker options for the platforms you
> support. Also, depending on which gtk you link against on Mac OS X you may
> need to link umpteen gtk/gdk libraries, or need a "-framework Gtk+-Cocoa" or
> similar linker switch (which would be hard to support with Marco's approach).
Ok, with gtk-config the right way to get the libraries is "gtk-config --libs".
With tclConfig.sh you have to source that in a shell script and read
environment variables afterwards.
So, in order to support this, we would need to write a hack when a
{$linklink gtk} occurs and write gtk-config specific code. For a different
library we would need a different hack.
Also, fact is we do have an internal linker and it will hopefully be
used for most platforms in the future. Ultimately it will go in the same
direction as with the assembler readers even for external linkers: In
order to fully understand the parameters, the compiler must understand
them.
> The whole point of the *config scripts it that you do not have to care about
> such implementation details at all.
> > > It's the same with different
> > > implementations which maybe be ABI- and API-compatible, but have
> > > different
> > > dependencies.
> >
> > Solve it using Pascal:
> >
> > {$ifdef platform}
> > uses library;
> > {$endif}
> >
> > and the compiler will sort out the rest.
>
> As explained above, a single platform may have multiple implementations
> available. You can of course generate three versions of all gtk units for Mac
> OS X (or even four by now), but that's not really nice either.
Generate 3 units, and introduce some unit aliases for gtk like Marco did
for libraries, problem solved. That is still a lot more generic solution
than *-config and a lot less work.
> > > Of course you can require the user to manually specify everything in
> > > his
> > > config file or on the command line, but it's nicer if this can be
> > > avoided.
> >
> > If there was a generic way determining library locations: yes
> > gtk-config can only be used to determine the location of one
> > library: libgtk. It is useless for libtcl, for example.
>
> It's not just gtk which uses this, at east sdl also does. And the fact that it
> doesn't solve world hunger does not mean it's not useful to support it.
We should design a system that does solve world hunger. I'm serious about
that: if we want to be a more professional tool than C, we should not copy
the defficiencies. Makefiles are one of them, Autohell is another, and
I consider this one such a thing as well.
> > Still, you can put some autodetections in samplecfg, but the compiler
> > itself is really the wrong location to do so.
>
> samplecfg only works at install time of the compiler, which is the wrong time.
> People don't decide at install time which package, which variant and which
> version of it they will want to use one day.
>
> The compiler or linker is the only right place to do it (unless you wrap the
> whole thing with a configure script and Makefiles, in which case you can do it
> there -- but our compiler largely replaces exactly that).
This we agree on, the compiler should do the work.
Daniël___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On 17 Jul 2006, at 16:01, Daniël Mantione wrote:
As I said, you do not have to parse that unless you have an
internal linker.
And even then you only have to parse linker options for the
platforms you
support. Also, depending on which gtk you link against on Mac OS X
you may
need to link umpteen gtk/gdk libraries, or need a "-framework Gtk+-
Cocoa" or
similar linker switch (which would be hard to support with
Marco's approach).
Ok, with gtk-config the right way to get the libraries is "gtk-
config --libs".
With tclConfig.sh you have to source that in a shell script and read
environment variables afterwards.
So, in order to support this, we would need to write a hack when a
{$linklink gtk} occurs and write gtk-config specific code. For a
different
library we would need a different hack.
Of course not. You should never change a {$linklib magicstring} into
some command. The exact command(s) to be executed would have to be
embedded in the unit with a compiler directive (and probably, just
like library name, be ifdef'd per platform).
Also, fact is we do have an internal linker and it will hopefully be
used for most platforms in the future.
I do not see this happening any time soon for e.g. Mac OS X.
Ultimately it will go in the same
direction as with the assembler readers even for external linkers: In
order to fully understand the parameters, the compiler must understand
them.
Yes, this is a downside of integrating everything (with the upside
being speed and memory usage, obviously).
Generate 3 units, and introduce some unit aliases for gtk like
Marco did
for libraries, problem solved. That is still a lot more generic
‹solution
than *-config and a lot less work.
Of course making the developer type in everything manually is always
more generic and less work for us. That is not my point, and I'm not
against providing this functionality. As I said in my reply to Marco,
I consider it complementary, as a last resort if all else fails.
It's not just gtk which uses this, at east sdl also does. And the
fact that it
doesn't solve world hunger does not mean it's not useful to
support it.
We should design a system that does solve world hunger. I'm serious
about
that: if we want to be a more professional tool than C, we should
not copy
the defficiencies. Makefiles are one of them, Autohell is another, and
I consider this one such a thing as well.
I think all this "competing with C" and not-invented-here syndrome is
downright silly, along with all the claiming that most bad things
come from C. If anything, it comes mostly from the standard Unix
design philosophy (small, well-delineated tools which perform their
core function and *only* that core function). Most *nix C compilers
follow that principle very well, but other C development environments
are more integrated (like commercial Mac and Windows IDEs, where you
sometimes can hardly e.g. tell the compiler from the linker).
We are only a small team, and by playing the elite Pascal geeks who
are going to show how much the C world sucks by doing everything
different, we are going to
keep getting stuck by having to reimplement everything because we
cannot work with what is already there. People often talk about how
stupid Mac users supposedly are and how elite they consider
themselves. Well, this Pascal-elitism and C-hostility by some gives
the Pascal community just as bad a name, even though just like in the
Mac community most people probably couldn't care less about these
little superiority wars.
To get back on topic: the more hacks you add to work around already-
existing infrastructure "because we don't want to rely on external
tools", the more you force yourself to keep doing that more and more
forever in the future. If you like that, fine. I don't.
The problem in this particular case is not C, it is the way most OS's
(do not) support library management. There are various workarounds to
make it less painful, and this *-config script thing is one way which
is fairly straightforward and which is being adopted in various
places (sometimes even fairly general, grouping everything together
in a global pkg-config script). Adding support for using this
existing infrastructure is good if it can help solving some problems
without people needing to know the nitty-gritty details of how the
libraries are called on their system.
Still, you can put some autodetections in samplecfg, but the
compiler
itself is really the wrong location to do so.
samplecfg only works at install time of the compiler, which is the
wrong time.
People don't decide at install time which package, which variant
and which
version of it they will want to use one day.
The compiler or linker is the only right place to do it (unless
you wrap the
whole thing with a configure script and Makefiles, in which case
you can do it
there -- but our compiler largely replaces exactly t
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
Op Mon, 17 Jul 2006, schreef Jonas Maebe: > Above you said that the compiler is the wrong location? The compiler is from a software engineering point of view the wrong location to call gtk-config and clones. However, it is the compiler's task to pass the libraries a unit needs to the linker. As this is contradictory, my conclusion is that we should not use gtk-config. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
Jonas Maebe wrote: > > On 17 Jul 2006, at 16:01, Daniël Mantione wrote: > >> We should design a system that does solve world hunger. I'm serious about >> that: if we want to be a more professional tool than C, we should not >> copy >> the defficiencies. Makefiles are one of them, Autohell is another, and >> I consider this one such a thing as well. > > I think all this "competing with C" and not-invented-here syndrome is > downright silly, along with all the claiming that most bad things come > from C. So you will claim that auto* tools and configure scripts are a good design ? > If anything, it comes mostly from the standard Unix design > philosophy (small, well-delineated tools which perform their core > function and *only* that core function). No these are separate things. The C compiler vendors do not provide a common platform resulting in a differing mess that has to be held together with scripts. These differences do not add expressive power as the unix tools allow when combining them in a smart way. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On Monday 17 July 2006 15:03, Micha Nelissen wrote: > No these are separate things. The C compiler vendors do not provide a > common platform resulting in a differing mess that has to be held > together with scripts. Of course they don't. Unlike some other languages where such things are standardized quite clearly, (most) consistency, dependency and linking issues are beyond the scope of the official C-standard. What a luck that at least the code is portable from one platform to another. If you have a spare floppy to transport it. :-> Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
Vinzent Hoefler wrote: > Of course they don't. Unlike some other languages where such things are > standardized quite clearly, (most) consistency, dependency and linking > issues are beyond the scope of the official C-standard. I'm not talking about the C language, but the vendors, the C library implementors, etc. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Apache headers
Hello, The headers are now available for download. The are explanations about how to make a simple module, example code, internal details and a download link of the bindings here: http://www.freepascal.org/wiki/index.php?title=FPC_and_Apache_Modules I translated mod_example from apache source code, and latter I should translate other modules too. Most of my tests were on Windows, so it would be nice if people test on Unix. The headers aren´t fully translated yet. I would say about 90% done, but is more then enougth for people to start playing with them. I will wait until the headers stabilize before sending for FPC subversion. Please submit bug reports! There is also an easter egg! The apache libraries put some strange prefixes and suffixes on function names, like many c libraries do. So I developed a software to list all exported functions of a dll. I thought it could help others doing binding work, so I released it as a Lazarus example, here: http://wiki.lazarus.freepascal.org/index.php/Libview thanks a lot, -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Apache headers
OT (more or less), I wish to create a very important mod for Apache that will divide error log based on virtual host. Do you know a good resource to use ? Does the current translated mod_example, can help me achieve that ? Ido On 7/17/06, Felipe Monteiro de Carvalho <[EMAIL PROTECTED]> wrote: Hello, The headers are now available for download. The are explanations about how to make a simple module, example code, internal details and a download link of the bindings here: http://www.freepascal.org/wiki/index.php?title=FPC_and_Apache_Modules I translated mod_example from apache source code, and latter I should translate other modules too. Most of my tests were on Windows, so it would be nice if people test on Unix. The headers aren´t fully translated yet. I would say about 90% done, but is more then enougth for people to start playing with them. I will wait until the headers stabilize before sending for FPC subversion. Please submit bug reports! There is also an easter egg! The apache libraries put some strange prefixes and suffixes on function names, like many c libraries do. So I developed a software to list all exported functions of a dll. I thought it could help others doing binding work, so I released it as a Lazarus example, here: http://wiki.lazarus.freepascal.org/index.php/Libview thanks a lot, -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Apache headers
On 7/17/06, ik <[EMAIL PROTECTED]> wrote: OT (more or less), I wish to create a very important mod for Apache that will divide error log based on virtual host. Do you know a good resource to use ? Does the current translated mod_example, can help me achieve that ? I do plan to create some tutorials about technical details of modules, but for specific things like that I advise you to join the official apache-modules mailling list, for modules developers, and ask there: http://httpd.apache.org/lists.html#http-modules Or search the archives of that list. Because althought I translated the headers, I am not yet familiar of all details of modules. thanks, -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On Mon, Jul 17, 2006 at 04:37:07PM +0200, Jonas Maebe wrote:
> >So, in order to support this, we would need to write a hack when a
> >{$linklink gtk} occurs and write gtk-config specific code. For a
> >different
> >library we would need a different hack.
>
> Of course not. You should never change a {$linklib magicstring} into
> some command. The exact command(s) to be executed would have to be
> embedded in the unit with a compiler directive (and probably, just
> like library name, be ifdef'd per platform).
The setup of the whole linkaliasing is to change the $linklib into mere
identifiers (while compiling units) that can then be mapped at will to real
libnames when determining how to link, with the default being 1:1. This
means we could move the whole ifdef {$linklib mess to a platforms (or
distro) specific fpc.cfg #include and more importantly OUT OF SORUCE
(regardless of internal or external, though with external more of the
discovery process must be done up front).
I want more out of source.
> >Also, fact is we do have an internal linker and it will hopefully be
> >used for most platforms in the future.
>
> I do not see this happening any time soon for e.g. Mac OS X.
I didn't see it happening at all half an year ago, but thanks to Peter...
> > That would be a pity, since OS X is the se Ultimately it will go in the
> >same direction as with the assembler readers even for external linkers:
> >In order to fully understand the parameters, the compiler must understand
> >them.
>
> Yes, this is a downside of integrating everything (with the upside
> being speed and memory usage, obviously).
It is inevitable. But that doesn't mean there is only one way to integrate
stuff. It must be done cautiously, and pragmatic.
> >Generate 3 units, and introduce some unit aliases for gtk like
> >Marco did
> >for libraries, problem solved. That is still a lot more generic
> >?solution
> >than *-config and a lot less work.
>
> Of course making the developer type in everything manually is always
> more generic and less work for us.
The idea is being able to be able to generally fix an existing release
_after_ a change becomes know (read: a distro release). It can be as simple
as saying "copy and paste this set", or download this source and run the
utility.
> That is not my point, and I'm not
> against providing this functionality. As I said in my reply to Marco,
> I consider it complementary, as a last resort if all else fails.
I consider pkgconfig very important. But I want to have it feed a store, a
FPC configuration file.
This because I want to be able to say "mail me your compiler state", and
send back a new one. Too much automatism will make things less transparant.
To the user, but also to the one who has to support it.
Supporting multiple versions is hard, and other people designs are not
always perfect or tailored to our use. Do I have to mention XCode here? :-)
> >that: if we want to be a more professional tool than C, we should not
> >copy the defficiencies. Makefiles are one of them, Autohell is another,
> >and I consider this one such a thing as well.
>
> I think all this "competing with C" and not-invented-here syndrome is
> downright silly, along with all the claiming that most bad things
> come from C.
That was Almindor not me. However there is a point in this that I agree
with. All this infrastructure is not designed for anything but the standard
toolchain. It is not like e.g. Win32 for any vendor to build on top off.
Also even for them there are bumps, but these are polished away for the
default systems in the distro release engineering. E.g. for a new compiler
the whole build environemnt is changed and made consistent. But for us stuff
breaks.
That is not "not-invented-here" syndrome or C phobia, but a simple reality.
I agree a bit with Florian that there is a fundamental problem in the Unix
(and then specially the Open Source parts) way of doing here. Something I
would never have agreed on say 5 years back.
> If anything, it comes mostly from the standard Unix
> design philosophy (small, well-delineated tools which perform their
> core function and *only* that core function)
_eighties_ Unix philosophy. Have you seen the sheer size of an avg Linux
distribution? Install *BSD, build a world, and see it rolling over your
screen :-). Unix nowadays is gigantic, and monolithical. These are old
sentiments.
> Most *nix C compilers follow that principle very well, but other C
> development environments are more integrated (like commercial Mac and
> Windows IDEs, where you sometimes can hardly e.g. tell the compiler from
> the linker).
IMHO the C _compiler_ way of things is not Unix philosophy, but simply the
lack of memory of K&R's their PDP7. Batchwise processing allowed less
memory. See the various Unix history books. Of course there was much
revisionism afterwards.
> we are going to keep getting stuck by having to reimplement everything
> because we cannot w
[fpc-devel] Problem with make deb in fixes_2_0 branch
I tried doing a "make deb" from the fixes_2_0 branch and I got an error. The log info is below: === /usr/bin/make -C fpcm all grep: /etc/ld.so.conf: No such file or directory make[4]: Entering directory `/home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/utils/fpcm' make[4]: Leaving directory `/home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/utils/fpcm' /usr/bin/make -C tply all make[4]: Entering directory `/home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/utils/tply' make[4]: Leaving directory `/home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/utils/tply' /usr/bin/make -C h2pas all make[4]: Entering directory `/home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/utils/h2pas' make[4]: Leaving directory `/home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/utils/h2pas' /usr/bin/make -C fprcp all make[4]: Entering directory `/home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/utils/fprcp' make[4]: Leaving directory `/home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/utils/fprcp' /usr/bin/make -C dxegen all make[4]: Entering directory `/home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/utils/dxegen' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/utils/dxegen' /usr/bin/make -C fpdoc all grep: /etc/ld.so.conf: No such file or directory make[4]: Entering directory `/home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/utils/fpdoc' make[4]: Leaving directory `/home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/utils/fpdoc' /usr/bin/make -C fpcres all make[4]: Entering directory `/home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/utils/fpcres' make[4]: Leaving directory `/home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/utils/fpcres' /usr/bin/install -m 755 -d /home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/debian/tmp/usr/bin /usr/bin/install -c -m 755 ppdep ptop rstconv data2inc delp bin2obj postw32 grab_vcsa /home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/debian/tmp/usr/bin /usr/bin/make -C fpcm install grep: /etc/ld.so.conf: No such file or directory make[4]: Entering directory `/home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/utils/fpcm' /usr/bin/install -m 755 -d /home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/debian/tmp/usr/bin /usr/bin/install -c -m 755 fpcmake /home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/debian/tmp/usr/bin make[4]: Leaving directory `/home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/utils/fpcm' /usr/bin/make -C tply install make[4]: Entering directory `/home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/utils/tply' /usr/bin/install -m 755 -d /home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/debian/tmp/usr/bin /usr/bin/install -c -m 755 plex pyacc /home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/debian/tmp/usr/bin /home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/utils/fpcm/fpcmake -p -Ti386-linux Makefile.fpc Processing Makefile.fpc Writing Package.fpc /usr/bin/install -m 755 -d /home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/debian/tmp/usr/lib/fpc/2.0.3/units/i386-linux/lexyacc /usr/bin/install -c -m 644 Package.fpc /home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/debian/tmp/usr/lib/fpc/2.0.3/units/i386-linux/lexyacc /usr/bin/install -m 755 -d /home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/debian/tmp/usr/lib/fpc/2.0.3/units/i386-linux/lexyacc /usr/bin/install -c -m 644 units/i386-linux/lexlib.ppu units/i386-linux/yacclib.ppu /home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/debian/tmp/usr/lib/fpc/2.0.3/units/i386-linux/lexyacc /usr/bin/install -c -m 644 units/i386-linux/lexlib.o units/i386-linux/yacclib.o /home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/debian/tmp/usr/lib/fpc/2.0.3/units/i386-linux/lexyacc /usr/bin/install -m 755 -d /home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/debian/tmp/usr/lib/fpc/lexyacc /bin/cp -fp yylex.cod yyparse.cod /home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/debian/tmp/usr/lib/fpc/lexyacc make[4]: Leaving directory `/home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/utils/tply' /usr/bin/make -C h2pas install make[4]: Entering directory `/home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/utils/h2pas' /usr/bin/install -m 755 -d /home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/debian/tmp/usr/bin /usr/bin/install -c -m 755 h2pas h2paspp /home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/debian/tmp/usr/bin make[4]: Leaving directory `/home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/utils/h2pas' /usr/bin/make -C fprcp install make[4]: Entering directory `/home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/utils/fprcp' /usr/bin/install -m 755 -d /home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/debian/tmp/usr/bin /usr/bin/install -c -m 755 fprcp /home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/debian/tmp/usr/bin make[4]: Leaving directory `/home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/utils/fprcp' /usr/bin/make -C dxegen install make[4]: Entering directory `/home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/utils/dxegen' make[4]: Nothing to be
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On 17 Jul 2006, at 22:36, Marco van de Voort wrote:
Of course not. You should never change a {$linklib magicstring} into
some command. The exact command(s) to be executed would have to be
embedded in the unit with a compiler directive (and probably, just
like library name, be ifdef'd per platform).
The setup of the whole linkaliasing is to change the $linklib into
mere
identifiers (while compiling units) that can then be mapped at will
to real
libnames when determining how to link, with the default being 1:1.
I know, but I was trying to point out that e.g. on Mac OS X sometimes
you may need
-lgtk-1.2.0 -lgdk-1.2.0 -lgdk_pixbuf
and sometimes
-framework Gtk+-Cocoa
and sometimes
-framework Gtk-Carbon
(and there's a fourth "native" Mac OS X gtk port underway, because
the two previous ones were never really finished)
You need something more than merely the remapping of library names.
This
means we could move the whole ifdef {$linklib mess to a platforms (or
distro) specific fpc.cfg #include and more importantly OUT OF SORUCE
(regardless of internal or external, though with external more of the
discovery process must be done up front).
I want more out of source.
I don't really care where exactly the information is stored (although
the unit somehow seems logical to me, if you want to keep the
interface and libs specification together), but if we change things
from the way they are now, then the information should be dynamic
(i.e., not merely determined at install time, because that only
shifts the problem) and preferably come from available automatic
sources (as opposed to the developer having to specify it).
Also, fact is we do have an internal linker and it will hopefully be
used for most platforms in the future.
I do not see this happening any time soon for e.g. Mac OS X.
I didn't see it happening at all half an year ago, but thanks to
Peter...
The GNU tool chain is at the same time more and less static than the
Mac OS X tool chain. Apple changes internal stuff concerning
libraries and the like all the time for their new whizzbang features
(zero-link, fix-and-continue, prebinding and then not anymore, ...).
It would be hell to keep up with that.
That is not my point, and I'm not
against providing this functionality. As I said in my reply to Marco,
I consider it complementary, as a last resort if all else fails.
I consider pkgconfig very important. But I want to have it feed a
store, a
FPC configuration file.
The problem is that it needs to be "refed" every time you compile
something using particular units (those depending on libraries
requiring this mumbo-jumbo). Not to mention on multi-arch systems
(like darwin/i386 which can also run darwin/ppc binaries) where the
parameters will depend on the architecture you are compiling for
(unless you have perfectly symmetrical needs for ppc and i386 with
just a different directory name somewhere, but that's often not the
case because ppc is most of the time supported back to Mac OS X
10.2.8, while i386 support only starts at 10.4).
This because I want to be able to say "mail me your compiler
state", and
send back a new one. Too much automatism will make things less
transparant.
To the user, but also to the one who has to support it.
That's what "-al -s" is for.
Supporting multiple versions is hard, and other people designs are not
always perfect or tailored to our use. Do I have to mention XCode
here? :-)
I do not think a closed source IDE which is being (re)built from
scratch and being stuffed with new features all the time (as opposed
to first fleshing out the basics) to give Steve Jobs something flashy
to talk about at the next WWDC is comparable to a script which
generates some linker parameters. And a bunch of linker parameters is
exactly tailored to what we need.
that: if we want to be a more professional tool than C, we should
not
copy the defficiencies. Makefiles are one of them, Autohell is
another,
and I consider this one such a thing as well.
I think all this "competing with C" and not-invented-here syndrome is
downright silly, along with all the claiming that most bad things
come from C.
That was Almindor not me.
I was replying to a mail from Daniel.
That is not "not-invented-here" syndrome or C phobia, but a simple
reality.
I agree a bit with Florian that there is a fundamental problem in
the Unix
(and then specially the Open Source parts) way of doing here.
That's more or less what I'm saying below, which you are refuting.
If anything, it comes mostly from the standard Unix
design philosophy (small, well-delineated tools which perform their
core function and *only* that core function)
_eighties_ Unix philosophy. Have you seen the sheer size of an avg
Linux
distribution?
Many small things (and some larger, like OpenOffice.org) together
make for large sizes.
gtk-config? Seem to do awfully lot,
It prints a str
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
Op Tue, 18 Jul 2006, schreef Jonas Maebe: > You need something more than merely the remapping of library names. As I said, you can remap unit names. At some point the user will have to decide to which one he wants to link, doing it by a unit name remap looks an elegant solution to me. > > > I think all this "competing with C" and not-invented-here syndrome is > > > downright silly, along with all the claiming that most bad things > > > come from C. > > > > That was Almindor not me. > > I was replying to a mail from Daniel. Doesn't matter: Marco was pointing out that all the (bandaid) stuff was designed for a single toolchain: gcc. We have the opportunity to do better, and therefore save our users from all kinds of bandaids gcc users need. If you think supporting gtk-config doesn't hurt the users: If we don't fix this properly, our users will feel necessary to write this kind of band-aids for their own libraries as well. > > and parse it and try to merge it > > with our own state and support that? > > For the external linker not a single bit of internal state merging is > necessary. It's just a fire-and-forget string. For the internal linker, yes, > you need some kind of parsing just like you need it for the assembler reader > and the binary writer (like Daniel mentioned iirc). I'm quite sure it will at some point be necessary to parse it even for the external linker, we had our own parsers before we had an internal assembler. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On Monday 17 July 2006 15:33, Micha Nelissen wrote: > Vinzent Hoefler wrote: > > Of course they don't. Unlike some other languages where such things > > are standardized quite clearly, (most) consistency, dependency and > > linking issues are beyond the scope of the official C-standard. > > I'm not talking about the C language, but the vendors, the C library > implementors, etc. And I was talking about the deficiency of its language definition that leads to exactly what your complaining about. Don't make the mistake to reduce language to syntax only. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Mac OS X Quickstart section in README file
There is no Mac OS X Quickstart section in the install/doc/readme.txt file,
although needed, in particular for the ReadMe.txt File of Mac OS X .dmg package.
This is my suggestion, which is partly based on what I found in
install/macosx/resources/ReadMe.txt:
* Quick start - Mac OS X/Darwin
There are two methods to install FreePascal for Mac OS X.
1) Download and install the Mac OS X package (fpc-2.0.4.powerpc-macosx.dmg)
This gives you the FreePascal compiler and the Xcode integration kit.
2) Install fpc using fink
This gives you the FreePascal compiler, in cluding all libraries, packages
and units from its sources, including FreeVision and the IDE, which is
partly works using X11 xterm.
With method 1 follow the instructions to install the XCode integration kit at:
http://www.freepascal.org/xcode.html
Method 2 is mainly thought for using the compiler through the command
line. Fink takes care of setting the PATH variable. You can (under Mac OS
X 10.2.x or earlier you actually have to) also use the command line with
FreePascal installed using method 1. The main point is to change your Path
as described below:
The compiler is called "fpc" and will be installed in /usr/local/bin. This
directory may not be in your PATH, yet (if you type "fpc" in a Terminal
window and you get something like "fpc: command not found", then it isn't).
If the installation directory is not yet in your path, you will have to add
it. To get an idea, how to do this, follow the instructions at:
"http://fink.sourceforge.net/doc/users-guide/install.php#setup";
to determine which file you have to edit, but instead of adding the line
suggested there, add the following at the end:
- if your shell is the Bourneshell (bash):
export PATH=/usr/local/bin:$PATH
When using Terminal.app add this to ".bash_profile",
when using the X11 xterm add this to ".bashrc".
If these files do not exist yet in your home directory, you have to create
them, for example with nano (or any other text editor):
nano .bash_profile
- if your shell is the C Shell (csh or tcsh):
setenv PATH /usr/local/bin:${PATH}
Next, close the Terminal window and open a new one. Now, the path should
be set correctly. After installing the package, you can write your
source code in your favorite editor (including Project Builder and XCode).
To compile something, go to the directory containing your source files in
Terminal and type:
fpc name_of_your_source_file
The compiler only accepts one file name as argument, but will automatically
search for and compile any units used by the specified source file. Run
"fpc" without an yarguments to get an overview of the possible command line
options.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
