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

[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).

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