RPATH problems in kdelibs

[Alexander Neundorf]

On Monday 27 November 2006 08:19, Thiago Macieira wrote:
> Alexander Neundorf wrote:
> >> Regardless of whether you added or not, they had RPATH (as my examples
> >> showed). They were Qt's library dir, plus /usr/local/lib and /lib (but
> >> not /usr/lib). Can you care to guess where those paths came from?
> >
> >Yes, I can care to guess.
> >Btw. if you search for "RPATH" in FindKDE4Internal.cmake and
> > KDE4Macros.cmake you will find everything related to RPATH handling for
> > KDE. So it's not that hard to find out. It's even completely commented.
>
> Let me rephrase: I did search. And given the comment in
> tKDE4Macros.cmake -- which I would expect to be from you -- "libraries
> don't get any RPATH", I'd also expect you to be guessing as much as I
> where it came from.

Ok. I committed a patch which restores the pre-cmake-2.4.3 behaviour where 
libs don't get any RPATH.
Rationale: without any RPATH the libs get the RPATH from the executable 
(AFAIK). This means when running an uninstalled executable, it will link to 
the correct uninstalled libs. When the executable gets installed, it is 
relinked to the installed versions.
When building libs with RPATH, they have to be built with the build-RPATH and 
then relinked to the install-RPATH when installing. This will take some time 
and cause complaints.

AFAIK this works at least on Linux.
Are kdewidget and maybe the styles, i.e. stuff which is loaded by Qt, the only 
problems ?
Then for these SET_TARGET_PROPERTIES() could be used explicitely to set the 
correct RPATH again.

This is no issue on OS X where there is install_name_tool which has the same 
effect but works blazingly fast. 
There is a tool called chrpath (http://freshmeat.net/projects/chrpath/) which 
can edit the RPATH in ELF files, the only problem is that it can't add an 
RPATH if there's no RPATH yet in the ELF file, and the new RPATH may not be 
longer than the already existing RPATH. Having something like that for ELF 
files would be really nice.

> >> By the way, I've also found this weird code in FindKDE4Internal.cmake:
> >> # also use /usr/local by default under UNIX, including Mac OS X
> >> if (UNIX)
> >>    link_directories(/usr/local/lib)
> >>    set( _KDE4_PLATFORM_INCLUDE_DIRS /usr/local/include )
> >>
> >> Why is that being added?
> >
> >What is so weird about /usr/local/ ?
>
> What is so special about it that it should be added? I don't think it
> should be treated any more specially than anything else.
>
> Note that gcc already includes those.

Let me just assure you, when I started this, it _did_ help against some 
problems. 

Bye
Alex
-- 
Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de
Home: neundorf AT kde.org                - http://www.kde.org
      alex AT neundorf.net               - http://www.neundorf.net