finding libraries for programs with doing clean builds

[Ralf Habacker]

Thiago Macieira schrieb:

>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.
>  
>
Some time ago I provided initial support for libtool replacement called 
"depfile" support.  
http://mail.kde.org/pipermail/kde-buildsystem/2005-November/000199.html
In http://lists.kde.org/?l=kde-commits&m=113156335225189&w=2 Benjamin 
Reed gave some additional hints. Unfortunally I wasn't able to wrote 
that stuff because of lack of time (and required linux related know 
how). Perhaps someone else can  take a look into that.

BTW: What about writing wrapper scripts. I have thought about this 
already on windows platforms (using <appname>.bat) because of the same 
library finding problem.

Ralf