finding libraries for programs with doing clean builds

[Thiago Macieira]

Matt Rogers wrote:
>> 2) relinking the program if no other suitable method is found
>>
>> Note that a standard Linux uses option #2, because LD_LIBRARY_PATH
>> won't work on a standard KDE installation that used --rpath.
>
>but when does it relink it? at install time?

At run time.

The build system expects you to install first, then run. So it builds the 
final binary.

If you try to run it before you install, the shell script that is where 
you'd expect the binary to be will relink the code so that you can run 
it.

>> Also note that the fact that we run program we've just built makes it
>> impossible to do a KDE cross-compilation. The clean solution for this
>> would be to split all programs we need for building KDE from the KDE
>> build itself.
>
>And I might get killed for saying this, but what about just continuing
>to use libtool as part of the build process? Surely we could hack
>something into bksys to do this.

We don't want to keep libtool.

The solution is to reimplement libtool's behaviour. This includes it.

Maybe we'll need to support libtool for those bizarre platforms that we 
support but don't understand. But the majority of our userbase uses ELF 
systems, which can be supported easily and MUCH faster than libtool.

Talk to coolo if you will: KDE recompilation wastes too much time 
executing libtool's shell script.
-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

1. On frumscafte, hwonne time_t wæs náht, se scieppend þone circolwyrde 
wundorcræftlíge cennede and seo eorðe wæs idel and hit wæs gód.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20060106/b212bef2/attachment-0001.pgp