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

[Daniël Mantione]

Op Tue, 18 Jul 2006, schreef Jonas Maebe:

> You need something more than merely the remapping of library names.

As I said, you can remap unit names. At some point the user will have to =

decide to which one he wants to link, doing it by a unit name remap looks =

an elegant solution to me.

> > > I think all this "competing with C" and not-invented-here syndrome is
> > > downright silly, along with all the claiming that most bad things
> > > come from C.
> > =

> > That was Almindor not me.
> =

> I was replying to a mail from Daniel.

Doesn't matter: Marco was pointing out that all the (bandaid) stuff was =

designed for a single toolchain: gcc. We have the opportunity to do better,=
 and =

therefore save our users from all kinds of bandaids gcc users need.

If you think supporting gtk-config doesn't hurt the users: If we don't fix =

this properly, our users will feel necessary to write this kind of =

band-aids for their own libraries as well.

> > and parse it and try to merge it
> > with our own state and support that?
> =

> For the external linker not a single bit of internal state merging is
> necessary. It's just a fire-and-forget string. For the internal linker, y=
es,
> you need some kind of parsing just like you need it for the assembler rea=
der
> and the binary writer (like Daniel mentioned iirc).

I'm quite sure it will at some point be necessary to parse it even for =

the external linker, we had our own parsers before we had an internal =

assembler. =


Dani=EBl