| Message ID | 20160809144343.2228-1-vapier@gentoo.org (mailing list archive) |
|---|---|
| State | Rejected |
| Headers | show |
On Tue, Aug 09, 2016 at 10:43:43PM +0800, Mike Frysinger wrote: > Since this lib uses symbols from libxfs (platform_findsizes) and many > symbols from libblkid, link against both. Otherwise, the resulting > shared lib has missing symbols which makes linking against annoying. libxcmd is an internal library, linked directly into the xfsprogs binaries. It is never shipped or used outside xfsprogs, so what is trying to use libxcmd as a shared library that doesn't also link against libblkid or libxfs? Cheers, Dave.
On 10 Aug 2016 07:49, Dave Chinner wrote: > On Tue, Aug 09, 2016 at 10:43:43PM +0800, Mike Frysinger wrote: > > Since this lib uses symbols from libxfs (platform_findsizes) and many > > symbols from libblkid, link against both. Otherwise, the resulting > > shared lib has missing symbols which makes linking against annoying. > > libxcmd is an internal library, linked directly into the xfsprogs > binaries. It is never shipped or used outside xfsprogs, so what is > trying to use libxcmd as a shared library that doesn't also link > against libblkid or libxfs? shouldn't internal libs still have coherent linkage ? otherwise you cause problems even internally for xfs -- any other libs or progs that link against libxcmd have to list all the libs that libxcmd happen to use itself. it also means that you get correct link order which is otherwise not guaranteed. e.g. just because you say libxfs needs to use libblkid doesn't mean the linker must put that after libxcmd in the link list. -mike
On Wed, Aug 10, 2016 at 09:52:36AM +0800, Mike Frysinger wrote: > On 10 Aug 2016 07:49, Dave Chinner wrote: > > On Tue, Aug 09, 2016 at 10:43:43PM +0800, Mike Frysinger wrote: > > > Since this lib uses symbols from libxfs (platform_findsizes) and many > > > symbols from libblkid, link against both. Otherwise, the resulting > > > shared lib has missing symbols which makes linking against annoying. > > > > libxcmd is an internal library, linked directly into the xfsprogs > > binaries. It is never shipped or used outside xfsprogs, so what is > > trying to use libxcmd as a shared library that doesn't also link > > against libblkid or libxfs? > > shouldn't internal libs still have coherent linkage ? otherwise you > cause problems even internally for xfs -- any other libs or progs that > link against libxcmd have to list all the libs that libxcmd happen to > use itself. AFAIK, only if the libs or progs actually call the functions that result in those dependencies being needed, right? i.e. it's not dynamically linked, so functions that aren't called are culled by the linker and so the undefined references to libxfs and libblkid are culled and don't need to be resolved. Hence the program only needs to be linked against libblkid/libxfs if they are required, right? See, for example, xfs_quota. quota/Makefile defines: LLDLIBS = $(LIBXCMD) LTDEPENDENCIES = $(LIBXCMD) LLDFLAGS = -static and the built binary: $ ldd quota/xfs_quota linux-vdso.so.1 (0x00007ffc0dae6000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdf92114000) /lib64/ld-linux-x86-64.so.2 (0x00005640768d0000) $ i.e. it has no link-time or run-time dependency on libxfs or libblkid, because it doesn't use any functions from libxcmd that require those libraries to be linked in. > otherwise not guaranteed. e.g. just because you say libxfs needs to > use libblkid doesn't mean the linker must put that after libxcmd in > the link list. No, but link order is defined by the order of libraries on the linker command line and we control that directly. See the ld man page: ... -l namespec .... The linker will search an archive only once, at the location where it is specified on the command line. If the archive defines a symbol which was undefined in some object which appeared before the archive on the command line, the linker will include the appropriate file(s) from the archive. However, an undefined symbol in an object appearing later on the command line will not cause the linker to search the archive again. See the -( option for a way to force the linker to search archives multiple times. ..... -( archives -) ..... The specified archives are searched repeatedly until no new undefined references are created. [....] ..... So we can define the link order exactly as we need it on the linker command line, or we can just say "just search everything" if we have cyclic dependencies that need to be resolved. Cheers, Dave.
diff --git a/libxcmd/Makefile b/libxcmd/Makefile index aab8d6d63624..46ba138a37e2 100644 --- a/libxcmd/Makefile +++ b/libxcmd/Makefile @@ -12,6 +12,8 @@ LT_AGE = 0 CFILES = command.c input.c paths.c projects.c help.c quit.c topology.c +LTLIBS = $(LIBXFS) $(LIBBLKID) + ifeq ($(HAVE_GETMNTENT),yes) LCFLAGS += -DHAVE_GETMNTENT endif
Since this lib uses symbols from libxfs (platform_findsizes) and many symbols from libblkid, link against both. Otherwise, the resulting shared lib has missing symbols which makes linking against annoying. Signed-off-by: Mike Frysinger <vapier@gentoo.org> --- libxcmd/Makefile | 2 ++ 1 file changed, 2 insertions(+)