Broken RPATH/RUNPATH in kdepim/console/kabc2mutt

[Andreas Pakulat]

On 10.04.09 06:37:14, Maciej Mrozowski wrote:
> On Friday 10 of April 2009 01:53:07 Tomáš Chvátal wrote:
> > Dne pátek 10 Duben 2009 01:35:29 Andreas Pakulat wrote:
> > > > Regarding kdepim, why not just install kabc2mutt as symlink to
> > > > kabcclient?
> > >
> > > Because at least one platform of KDE4 doesn't support symlinks.
> > >
> > > Andreas
> >
> > Wont it be smart to actualy use symlinks where they work and use the
> > current system only when needed?
> 
> > Out of curiosity what platform dont support symlinks (when i think of
> > linux/BSD/Windows all supports them)
> 
> Well, on Windows one can still use FAT32 (but the same applies to other 
> platforms as well).

Exactly, not to mention that average windows users don't have a clue
about symlinks.

> Those who researched the topic will see that in kdepim/console/kabcclient 
> there's already
> if (NOT WIN32)
>   install ( RENAME )
> else (NOT WIN32)
>  compile again with different executable name and install
> fi (NOT WIN32)

One easy solution would be to enable the else-part for all platforms,
did you ask the kdepim people why they don't do that? I'm guessing to
reduce compile time, but that could also be achieved by splitting up the
code into main.cpp + a static lib for the rest and link both executables
to the static library.

> @Andreas
> Yes, you are missing sth :) - the fact I mentioned that Gentoo fixes missing 
> RPATH entries, that's why in attached scanelf output they are fine.

Ah, it would be better for discussion to see the actual RPATH.

> Still there is *difference* in RPATH sections between source executable, and 
> "renamed" one, and should be the case for operation called RENAME.
> One can build kdepim/console/kabcclient and use some elf utils to display 
> RPATH

Unfortunately here I can't reproduce this as everything is installed
into /usr/local. So without the Gentoo patches the RPATH in kabc2mutt
refers to the builddir of kdepim, I guess?

> Of course if any, it's cmake bug and I should probably report it there.

I don't think this is a real bug, CMake is told that there's an
executable that it should install and it should rename it on the way.
As CMake doesn't know this executable has been built by it, it has no
right to assume it should touch any of the internals of that executable.

The only solution that CMake could provide, is a RENAME option for
install(TARGETS).

> As far as kdepim is concerned, symlink would be the best here, unfortunately I 
> have no idea how to reliably create one in cmake. i guess it would need at 
> least two steps:
> - create relative symlink in current (for target executable - build) dir
> - install symlink as FILE to ${BINARY_DIR}

Shouldn't this work: 

cmake -E create_symlink ${BIN_INSTALL_DIR}/kabcclient
${BIN_INSTALL_DIR}/kabc2mutt

Though I'm not sure how that expands when DESTDIR is used...

Andreas

-- 
You get along very well with everyone except animals and people.