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

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


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


More information about the fpc-devel mailing list