bug-gnulib
[Top][All Lists]
Advanced

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

relocwrapper interaction with replacement functions


From: Ben Pfaff
Subject: relocwrapper interaction with replacement functions
Date: Mon, 07 Jun 2010 23:16:07 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

On OpenBSD 4.7, GNU PSPP from current "master" configured with
--enable-relocatable fails linking relocwrapper.c at "make
install" time:

    /tmp//ccy8gNb6.o(.text+0x64): In function `add_dotbin':
    gl/relocwrapper.c:105: undefined reference to `rpl_fprintf'
    /tmp//ccy8gNb6.o(.text+0x172): In function `activate_libdirs':
    gl/relocwrapper.c:165: undefined reference to `rpl_fprintf'
    /tmp//ccy8gNb6.o(.text+0x1f9): In function `main':
    gl/relocwrapper.c:189: undefined reference to `rpl_fprintf'
    /tmp//ccHe4GuE.o(.text+0xe9): In function `set_relocation_prefix':
    gl/relocatable.c:154: undefined reference to `libintl_set_relocation_prefix'
    /tmp//ccIOlqzo.o(.text+0x3c): In function `rpl_strerror':
    gl/strerror.c:339: undefined reference to `rpl_sprintf'
    collect2: ld returned 1 exit status

One solution for the problems with the rpl_* symbols would be to
build the relocwrapper program in the usual way as part of a
Makefile.am, and then link it against the Gnulib library, so that
relocwrapper could take advantage of the wrappers.  I don't
actually know why it is not done that way already; I assume that
there must be good reason.  Maybe it is because the relocwrapper
passes special -D options when it compiles the source files, but
I think that Automake can handle that with per-target compilation
flags.

Another way would be to make the substitutions conditional on
!IN_RELOCWRAPPER, but that seems fragile for two reasons: first,
because Gnulib developers would need to be aware of the need to
check for IN_RELOCWRAPPER as they add more wrappers, and second,
because Gnulib developers would need to remember to avoid using
the features provided by the wrappers in contexts where the
wrappers might not always be present.

For libintl_set_relocation_prefix, I guess PSPP should just stop
using DEPENDS_ON_LIBINTL.  There is not much benefit to it
anyhow.

What do you think?

Thanks,

Ben.
-- 
Ben Pfaff 
http://benpfaff.org



reply via email to

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