--===============0395620210==
Content-Type: multipart/signed;
  boundary="nextPart1569811.4JkjumA5Ye";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1569811.4JkjumA5Ye
Content-Type: text/plain;
  charset="iso-8859-6"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Discussion moved from kde-core-devel. Link to thread:
http://lists.kde.org/?t=3D119343241900001&r=3D1&w=3D2

Em Monday 29 October 2007 16:45:01 Alexander Neundorf escreveu:
> > But can't we use the installed libraries for the commands used during
> > installation?
>
> You mean "used during building", right ?
> Not necessarily. The commands may use some new stuff or need bug fixes fr=
om
> the libs so they need to get the libraries from the build tree.

Yes, I meant that. But you're right: the application may need some new=20
functionality from the library.

By the way, this is how Qt solves this problem for moc and uic: it *doesn't=
*=20
link them to the Qt libraries. Those programs are "bootstrapped": that is,=
=20
they add the .cpp files directly to their compilation, therefore linking=20
statically to the Qt stuff they need.=20

So in a typical Qt build, qstring.cpp is compiled 5 times: once for QtCore,=
=20
then one more time per tool (moc, uic, rcc and qmake).

> > Another option: build those tools only with RPATH to the build tree, th=
en
> > relink them (and only them) during installation. This requires a full
> > library list during linking: e.g., "-lkio -lkdeui -lkdecore", not just
> > "-lkio". Doesn't CMake already do that?
>
> Well, the issue is that potentially any of the libraries could be used by
> these tools, and it doesn't make sense to mark libraries as
> RUN_UNINSTALLED, because the developer of the library doesn't necessarily
> know that.
>
> CMake doesn't automatically detect which shared libraries are linked to
> executables which have an RPATH which points into the build tree, in order
> to guess to build these libraries also with RPATH pointing into the build
> tree.

What happens to a library marked RUN_UNINSTALLED?

My point is: only the program has to be modified to find the libraries when=
=20
they aren't installed yet. The libraries themselves don't need to be modifi=
ed=20
at all.

So, when building a RUN_UNINSTALLED program, it is linked with full rpath t=
o=20
the build tree and full library list. That way, all libraries will be found=
=20
in the build tree, even if the libraries themselves don't know anything abo=
ut=20
RUN_UNINSTALLED.

> > Maybe an even better option: set LD_LIBRARY_PATH when running
> > uninstalled. That variable overrides RUNPATH and any distribution not
> > using that (read: using RPATH only) should be shot in the head.
> > DT_RUNPATH has been available for more than 5 years.
>
> While it probably is available on most Linux systems today, I don't know =
if
> this is also true for *BSD, Solaris, HP-UX etc.

=46reeBSD has been using RUNPATH exclusively for years. They have already d=
umped=20
the old and conceptually broken DT_RPATH. This is what irks me: why the hel=
l=20
hasn't Linux done the same? Support for DT_RUNPATH has been around for 8=20
years in glibc, some 5 years or more in the linker.

Of the platforms we can support, we have two groups:

AIX, MacOS X, Win32: their own executable formats
All others (Linux, the BSDS, Solaris, IRIX, HP-UX): ELF

I have no idea about AIX's file format. All I know is it's COFF-based (it's=
=20
called XCOFF). Reading through the ld(1) man page on AIX indicates that the=
=20
linker hardcodes the -L switches to the final executable. In other words: t=
he=20
AIX linker does not like linking to uninstalled libraries at all. It would=
=20
indicate that relinking at install time is mandatory on AIX (so as to get r=
id=20
of the build-tree references).

I also try to steer away from MacOS X's Mach-O format. It's very confusing.=
=20
But I know it supports changing the linker paths of already-created=20
executables without relinking.

As for Win32's COFF Portable Executable format, the interesting thing is th=
at=20
all we need to do is put the DLLs in the same directory as the executable=20
itself. There's no need to relink: the same executable and same libraries a=
re=20
valid for uninstalled- and installed-execution. We do place them all in bin=
/,=20
don't we?

=46or IRIX, it looks like DT_RUNPATH is not supported. It's not mentioned=20
anywhere in the ld(1) or rld(5) manuals.

The same seems to apply to HP-UX.

=46or Solaris, it's using DT_RUNPATH on normal builds (Solaris 9 tested).

> I don't think CMake right now supports setting only RUNPATH but not RPATH
> due to this. Even if it would be implemented today, it wouldn't help us
> since we require CMake 2.4.5 for KDE 4.0.x.

There's no way to set only RUNPATH (without RPATH) without modifying the=20
linker. But this is not anything that affects us: if DT_RUNPATH is present,=
=20
the DT_RPATH entry *must* be ignored by the dynamic linker.

So, the search order is this, on ELF platforms:
	RPATH, unless RUNPATH is present
	system-specific environment variables (LD_LIBRARY64_PATH, etc.)
	LD_LIBRARY_PATH
	RUNPATH
	system configuration
	system defaults

> Having something like install_name_tool would be nice :-)
> There is chrpath but this is not widely installed and works only if the n=
ew
> RPATH is not longer than the original one, so it would need some support
> from the linker, so enough space is reserved. OS X does that.

I guess there's also a third option, which is what libtool used to do:

	relink at uninstalled-run-time

That is, if a program is run from inside its build tree, it's automatically=
=20
relinked against the proper libraries.

So, let me summarise what I am proposing:

=2D on AIX: always relink at install time, regardless of any CMake settings
=2D on MacOS X: install_name_tool
=2D on Windows: no action necessary - at most, set PATH
=2D on ELF platforms with DT_RUNPATH (Solaris, Linux, BSDs):
  set LD_LIBRARY_PATH from a shell script and exec
  no relinking necessary
=2D on ELF platforms without DT_RUNPATH (IRIX, HP-UX):
  RUN_UNINSTALLED executables are relinked at install time

Also note that "link at install time" should mean "link twice at compile ti=
me"=20
(except for AIX, where you *need* to install the libraries before you can=20
link the executable), since you can run the executable in the build tree=20
after installation.

=2D-=20
=A0 Thiago Macieira =A0- =A0thiago (AT) macieira.info - thiago (AT) kde.org
=A0 =A0 PGP/GPG: 0x6EF45358; fingerprint:
=A0 =A0 E067 918B B660 DBD1 105C =A0966C 33F5 F005 6EF4 5358

--nextPart1569811.4JkjumA5Ye
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBHJv56M/XwBW70U1gRAobZAKCUaITodh/QwpK1VgK3KKdI2DHiwACgjJyI
nyjjjhsZLeT2WQfdCTX8jtc=
=TSKx
-----END PGP SIGNATURE-----

--nextPart1569811.4JkjumA5Ye--

--===============0395620210==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

--===============0395620210==--