[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pkglib_PROGRAMS is now rejected
From: |
Jim Meyering |
Subject: |
Re: pkglib_PROGRAMS is now rejected |
Date: |
Sun, 19 Jun 2011 15:31:41 +0200 |
Pádraig Brady wrote:
> On 19/06/11 11:52, Jim Meyering wrote:
>> I normally use automake built from the head of "master",
>> but not long ago, it started failing like this:
>>
>> src/Makefile.am:141: error: `pkglibdir' is not a legitimate directory \
>> for `PROGRAMS'
>>
>> That variable determines where we install libstdbuf.so.
>>
>> One possibility is to change src/Makefile.am as below,
>> but that would mean moving libstdbuf.so from
>> $prefix/lib/coreutils/ to
>> $prefix/libexec/coreutils/
>> and adjusting stdbuf.c, and causing distros to adjust.
>>
>> There's probably a less invasive change...
>>
>> diff --git a/src/Makefile.am b/src/Makefile.am
>> index 516e1e5..ef0e7a4 100644
>> --- a/src/Makefile.am
>> +++ b/src/Makefile.am
>> @@ -138,7 +138,7 @@ bin_PROGRAMS = $(OPTIONAL_BIN_PROGS)
>>
>> noinst_PROGRAMS = setuidgid getlimits
>>
>> -pkglib_PROGRAMS = $(OPTIONAL_PKGLIB_PROGS)
>> +pkglibexec_PROGRAMS = $(OPTIONAL_PKGLIB_PROGS)
>>
>> noinst_HEADERS = \
>> chown-core.h \
>> --
>> 1.7.6.rc2.4.g36bfb.dirty
>
> Well I used lib/ rather that libexec/ because
> we don't actually dlload and link against the lib, and
> also if it was in /usr/lib/ then one can specify
> the lib without full path to LD_PRELOAD.
> Though I notice that on Fedora 15 this lib is
> in /usr/lib64/coreutils so the latter point is moot.
>
> The above change might not cause much issues for
> distros at all?
Thanks for the quick feedback.
In that case, what do you think of this?
>From 0f14e7aa28bfc7b385f75ccd1b7d23e194462074 Mon Sep 17 00:00:00 2001
From: Jim Meyering <address@hidden>
Date: Sun, 19 Jun 2011 11:41:24 +0200
Subject: [PATCH] build: fix automake variable name to work with cutting edge
automake
* src/Makefile.am (pkglibexec_PROGRAMS): Rename from pkglib_PROGRAMS.
The latter is invalid. Without this change, automake
v1.11-373-g9ca6326 and newer (on master) would fail with this:
`pkglibdir' is not a legitimate directory for `PROGRAMS'
This changes the default installation directory of libstdbuf.so from
$prefix/lib/coreutils/ to
$prefix/libexec/coreutils/
* src/stdbuf.c (set_LD_PRELOAD): Search in PKGLIBEXECDIR, not PKGLIBDIR,
since that's where we install libstdbuf.so.
Do not search in "", the system default directory.
---
src/Makefile.am | 2 +-
src/stdbuf.c | 9 ++++-----
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/src/Makefile.am b/src/Makefile.am
index 516e1e5..ef0e7a4 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -138,7 +138,7 @@ bin_PROGRAMS = $(OPTIONAL_BIN_PROGS)
noinst_PROGRAMS = setuidgid getlimits
-pkglib_PROGRAMS = $(OPTIONAL_PKGLIB_PROGS)
+pkglibexec_PROGRAMS = $(OPTIONAL_PKGLIB_PROGS)
noinst_HEADERS = \
chown-core.h \
diff --git a/src/stdbuf.c b/src/stdbuf.c
index f51dc6a..6fd803c 100644
--- a/src/stdbuf.c
+++ b/src/stdbuf.c
@@ -193,15 +193,14 @@ set_LD_PRELOAD (void)
char *LD_PRELOAD;
/* Note this would auto add the appropriate search path for "libstdbuf.so":
- gcc stdbuf.c -Wl,-rpath,'$ORIGIN' -Wl,-rpath,$PKGLIBDIR
+ gcc stdbuf.c -Wl,-rpath,'$ORIGIN' -Wl,-rpath,$PKGLIBEXECDIR
However we want the lookup done for the exec'd command not stdbuf.
- Since we don't link against libstdbuf.so add it to LIBDIR rather than
- LIBEXECDIR, as we'll search for it in the "sys default" case below. */
+ Since we don't link against libstdbuf.so add it to PKGLIBEXECDIR
+ rather than to LIBDIR. */
char const *const search_path[] = {
program_path,
- PKGLIBDIR,
- "", /* sys default */
+ PKGLIBEXECDIR,
NULL
};
--
1.7.6.rc2.4.g36bfb.dirty