coreutils
[Top][All Lists]
Advanced

[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



reply via email to

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