[Top][All Lists]
[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
- relocwrapper interaction with replacement functions,
Ben Pfaff <=
- Re: relocwrapper interaction with replacement functions, Bruno Haible, 2010/06/08
- Re: relocwrapper interaction with replacement functions, Ben Pfaff, 2010/06/09
- Re: relocwrapper interaction with replacement functions, Bruno Haible, 2010/06/09
- Re: relocwrapper interaction with replacement functions, Eric Blake, 2010/06/09
- Re: [1/4] setenv, relocwrapper interaction with replacement functions, Bruno Haible, 2010/06/09
- Re: [2/4] relocwrapper interaction with replacement functions, Bruno Haible, 2010/06/09
- Re: [3/4] areadlink, relocwrapper interaction with replacement functions, Bruno Haible, 2010/06/09
- Re: [3/4] areadlink, relocwrapper interaction with replacement functions, Jim Meyering, 2010/06/09
- Re: relocwrapper interaction with replacement functions, Ben Pfaff, 2010/06/09