[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.
Jonas
More information about the fpc-devel
mailing list