Re: relocwrapper interaction with replacement functions

2010-06-08 Thread Bruno Haible
Hi Ben,

> 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.

But that would require extra Makefile.am rules that the developer has to
write. The --enable-relocatable mechanism tries hard to get away with minimal
changes to the Makefile.am:


Therefore I would suggest to solve this problem by adding #undefs in
specific places, such as

/* Use the system functions, not the gnulib overrides in this file.  */
#undef fprintf
#undef sprintf

What is the complete required symbol list (nm ...o | grep ' U ') of the set
of modules compiled for the relocwrapper on your system?

> Another way would be to make the substitutions conditional on
> !IN_RELOCWRAPPER, but that seems fragile

Yes, this would be fragile. But maybe we need this approach for the
set_relocation_prefix functions.

Bruno



Re: [bug-inetutils] inetutils-1.8: ftp build error

2010-06-08 Thread Giuseppe Scrivano
Hello,

I am forwarding an error reported on the inetutils mailing list.

The problem is that readline 6.x exports `xmalloc' and `xrealloc', and
it causes a linker error when used together with gnulib.

Probably readline shouldn't export these symbols, but I think it should
be possible somehow to workaround this problem in gnulib as well.

What do you think?

Cheers,
Giuseppe



Jimi  writes:

> Hello,
>
> When I try to build the ftp binary included in the inetutils package, I
> encounter an error. It appears to be related to libreadline's reference of
> xmalloc.
>
> Here are the arguments passed during the configuration stage:
> ./configure --prefix=/usr --libexecdir=/usr/sbin --sysconfdir=/etc
> --localstatedir=/var --disable-logger --disable-syslogd --disable-whois
> --disable-servers


This is the relevant part of the build log:

/usr/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../libreadline.a(xmalloc.o): In 
function `xmalloc':
/usr/src/readline/xxxbuild/yyysrc/xmalloc.c:58: multiple definition of `xmalloc'
../lib/libgnu.a(xmalloc.o):/usr/src/inetutils/xxxbuild/yyysrc/lib/xmalloc.c:44: 
first defined here
/usr/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../libreadline.a(xmalloc.o): In 
function `xrealloc':
/usr/src/readline/xxxbuild/yyysrc/xmalloc.c:71: multiple definition of 
`xrealloc'
../lib/libgnu.a(xmalloc.o):/usr/src/inetutils/xxxbuild/yyysrc/lib/xmalloc.c:56: 
first defined here
collect2: ld returned 1 exit status
make[2]: Leaving directory `/usr/src/inetutils/xxxbuild/inetutils-1.8/ftp'
make[1]: Leaving directory `/usr/src/inetutils/xxxbuild/inetutils-1.8'
make[2]: *** [ftp] Error 1



Re: check-news target fails if NEWS file starts with a copyright header

2010-06-08 Thread Peter Simons
Hi Jim,

 > How about removing the use of "head" and using this as the default:
 >
 > sed -n 1,10p

yes, that is a really good idea.

Take care,
Peter


>From b0e59e16e848f5a6f65fb2a8d5cb16a5355a8a37 Mon Sep 17 00:00:00 2001
From: Peter Simons 
Date: Mon, 7 Jun 2010 15:24:21 +0200
Subject: [PATCH] Introduced the $(news-check-lines-spec) variable in maint.mk.

$(news-check-lines-spec) determines the range of lines inspected by
the 'news-check' target to ensure that the NEWS file is up-to-date.
The default value is "1,10", meaning that any of lines 1 to 10 must
match $(news-check-regexp) for the test to succeed.
---
 ChangeLog|8 
 top/maint.mk |5 +++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 3eb9e3a..ca5b2ff 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2010-06-08  Peter Simons  
+
+* top/maint.mk: Introduced the variable $(news-check-lines-spec) to
+determine the range of lines inspected by the 'news-check' target to
+ensure that the NEWS file is up-to-date. The default value is "1,10",
+meaning that any of lines 1 to 10 must match $(news-check-regexp) for
+the test to succeed.
+
 2010-06-07  Jim Meyering  
 
do-release-commit-and-tag: fix typo in --help
diff --git a/top/maint.mk b/top/maint.mk
index 644fbb6..f7c4ddd 100644
--- a/top/maint.mk
+++ b/top/maint.mk
@@ -104,6 +104,7 @@ endif
 # NEWS file.
 today = $(shell date +%Y-%m-%d)
 news-check-regexp ?= '^\*.* $(VERSION_REGEXP) \($(today)\)'
+news-check-lines-spec ?= 1,10
 
 # Prevent programs like 'sort' from considering distinct strings to be equal.
 # Doing it here saves us from having to set LC_ALL elsewhere in this file.
@@ -874,8 +875,8 @@ sc_makefile_at_at_check:
  && { echo '$(ME): use $$(...), not @...@' 1>&2; exit 1; } || :
 
 news-check: NEWS
-   if head $(srcdir)/NEWS | grep -E $(news-check-regexp)   \
-   >/dev/null; then\
+   if sed -n $(news-check-lines-spec)p $(srcdir)/NEWS  \
+   | grep -E $(news-check-regexp) >/dev/null; then \
  :;\
else\
  echo 'NEWS: $$(news-check-regexp) failed to match' 1>&2;  \
-- 
1.7.1



Re: [PATCH] describe --local-dir option in documentation

2010-06-08 Thread Bruno Haible
Hi Ben,

> I couldn't find a description of how or why to use --local-dir,
> so I wrote this up.

The original documentation of the feature was in my announcement at
.
Maybe you can look to combine the contents of that text with yours?

> * doc/gnulib-tool.texi (Local changes): New section.

IMO these explanations should go in a new chapter, "Extending Gnulib",
positioned between "Writing modules" and "Miscellaneous Notes".
It's important enough to be a chapter of its own, and the user first
has to have a minimal understanding how to write modules of his own before
he can use --local-dir.

> + * doc/gnulib-intro.texi (Openness): Add cross-reference to new
> + section.

Good. Another cross-reference could be added to the intro of the
chapter "Writing modules".

Bruno



Re: [bug-inetutils] inetutils-1.8: ftp build error

2010-06-08 Thread Bruno Haible
Hi,

Giuseppe Scrivano wrote:
> The problem is that readline 6.x exports `xmalloc' and `xrealloc', and
> it causes a linker error when used together with gnulib.

According to what Chet Ramey said in
  
it should be possible to override 'xmalloc' and 'xrealloc' in gnulib, and
libreadline should then use the definitions from gnulib. Recall that gnulib
links statically into the program; gnulib is not compiled into a shared
library.

Bruno



Re: check-news target fails if NEWS file starts with a copyright header

2010-06-08 Thread Jim Meyering
Peter Simons wrote:
>  > How about removing the use of "head" and using this as the default:
>  >
>  > sed -n 1,10p
>
> yes, that is a really good idea.

Thanks for the patch.

I've adjusted that to move comments from the log into maint.mk,
where future users will be more likely to read them.
Once you've done that, "(news-check-lines-spec): New variable."
is all you need to say about the new variable in the log.

Any additional comments or suggestions?
I'll push this later today.

>From 296be6b6babfbe14109df50aa22488dc05ccc878 Mon Sep 17 00:00:00 2001
From: Peter Simons 
Date: Mon, 7 Jun 2010 15:24:21 +0200
Subject: [PATCH] maint.mk: make the news-check rule more configurable

* top/maint.mk (news-check-lines-spec) New variable.
(news-check): Use "sed -n 1,10p" in place of "head".
---
 ChangeLog|6 ++
 top/maint.mk |   10 --
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 3eb9e3a..edb9122 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-06-08  Peter Simons  
+
+   maint.mk: make the news-check rule more configurable
+   * top/maint.mk (news-check-lines-spec) New variable.
+   (news-check): Use "sed -n 1,10p" in place of "head".
+
 2010-06-07  Jim Meyering  

do-release-commit-and-tag: fix typo in --help
diff --git a/top/maint.mk b/top/maint.mk
index 644fbb6..59e9cb5 100644
--- a/top/maint.mk
+++ b/top/maint.mk
@@ -103,6 +103,12 @@ endif
 # Override this in cfg.mk if you are using a different format in your
 # NEWS file.
 today = $(shell date +%Y-%m-%d)
+
+# Select which lines of NEWS are searched for $(news-check-regexp).
+# This is a sed line number spec.  The default says that we search
+# lines 1..10 of NEWS for $(news-check-regexp).
+# If you want to search only line 3 or only lines 20-22, use "3" or "20,22".
+news-check-lines-spec ?= 1,10
 news-check-regexp ?= '^\*.* $(VERSION_REGEXP) \($(today)\)'

 # Prevent programs like 'sort' from considering distinct strings to be equal.
@@ -874,8 +880,8 @@ sc_makefile_at_at_check:
  && { echo '$(ME): use $$(...), not @...@' 1>&2; exit 1; } || :

 news-check: NEWS
-   if head $(srcdir)/NEWS | grep -E $(news-check-regexp)   \
-   >/dev/null; then\
+   if sed -n $(news-check-lines-spec)p $(srcdir)/NEWS  \
+   | grep -E $(news-check-regexp) >/dev/null; then \
  :;\
else\
  echo 'NEWS: $$(news-check-regexp) failed to match' 1>&2;  \
--
1.7.1.501.g23b46



Re: check-news target fails if NEWS file starts with a copyright header

2010-06-08 Thread Peter Simons
Hi Jim,

 > Any additional comments or suggestions?

no, I'm happy with the end result. Thank you.

Take care,
Peter




Re: [Bug-readline] Re: [bug-inetutils] inetutils-1.8: ftp build error

2010-06-08 Thread Chet Ramey
On 6/8/10 5:20 AM, Bruno Haible wrote:
> Hi,
> 
> Giuseppe Scrivano wrote:
>> The problem is that readline 6.x exports `xmalloc' and `xrealloc', and
>> it causes a linker error when used together with gnulib.
> 
> According to what Chet Ramey said in
>   
> it should be possible to override 'xmalloc' and 'xrealloc' in gnulib, and
> libreadline should then use the definitions from gnulib. Recall that gnulib
> links statically into the program; gnulib is not compiled into a shared
> library.

There are two important things to remember: linking happens beginning to
end on the command line, and the linker works at file scope.

The first means that if an application provides its own definition of
xmalloc/xrealloc/xfree, or somehow arranges for those symbols to be
defined by the time readline is linked, readline's version will not be
included.

The second thing is that the linker works on files: when it links a file
that provides a particular function definition, all functions in that file
are linked.  The gnulib interface defines many more functions than the
readline one: x2realloc, xcalloc, xzalloc, etc.  If the application or
gnulib itself uses any of those `extra' functions, the entire file from
gnulib will be linked in, and you'll get a redefined symbol error.

The first can be solved by putting definitions for xmalloc/xrealloc/xfree
into the program's code or changing the makefile so that gnulib is linked
before readline.  That will probably work for the second also, but if it
doesn't, I don't know if the second can be solved without taking gnulib's
xmalloc.c and adding it to the list of ftp's source/object files.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/



Re: bug#6053: cp, ls, and mv bug: unknown error (252)

2010-06-08 Thread Jim Meyering
Callahan, Patrick M. wrote:
> Pádraig Brady wrote:
>> Callahan, Patrick M. wrote:
>> > When using coreutils binaries either built from sources or installed
>> > from the Porting And Archive Centre for HP-UX we see errors of the type
>> > below when copying (cp), listing (ls), or moving (mv) files or
>> > directories on Quantum's StorNext file system (cvfs).  When we build
>> > "--without-acl" we do not see these errors.
>> >
>> >> mv SEG_5_1* ~/release-input/dev-to-integration
>> > mv: preserving permissions for
>> > `/usr/people/archive/release-input/dev-to-integation/SEG_5_1.txt':
>> > Unknown error (252)

Thanks for the details.
Do you care about ACLs?
If not, then building --without-acl should be fine.

If you do require that ACLs be preserved in general,
then more work will be required.  The code in question is
probably part of gnulib, in copy-acl.c.  There, we already
ignore failure due to conditions that imply lack of support:

if ((errno == ENOSYS || errno == EOPNOTSUPP)
...
if ((errno == ENOSYS || errno == EINVAL || errno == ENOTSUP)

But that the errno value in question, 252, does not map
to a strerror string is ominous.  Could it be that your version
of HP-UX's C library is lacking patches that might provide that?

You could get in a debugger and determine where
to add "|| errno == 252" to solve what appears to be
an HP-UX-and/or-cvfs-specific problem.

However, such a change is not appropriate for others,
and I doubt it will be worthwhile to attempt an
upstream workaround.



Re: bug#6053: cp, ls, and mv bug: unknown error (252)

2010-06-08 Thread Pádraig Brady
On 08/06/10 21:51, Jim Meyering wrote:
> Callahan, Patrick M. wrote:
>> Pádraig Brady wrote:
>>> Callahan, Patrick M. wrote:
 When using coreutils binaries either built from sources or installed
 from the Porting And Archive Centre for HP-UX we see errors of the type
 below when copying (cp), listing (ls), or moving (mv) files or
 directories on Quantum's StorNext file system (cvfs).  When we build
 "--without-acl" we do not see these errors.

> mv SEG_5_1* ~/release-input/dev-to-integration
 mv: preserving permissions for
 `/usr/people/archive/release-input/dev-to-integation/SEG_5_1.txt':
 Unknown error (252)
> 
> Thanks for the details.
> Do you care about ACLs?
> If not, then building --without-acl should be fine.
> 
> If you do require that ACLs be preserved in general,
> then more work will be required.  The code in question is
> probably part of gnulib, in copy-acl.c.  There, we already
> ignore failure due to conditions that imply lack of support:
> 
> if ((errno == ENOSYS || errno == EOPNOTSUPP)
> ...
> if ((errno == ENOSYS || errno == EINVAL || errno == ENOTSUP)
> 
> But that the errno value in question, 252, does not map
> to a strerror string is ominous.  Could it be that your version
> of HP-UX's C library is lacking patches that might provide that?
> 
> You could get in a debugger and determine where
> to add "|| errno == 252" to solve what appears to be
> an HP-UX-and/or-cvfs-specific problem.
> 
> However, such a change is not appropriate for others,
> and I doubt it will be worthwhile to attempt an
> upstream workaround.

Well a quick search says ENOTSUP is 252 on HPUX which is
different to EOPNOTSUPP. So perhaps we need to check
for both these errors in the if statements above.
I've mentioned before about amalgamating various errnos
when testing for "not supported", but it seems dubious
to not treat ENOTSUP and EOPNOTSUPP as synonymous at least.

strerror(252) = "unknown" on HPUX is strange

cheers,
Pádraig.



Re: [PATCH] describe --local-dir option in documentation

2010-06-08 Thread Ben Pfaff
Bruno Haible  writes:

>> I couldn't find a description of how or why to use --local-dir,
>> so I wrote this up.
>
> The original documentation of the feature was in my announcement at
> .
> Maybe you can look to combine the contents of that text with yours?

Thanks, I hadn't known about this announcement.  I combined the
texts.

I added your name to the ChangeLog entry since a lot of the
wording is derived from yours now.

>> * doc/gnulib-tool.texi (Local changes): New section.
>
> IMO these explanations should go in a new chapter, "Extending Gnulib",
> positioned between "Writing modules" and "Miscellaneous Notes".
> It's important enough to be a chapter of its own, and the user first
> has to have a minimal understanding how to write modules of his own before
> he can use --local-dir.

OK, done.

>> +* doc/gnulib-intro.texi (Openness): Add cross-reference to new
>> +section.
>
> Good. Another cross-reference could be added to the intro of the
> chapter "Writing modules".

Thanks.

I'm appending the revised version.  What do you think?

Thanks,

Ben.

--8<--cut here-->8--

>From 6d81a7b937aebc508f8f571c935d59b658436556 Mon Sep 17 00:00:00 2001
From: Ben Pfaff 
Date: Tue, 8 Jun 2010 21:13:20 -0700
Subject: [PATCH] Update 'gnulib-tool' documentation.

* doc/gnulib.texi (Writing Modules): Add cross-reference to new chapter.
(Extending Gnulib): New chapter.
* doc/gnulib-intro.texi (Openness): Add cross-reference to new chapter.
---
 ChangeLog |   10 ++
 doc/gnulib-intro.texi |4 +-
 doc/gnulib.texi   |   81 +++-
 3 files changed, 91 insertions(+), 4 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 40bd312..4097eb3 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2010-06-07  Ben Pfaff  
+Bruno Haible  
+
+   Update 'gnulib-tool' documentation.
+   * doc/gnulib.texi (Writing Modules): Add cross-reference to new
+   chapter.
+   (Extending Gnulib): New chapter.
+   * doc/gnulib-intro.texi (Openness): Add cross-reference to new
+   chapter.
+
 2010-05-23  Ben Pfaff  
 
Update maintainer documentation for 'relocatable-prog' module.
diff --git a/doc/gnulib-intro.texi b/doc/gnulib-intro.texi
index 4cb86b8..52191ec 100644
--- a/doc/gnulib-intro.texi
+++ b/doc/gnulib-intro.texi
@@ -346,5 +346,5 @@ locally add modules that are treated like Gnulib modules by
 @code{gnulib-tool}.
 @end enumerate
 
-This is achieved by the @samp{--local-dir} option of @code{gnulib-tool}.
-
+This is achieved by the @samp{--local-dir} option of @code{gnulib-tool}
+(@pxref{Extending Gnulib}).
diff --git a/doc/gnulib.texi b/doc/gnulib.texi
index 4cbc9e7..5af6cd8 100644
--- a/doc/gnulib.texi
+++ b/doc/gnulib.texi
@@ -54,6 +54,7 @@ Documentation License''.
 * Introduction::
 * Invoking gnulib-tool::
 * Writing modules::
+* Extending Gnulib::
 * Miscellaneous Notes::
 * POSIX Substitutes Library::   Building as a separate substitutes library.
 * Header File Substitutes:: Overriding system headers.
@@ -117,8 +118,8 @@ Resources:
 @node Writing modules
 @chapter Writing modules
 
-This chapter explains how to write modules of your own, either for your own
-package (to be used with gnulib-tool's @samp{--local-dir} option), or for
+This chapter explains how to write modules of your own, either to
+extend Gnulib for your own package (@pxref{Extending Gnulib}), or for
 inclusion in gnulib proper.
 
 The guidelines in this chapter do not necessarily need to be followed for
@@ -608,6 +609,82 @@ before every release.
 @end enumerate
 
 
+...@node Extending Gnulib
+...@chapter Extending Gnulib
+
+Gnulib modules are intended to be suitable for widespread use.  Most
+problems with Gnulib can and should be fixed in a generic way, so that
+all of Gnulib's users can benefit from the change.  But occasionally a
+problem arises that is difficult or undesirable to fix generically, or
+a project that uses Gnulib may need to work around an issue before the
+Gnulib maintainers commit a final fix.  Maintainers may also want to
+add their own pools of modules to projects as Gnulib ``staging
+areas.''
+
+The obvious way to make local changes to Gnulib modules is to use
+...@command{gnulib-tool} to check out pristine modules, then to modify
+the results in-place.  This works well enough for short-lived
+experiments.  It is harder to keep modified versions of Gnulib modules
+for a long time, even though Git (or another distributed version
+control systems) can help out a lot with this during the development
+process.
+
+Git, however, doesn't address the distribution issue.  When a package
+``foobar'' needs a modified version of, say, @file{stdint_.h}, it
+either has to put a comment into @file{foobar/autogen.sh} saying
+``Attention! This doesn't work with a pristine Gnulib, you need this
+and that patch after chec

Re: relocwrapper interaction with replacement functions

2010-06-08 Thread Ben Pfaff
Bruno Haible  writes:

>> 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.
>
> But that would require extra Makefile.am rules that the developer has to
> write. The --enable-relocatable mechanism tries hard to get away with minimal
> changes to the Makefile.am:
> 

To demonstrate what I meant, I spent a bit of time working on
modules/relocatable-prog-wrapper, coming up with this:

Makefile.am:
if !RELOCATABLE_VIA_LD
noinst_PROGRAMS += reloc-wrapper
reloc_wrapper_CPPFLAGS = \
-I$(builddir) -I$(srcdir) -I$(RELOCATABLE_CONFIG_H_DIR) \
-DHAVE_CONFIG_H -DIN_RELOCWRAPPER -DNO_XMALLOC \
-DINSTALLPREFIX=\"$(prefix)\" -DINSTALLDIR=\"...\" \
-DLIBPATHVAR=\"$(shlibpathvar)\" -DLIBDIRS=$(libdirs) \
-DEXEEXT=\"$(EXEEXT)\"
reloc_wrapper_SOURCES = \
relocwrapper.c progname.c progreloc.c areadlink.c readlink.c \
canonicalize-lgpl.c malloca.c relocatable.c setenv.c strerror.c \
c-ctype.c
endif

before I realized that there was no way to fill in the ... in
the -DINSTALLDIR=\"...\" part, since it can vary from one binary
to another.  So I see what you mean now.  Too bad.

> Therefore I would suggest to solve this problem by adding #undefs in
> specific places, such as
>
> /* Use the system functions, not the gnulib overrides in this file.  */
> #undef fprintf
> #undef sprintf
>
> What is the complete required symbol list (nm ...o | grep ' U ') of the set
> of modules compiled for the relocwrapper on your system?

Here it is:

 U abort
 U access
 U canonicalize_file_name
 U compute_curr_prefix
 U __errno
 U execv
 U exit
 U fprintf
 U free
 U freea
 U fwrite
 U getcwd
 U getenv
 U get_full_program_name
 U __guard
 U lstat
 U malloc
 U memcpy
 U memmove
 U mmalloca
 U program_name
 U readlink
 U realloc
 U relocate
 U rpl_readlink
 U rpl_strerror
 U setenv
 U set_program_name
 U set_program_name_and_installdir
 U set_relocation_prefix
 U __sF
 U sprintf
 U __stack_smash_handler
 U strchr
 U strcmp
 U strcpy
 U strerror
 U strncmp
 U strrchr

The above is *with* the following two --local-dir additions to
PSPP, plus disabling DEPENDS_ON_LIBINTL.  Those changes allow the
relocwrapper to build fine on OpenBSD.  In other words, only
fprintf and sprintf appear to be real problems on this system.

diff --git a/gl/local/lib/relocwrapper.c.diff b/gl/local/lib/relocwrapper.c.diff
new file mode 100644
index 000..d7676eb
--- /dev/null
+++ b/gl/local/lib/relocwrapper.c.diff
@@ -0,0 +1,15 @@
+diff -up /home/blp/pspp/master/gl/relocwrapper.c\~ 
/home/blp/pspp/master/gl/relocwrapper.c
+--- /home/blp/pspp/master/gl/relocwrapper.c~   2010-05-17 21:56:43.0 
-0700
 /home/blp/pspp/master/gl/relocwrapper.c2010-06-07 22:39:44.0 
-0700
+@@ -55,6 +55,9 @@
+ #include "relocatable.h"
+ #include "c-ctype.h"
+ 
++/* Temporary workaround for bug in relocatable-prog module. */
++#undef fprintf
++
+ /* Return a copy of the filename, with an extra ".bin" at the end.
+More generally, it replaces "${EXEEXT}" at the end with ".bin${EXEEXT}".  
*/
+ static char *
+
+Diff finished.  Mon Jun  7 22:39:49 2010
diff --git a/gl/local/lib/strerror.c.diff b/gl/local/lib/strerror.c.diff
new file mode 100644
index 000..a20ecdc
--- /dev/null
+++ b/gl/local/lib/strerror.c.diff
@@ -0,0 +1,15 @@
+diff -up /home/blp/pspp/master/gl/strerror.c\~ 
/home/blp/pspp/master/gl/strerror.c
+--- /home/blp/pspp/master/gl/strerror.c~   2010-05-17 21:56:43.0 
-0700
 /home/blp/p

uninstalling relocation wrappers

2010-06-08 Thread Ben Pfaff
"make distuninstallcheck" noticed a weakness in the recipes that
relocatable-maint.texi recommends for relocatable programs: "make
uninstall" does not remove the ".bin" programs that install-reloc
creates on some systems.

So far, the best solution that I've come up with that is generic,
that is, that does not require the maintainer to name each
installation directory or each program to be installed, is adding
the following as an uninstall-hook:

if !RELOCATABLE_VIA_LD
if test $(RELOCATABLE) = yes; then  \
case '$(EXEEXT)' in \
*.bin) ;;   \
*) $(MAKE) uninstall EXEEXT=$(EXEEXT).bin ;;\
esac;   \
fi
endif

It leaves something to be desired in terms of elegance, but it
does work for my test case at least.  Do you have any comments,
or any better ideas?

Thanks,

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