[fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

Jonas Maebe jonas.maebe at elis.ugent.be
Mon Jul 17 14:53:30 CEST 2006

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.


More information about the fpc-devel mailing list