bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gnulib] new module lib-ignore; new section build_lib in MODULES


From: Paul Eggert
Subject: Re: [bug-gnulib] new module lib-ignore; new section build_lib in MODULES.html
Date: Wed, 11 Jan 2006 10:14:26 -0800
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

Bruno Haible <address@hidden> writes:

> The problem is brought in by the fact that we build a single libgnulib or
> libcoreutils for all executables of a package, and if a single function
> in this library needs, say, high-resolution timers, the libgnulib or
> libcoreutils has "-lrt" in its link specification.

That's what leads to the problem here, but the problem can occur even
if we don't build a libgnulib.  For example, a package might not need
any gnulib .o files at all, but it still might invoke something like
gl_CLOCK_TIME, which merely sets LIB_CLOCK_GETTIME=-lrt and defines
HAVE_CLOCK_GETTIME.  If a package like that defines several programs,
only some of which call clock_gettime, then the maintainer will have
to do something like this (this is an extract from
coreutils/src/Makefile.am):

pr_LDADD = $(LDADD) $(LIB_CLOCK_GETTIME)
shred_LDADD = $(LDADD) $(LIB_GETHRXTIME) $(LIB_FDATASYNC)
sort_LDADD = $(LDADD) $(POW_LIB) $(LIB_GETHRXTIME)
...

where each program is carefully linked to each optionally-available
library it might use.

This sort of cataloging is error-prone and a pain to maintain.  It
should be automated, and -zignore does the automation.  (I don't know
why -zignore is not the default; but it isn't and we have to deal with
it.)

> This uses 'ldd'. This command is OS dependent:
>
>    AIX:          dump -H
>    IRIX:         elfdump -Dl
>    HP-UX:        chatr
>    OSF/1, Tru64: odump -Dl
>    Solaris:      ldd
>    glibc-based:  ldd

Now that you mention it, there's also 'otool -L' on Mac OS X.

However, does the problem occur with the linkers used on AIX, IRIX,
HP-UX, OSF/1, and Tru64?  If not, then I'm not sure it's worth trying
all the possibilities.  But if so, I suppose we could install a
further patch that looks something like the following.  But this
raises Ralf Wildenhues's point: do these other linkers need some other
option, one that isn't spelled "-zignore"?

--- lib-ignore.m4.~1.1.~        2006-01-09 10:42:51.000000000 -0800
+++ lib-ignore.m4       2006-01-11 10:08:27.000000000 -0800
@@ -13,21 +13,29 @@ AC_DEFUN([gl_IGNORE_UNUSED_LIBRARIES],
     [gl_cv_ignore_unused_libraries],
     [gl_cv_ignore_unused_libraries=none
      AC_LINK_IFELSE([AC_LANG_PROGRAM()],
-       [gl_ldd_output0=`(ldd conftest$ac_exeext) 2>/dev/null` ||
-         gl_ldd_output0=])
+       [for gl_ldd in \
+               ldd \
+               'chatr' \
+               'dump -H' \
+               'elfdump -Dl' \
+               'odump -Dl' \
+               'otool -L' \
+               :; do
+         gl_ldd_output0=`($gl_ldd conftest$ac_exeext) 2>/dev/null` && break
+        done])
      if test "$gl_ldd_output0"; then
        gl_saved_ldflags=$LDFLAGS
        gl_saved_libs=$LIBS
        LIBS="$LIBS -lm"
        AC_LINK_IFELSE([AC_LANG_PROGRAM()],
-        [gl_ldd_output1=`(ldd conftest$ac_exeext) 2>/dev/null` ||
+        [gl_ldd_output1=`($gl_ldd conftest$ac_exeext) 2>/dev/null` ||
            gl_ldd_output1=])
        if test "$gl_ldd_output1" && test "$gl_ldd_output0" != "$gl_ldd_output1"
        then
         for gl_flags in '-Xlinker -zignore' '-zignore'; do
           LDFLAGS="$gl_flags $LDFLAGS"
           AC_LINK_IFELSE([AC_LANG_PROGRAM()],
-            [if gl_ldd_output2=`(ldd conftest$ac_exeext) 2>/dev/null` &&
+            [if gl_ldd_output2=`($gl_ldd conftest$ac_exeext) 2>/dev/null` &&
                 test "$gl_ldd_output0" = "$gl_ldd_output2"; then
                gl_cv_ignore_unused_libraries=$gl_flags
              fi])





reply via email to

[Prev in Thread] Current Thread [Next in Thread]