Albert Astals Cid <aa...@kde.org> writes: > El diumenge, 24 de setembre de 2017, a les 9:58:35 CEST, Carlos Garcia Campos > va escriure: >> Albert Astals Cid <aa...@kde.org> writes: >> > El dilluns, 11 de setembre de 2017, a les 20:52:31 CEST, Adrian Johnson va >> > >> > escriure: >> >> On 11/09/17 20:28, Albert Astals Cid wrote: >> >> > El diumenge, 10 de setembre de 2017, a les 20:39:18 CEST, Adrian >> >> > Johnson >> > >> > va escriure: >> >> >> One more problem I found with cmake. It does not set up the rpath for >> >> >> the install directory like autotools does. I sometimes have more than >> >> >> one version of poppler installed to different prefixes for testing >> >> >> purposes. With autotools I could just run any version without needing >> >> >> to >> >> >> change LD_LIBRARY_PATH for the version I want to run. >> >> > >> >> > Don't touch LD_LIBRARY_PATH at all, it already does what you want. >> >> > >> >> > tsdgeos@xps:~/devel/poppler/build-new:master$ ldd utils/pdfinfo | grep >> >> > poppler> >> >> > >> >> > libpoppler.so.70 => >> >> > /home/tsdgeos/devel/poppler/build-new/libpoppler.so.70 >> >> > (0x00007fc473d96000)> >> >> > >> >> > tsdgeos@xps:~/devel/poppler/build-new:master$ cd .. >> >> > tsdgeos@xps:~/devel/poppler:master$ cd build-old/ >> >> > tsdgeos@xps:~/devel/poppler/build-old:master$ ldd utils/pdfinfo | grep >> >> > poppler> >> >> > >> >> > libpoppler.so.70 => >> >> > /home/tsdgeos/devel/poppler/build-old/libpoppler.so.70 >> >> > (0x00007f6d96bdd000) >> >> >> >> Not after it has been installed. >> >> >> >> ~/usr/bin$ ldd ./pdfinfo | grep poppler >> >> >> >> libpoppler.so.70 => not found >> >> >> >> autotools sets the rpath to the install directory. >> > >> > This may be a silly question, but why do you need to install multiple >> > versions, just have different build dirs? >> > >> > rpath is evil since AFAIR it wins against LD_LIBRARY_PATH, *I* want to >> > have >> > the last word. >> >> This has broken my workflow, though. I was going crazy finding a >> regression, because I was getting always the same results for every >> revision I tried, until I figured out it was because the poppler glib >> demo in build dir was always using the installed poppler. I have poppler >> and many other things installed with jhbuild in a different prefix in my >> home. jhbuild uses LD_LIBRARY_PATH, so since it wins, when I try to run >> From build dir with jhbuild run glib/demo/poppler-glib-demo it always >> uses the installed libraries. This is the way I work in all other >> projects. If I run the demo without jhbuld run, then it correctly links >> to the libs in the buildir, but then it doesn't use my other libraries >> installed by jhbuild (cairo, pixman, etc.), so that's not a solution for >> me. I can't set LD_LIBRARY_PATH either, because jhbuild prepends its >> paths, and it would be quite inconvenient. In other projects I work, that >> use cmake, RPATH is set to the build directory, and removed by make >> install. When running from the build dir, 99% of the times you really >> want to use the built libraries from the build dir not the installed ones, >> so RPATH does the right thing. What I usually do the other 1% of the >> times I don't want this, is using LD_PRELOAD. > > I sincerely find this is more a limitation fo your tools than of our build > system, why is jhbuild adding the poppler LD_LIBRARY_PATH when running in > poppler? it seems to me if you're running a poppler too it should only add > the > dependencies of the libraries it needs, not of itself too.
jhbuild is adding its own prefix to LD_LIBRARY_PATH, in my case /home/carlos/gnome, where all my other modules are installed (including cairo and pixman). So, if I have previously installed poppler, when running poppler utils from build dir inside the jhbuild environment, the installed libraries are used, because LD_LIBRARY_PATH has precedence over RUNPATH. That's not the case of RPATH, I can run the poppler utils From build dir inside the jhbuild and the libs in the build dir will be used, while still using all my other libs from jhbuild. I think this is a common case, I bet I'm not the only one affected by this, just the one who noticed it (and noticed it the hard way). > Anyway if you can produce a patch that doesn't interfere with my workflow and > it helps both you and Adrian i guess we could commit it if noone else > disagrees. I have no idea how to do it, so I'll investigate when I find some more time. > Cheers, > Albert > >> >> > Cheers, >> > >> > Albert >> > >> >> > Cheers, >> >> > >> >> > Albert >> >> > >> >> > _______________________________________________ >> >> > poppler mailing list >> >> > poppler@lists.freedesktop.org >> >> > https://lists.freedesktop.org/mailman/listinfo/poppler >> >> >> >> _______________________________________________ >> >> poppler mailing list >> >> poppler@lists.freedesktop.org >> >> https://lists.freedesktop.org/mailman/listinfo/poppler >> > >> > _______________________________________________ >> > poppler mailing list >> > poppler@lists.freedesktop.org >> > https://lists.freedesktop.org/mailman/listinfo/poppler > > > _______________________________________________ > poppler mailing list > poppler@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/poppler -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462
signature.asc
Description: PGP signature
_______________________________________________ poppler mailing list poppler@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/poppler
