GNOME Bugzilla – Bug 586675
Runtime library location
Last modified: 2009-06-23 17:04:21 UTC
Some distros, such as Fedora (and probably others), installs the runtime libraries (e.g. libglib-2.0.so.0 and libglib-2.0.so.0.2103.0) from the GLib tarball into /lib instead of /usr/lib (while keeping libglib-2.0.so used for development in /usr/lib). This is because programs running before /usr is mounted are using GLib. Anyway, this makes it hard to hack on GLib the usual way we all know and love, e.g. 1. CFLAGS="-O0 -g" ./autogen.sh --prefix=/usr --sysconfdir=/etc \ --localstatedir=/var --libdir=/usr/lib64 2. make && sudo make install I will attach a patch that introduces a --with-runtime-libdir option so you can pass a (relative) path to the location where to install the runtime libraries, e.g. 1. CFLAGS="-O0 -g" ./autogen.sh --prefix=/usr --sysconfdir=/etc \ --localstatedir=/var --libdir=/usr/lib64 \ --with-runtime-libdir=../../lib64
Created attachment 137199 [details] [review] Proposed patch
Created attachment 137200 [details] Installed tree with this patch Sources were configured this way ./autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var \ --libdir=/usr/lib64 --with-runtime-libdir=../../lib64
Btw, the reason we're asking for a relative path instead of an absolute path is that - We want the symlink in /usr/lib64/libglib-2.0.so -> TARGET to be relative (otherwise some build systems might complain when installing to DESTDIR) - I don't know of any good portable equivalent (e.g. sh(1)) of Python's os.path.relpath() function
This feels like a generic autoconf->automake->libtool idea. Do they have any thoughts about it before going ahead with a home-grown solution?
(In reply to comment #4) > This feels like a generic autoconf->automake->libtool idea. Do they have any > thoughts about it before going ahead with a home-grown solution? All other projects (udev, glibc etc) with these needs roll their own. If autoconf/automake/libtool can do this in the future, we can always switch to it. For now, it solves a very real (and annoying) problem.
Looks very good to me. Thanks for doing that. Note that we have a section explaining all non-standard configure options in docs/reference/glib/building.sgml. Can you add a paragraph about the new option there when you commit this ?
(In reply to comment #5) > (In reply to comment #4) > > This feels like a generic autoconf->automake->libtool idea. Do they have any > > thoughts about it before going ahead with a home-grown solution? > > All other projects (udev, glibc etc) with these needs roll their own. If > autoconf/automake/libtool can do this in the future, we can always switch to > it. For now, it solves a very real (and annoying) problem. > Makes good sense. Hadn't looked at others.
(In reply to comment #6) > Looks very good to me. Thanks for doing that. > > Note that we have a section explaining all non-standard configure options in > docs/reference/glib/building.sgml. Can you add a paragraph about the new option > there when you commit this ? > Sure, I added some docs before committing: http://git.gnome.org/cgit/glib/commit/?id=0ccd18bc83c5e6eff77940a61cc9b31a88dd1851 Thanks for the review.