--===============0599820079== Content-Type: multipart/signed; boundary="nextPart2551299.SylMWxBUV0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart2551299.SylMWxBUV0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Em Tuesday 30 October 2007 11:23:27 Alexander Neundorf escreveu: > > So in a typical Qt build, qstring.cpp is compiled 5 times: once for > > QtCore, then one more time per tool (moc, uic, rcc and qmake). > > Sure ? How about creating a static lib for these tools ? > While seems to be a good approach, do we want that for KDE ? I doubt that, > there are several generators, not only in kdelibs. We'd probably need a complete overhaul of the Qt buildsystem, which is not= =20 planned for the near future. Not to mention that some .cpp files are built with different options turnin= g=20 Qt features off, so as to reduce executable size. > > So, when building a RUN_UNINSTALLED program, it is linked with full rpa= th > > to the build tree and full library list. That way, all libraries will be > > found in the build tree, even if the libraries themselves don't know > > anything about RUN_UNINSTALLED. > > Apparently not. If app A links to soprano (or another 3rd party library), > and the soprano cmake module just sets > SET(SOPRANO_LIBS /opt/soprano/lib/libsoprano.so) Stop. That's an installed library. It doesn't count. We're talking about running uninstalled applications that link to uninstall= ed=20 libraries. Linking to installed libraries has never been a problem -- the=20 RPATH to the install tree is present anyways. > then A will link just to that and not know about other libraries > libsoprano.so links to (and their directories, which are required for the > RPATH). If libsoprano.so doesn't find its libraries without RPATH (or > RUNPATH), there are two options: Again, stop. libsoprano.so's dependencies are loaded by libsoprano.so itsel= f,=20 not by the application. So it's the dependent library's job to find the=20 libraries the right way (environment variable, ld.so.conf modification,=20 RPATH, whatever). > 1) it needs an RPATH itself [snip] > The first option sounds much better to me. Yes, but that's true of all dependencies, regardless of whether they were=20 compiled with CMake or not. So, the point is: we cannot fix a library that = is=20 already installed. Either it knows how to find its libraries, or=20 linking/running will fail. In any case, it's not our fault. > If the library comes from within the same build tree, CMake should add all > the directories for the RPATH. Great. But the point here is: - you're building application APP - APP links to libONE - libONE links to libTWO So APP should be linked twice: install version: =20 gcc -o APP.final -lONE -L$buildtree/lib -Wl,--rpath,$prefix/lib run-uninstalled version: gcc -o APP -lONE -lTWO -L$buildtree/lib \ -Wl,--rpath,$buildtree/lib:$prefix/lib If -lTWO appears in the install version, it won't cause any harm. > > As for Win32's COFF Portable Executable format, the interesting thing is > > that all we need to do is put the DLLs in the same directory as the > > executable itself. There's no need to relink: the same executable and > > same libraries are valid for uninstalled- and installed-execution. We do > > place them all in bin/, don't we? > > We don't, see the lengthy discussion on k-c-d and here about it. We may do > it or KDE 4.1. Setting PATH is required or the installer has to do it. Well, then I'm ready to say our Windows support is "shaky at best" and runn= ing=20 the tools may fail at any time, including during compilation. If we're goin= g=20 to place files in their correct places only starting with KDE 4.1, then we'= re=20 tabling this discussion. > > There's no way to set only RUNPATH (without RPATH) without modifying the > > linker. But this is not anything that affects us: if DT_RUNPATH is > > present, the DT_RPATH entry *must* be ignored by the dynamic linker. > > Ah, I didn't know that. > So if enable-new-dtags is in the link flags, -Wl,-rpath sets the RUNPATH > instead of the RPATH ? No, it sets both. But RUNPATH overrides RPATH. (Cyclic overriding: RUNPATH overrides RPATH, LD_LIBRARY_PATH overrides=20 RUNPATH, RPATH overrides LD_LIBRARY_PATH :->) > > 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 > > - on AIX: always relink at install time, regardless of any CMake settin= gs > > I would just assume that CMake does the right thing, Kitware builds almost > all of their projects/products on almost all platforms, e.g. VTK is built > every night also on AIX. > The first person who will try to build KDE4 on AIX will tell us :-) Well, until today we didn't know our Qt builds in AIX hardcoded the build t= ree=20 paths into the final executable. I had to open the executables in khexedit = to=20 see that. > > - on ELF platforms without DT_RUNPATH (IRIX, HP-UX): > > RUN_UNINSTALLED executables are relinked at install time > > This could make some things easier, I think we could even completely get > rid of the RUN_UNINSTALLED argument. Everything, apps and libs would get > the full RPATH (RUNPATH) for the install tree, the shell scripts which set > LD_LIBRARY_PATH are created anyway. That's what I proposed for the platforms using DT_RUNPATH. But mind you: th= e=20 real target (the ELF executable) should have a different name -- the shell= =20 script should have the target's name inside the build tree. > I'd consider AIX, IRIX and HP-UX not our main target platforms, so I'd say > it shouldn't be too much of a problem if on these platforms relinking > always happens, for everything which has an RPATH. Agreed. > P.S. actually the platform is intended to be frozen, and this is a > significant change... Things are working fine as-is for me, using the FULL_RPATH option. Almost n= o=20 one has complained about this problem for the several months since we've la= st=20 discussed RPATH. =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 --nextPart2551299.SylMWxBUV0 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) iD8DBQBHJy2BM/XwBW70U1gRAnvCAJ91CHDLha4NgMjOFSQmWzhmyLhxzgCdGQOC iwpUsQUVRQgEXzGE6op0cBE= =rNbc -----END PGP SIGNATURE----- --nextPart2551299.SylMWxBUV0-- --===============0599820079== 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 --===============0599820079==--