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

[Daniël Mantione]

Op Mon, 17 Jul 2006, schreef Jonas Maebe:

> =

> On 17 Jul 2006, at 14:57, Dani=EBl 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 link=
er.
> 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 appro=
ach).

Ok, with gtk-config the right way to get the libraries is "gtk-config --lib=
s".
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 ab=
out
> 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 th=
at 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=EBl