/lib/libsemanage.so.1 links to /usr/lib/libustr-1.0.so.1

/lib/libsemanage.so.1 links to /usr/lib/libustr-1.0.so.1

[Manoj Srivastava]

Hi,

        As demonstrated by

$ ldd /lib/libsemanage.so.1
        linux-gate.so.1 =>  (0xb8092000)
        libsepol.so.1 => /lib/libsepol.so.1 (0xb8015000)
        libselinux.so.1 => /lib/libselinux.so.1 (0xb7ffa000)
        libbz2.so.1.0 => /lib/libbz2.so.1.0 (0xb7fe9000)
        libustr-1.0.so.1 => /usr/lib/libustr-1.0.so.1 (0xb7fbf000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7e60000)
        libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7e5c000)
        /lib/ld-linux.so.2 (0xb8093000)

	libsemanage1 links to libustr which is located under the,
 possible separate or external, /usr partition, which would render
 libsemanage unusable in such setups. (This dependency has been around
 since 2.0.9).

        Should we move libsemanage1 to /usr/lib? The only reason for it
 to be in /lib would be for early boot, where /usr might not be
 available, but at this point, it is likely not usable without /usr
 anyway. 

        manoj
-- 
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: /lib/libsemanage.so.1 links to /usr/lib/libustr-1.0.so.1

[Joshua Brindle]

Manoj Srivastava wrote:
> Hi,
>
>          As demonstrated by
>
> $ ldd /lib/libsemanage.so.1
>          linux-gate.so.1 =>   (0xb8092000)
>          libsepol.so.1 =>  /lib/libsepol.so.1 (0xb8015000)
>          libselinux.so.1 =>  /lib/libselinux.so.1 (0xb7ffa000)
>          libbz2.so.1.0 =>  /lib/libbz2.so.1.0 (0xb7fe9000)
>          libustr-1.0.so.1 =>  /usr/lib/libustr-1.0.so.1 (0xb7fbf000)
>          libc.so.6 =>  /lib/i686/cmov/libc.so.6 (0xb7e60000)
>          libdl.so.2 =>  /lib/i686/cmov/libdl.so.2 (0xb7e5c000)
>          /lib/ld-linux.so.2 (0xb8093000)
>
> 	libsemanage1 links to libustr which is located under the,
>   possible separate or external, /usr partition, which would render
>   libsemanage unusable in such setups. (This dependency has been around
>   since 2.0.9).
>
>          Should we move libsemanage1 to /usr/lib? The only reason for it
>   to be in /lib would be for early boot, where /usr might not be
>   available, but at this point, it is likely not usable without /usr
>   anyway.
>
>          manoj


Yes, I'm not sure why you'd need libsemanage during early boot, we 
probably should apply this:

diff --git a/libsemanage/src/Makefile b/libsemanage/src/Makefile
index cfb9558..c531a2f 100644
--- a/libsemanage/src/Makefile
+++ b/libsemanage/src/Makefile
@@ -1,7 +1,7 @@
  # Installation directories.
  PREFIX ?= $(DESTDIR)/usr
  LIBDIR ?= $(PREFIX)/lib
-SHLIBDIR ?= $(DESTDIR)/lib
+SHLIBDIR ?= $(PREFIX)/lib
  INCLUDEDIR ?= $(PREFIX)/include
  PYLIBVER ?= $(shell python -c 'import sys;print "python%d.%d" % 
sys.version_info[0:2]')
  PYINC ?= /usr/include/${PYLIBVER}

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: /lib/libsemanage.so.1 links to /usr/lib/libustr-1.0.so.1

[Manoj Srivastava]

On Tue, Oct 13 2009, Joshua Brindle wrote:


> Yes, I'm not sure why you'd need libsemanage during early boot, we
> probably should apply this:
>
> diff --git a/libsemanage/src/Makefile b/libsemanage/src/Makefile
> index cfb9558..c531a2f 100644
> --- a/libsemanage/src/Makefile
> +++ b/libsemanage/src/Makefile
> @@ -1,7 +1,7 @@
>  # Installation directories.
>  PREFIX ?= $(DESTDIR)/usr
>  LIBDIR ?= $(PREFIX)/lib
> -SHLIBDIR ?= $(DESTDIR)/lib
> +SHLIBDIR ?= $(PREFIX)/lib
>  INCLUDEDIR ?= $(PREFIX)/include
>  PYLIBVER ?= $(shell python -c 'import sys;print "python%d.%d" %
> sys.version_info[0:2]')
>  PYINC ?= /usr/include/${PYLIBVER}
>

        I've applied this patch in Debian unstable.

        manoj
-- 
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: /lib/libsemanage.so.1 links to /usr/lib/libustr-1.0.so.1

[Stephen Smalley]

On Wed, 2009-10-14 at 00:49 -0500, Manoj Srivastava wrote:
> On Tue, Oct 13 2009, Joshua Brindle wrote:
> 
> 
> > Yes, I'm not sure why you'd need libsemanage during early boot, we
> > probably should apply this:
> >
> > diff --git a/libsemanage/src/Makefile b/libsemanage/src/Makefile
> > index cfb9558..c531a2f 100644
> > --- a/libsemanage/src/Makefile
> > +++ b/libsemanage/src/Makefile
> > @@ -1,7 +1,7 @@
> >  # Installation directories.
> >  PREFIX ?= $(DESTDIR)/usr
> >  LIBDIR ?= $(PREFIX)/lib
> > -SHLIBDIR ?= $(DESTDIR)/lib
> > +SHLIBDIR ?= $(PREFIX)/lib
> >  INCLUDEDIR ?= $(PREFIX)/include
> >  PYLIBVER ?= $(shell python -c 'import sys;print "python%d.%d" %
> > sys.version_info[0:2]')
> >  PYINC ?= /usr/include/${PYLIBVER}
> >
> 
>         I've applied this patch in Debian unstable.

My only concern with relocating libsemanage is whether it will create
any compatibility problems for existing binaries previously linked
against /lib/libsemanage.so.1.  Also it could get confusing if you build
and install the newer version and existing binaries keep using the old
library at the old location.  You likely need/want to
symlink /lib/libsemanage.so.1 to the new location.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: /lib/libsemanage.so.1 links to /usr/lib/libustr-1.0.so.1

[Daniel J Walsh]

On 10/19/2009 10:20 AM, Stephen Smalley wrote:
> On Wed, 2009-10-14 at 00:49 -0500, Manoj Srivastava wrote:
>> On Tue, Oct 13 2009, Joshua Brindle wrote:
>>
>>
>>> Yes, I'm not sure why you'd need libsemanage during early boot, we
>>> probably should apply this:
>>>
>>> diff --git a/libsemanage/src/Makefile b/libsemanage/src/Makefile
>>> index cfb9558..c531a2f 100644
>>> --- a/libsemanage/src/Makefile
>>> +++ b/libsemanage/src/Makefile
>>> @@ -1,7 +1,7 @@
>>>  # Installation directories.
>>>  PREFIX ?= $(DESTDIR)/usr
>>>  LIBDIR ?= $(PREFIX)/lib
>>> -SHLIBDIR ?= $(DESTDIR)/lib
>>> +SHLIBDIR ?= $(PREFIX)/lib
>>>  INCLUDEDIR ?= $(PREFIX)/include
>>>  PYLIBVER ?= $(shell python -c 'import sys;print "python%d.%d" %
>>> sys.version_info[0:2]')
>>>  PYINC ?= /usr/include/${PYLIBVER}
>>>
>>
>>         I've applied this patch in Debian unstable.
> 
> My only concern with relocating libsemanage is whether it will create
> any compatibility problems for existing binaries previously linked
> against /lib/libsemanage.so.1.  Also it could get confusing if you build
> and install the newer version and existing binaries keep using the old
> library at the old location.  You likely need/want to
> symlink /lib/libsemanage.so.1 to the new location.
> 
Why does it need to be moved?  Are you doing semanage functions during boot up?

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: /lib/libsemanage.so.1 links to /usr/lib/libustr-1.0.so.1

[Stephen Smalley]

On Mon, 2009-10-19 at 11:07 -0400, Daniel J Walsh wrote:
> On 10/19/2009 10:20 AM, Stephen Smalley wrote:
> > On Wed, 2009-10-14 at 00:49 -0500, Manoj Srivastava wrote:
> >> On Tue, Oct 13 2009, Joshua Brindle wrote:
> >>
> >>
> >>> Yes, I'm not sure why you'd need libsemanage during early boot, we
> >>> probably should apply this:
> >>>
> >>> diff --git a/libsemanage/src/Makefile b/libsemanage/src/Makefile
> >>> index cfb9558..c531a2f 100644
> >>> --- a/libsemanage/src/Makefile
> >>> +++ b/libsemanage/src/Makefile
> >>> @@ -1,7 +1,7 @@
> >>>  # Installation directories.
> >>>  PREFIX ?= $(DESTDIR)/usr
> >>>  LIBDIR ?= $(PREFIX)/lib
> >>> -SHLIBDIR ?= $(DESTDIR)/lib
> >>> +SHLIBDIR ?= $(PREFIX)/lib
> >>>  INCLUDEDIR ?= $(PREFIX)/include
> >>>  PYLIBVER ?= $(shell python -c 'import sys;print "python%d.%d" %
> >>> sys.version_info[0:2]')
> >>>  PYINC ?= /usr/include/${PYLIBVER}
> >>>
> >>
> >>         I've applied this patch in Debian unstable.
> > 
> > My only concern with relocating libsemanage is whether it will create
> > any compatibility problems for existing binaries previously linked
> > against /lib/libsemanage.so.1.  Also it could get confusing if you build
> > and install the newer version and existing binaries keep using the old
> > library at the old location.  You likely need/want to
> > symlink /lib/libsemanage.so.1 to the new location.
> > 
> Why does it need to be moved?  Are you doing semanage functions during boot up?

It's moving the other direction (presently in /lib, moving to /usr/lib).
Manoj pointed out that because of the ustr dependency, it no longer
makes sense to keep libsemanage in /lib, because libustr lives
in /usr/lib.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: /lib/libsemanage.so.1 links to /usr/lib/libustr-1.0.so.1

[Daniel J Walsh]

On 10/19/2009 11:11 AM, Stephen Smalley wrote:
> On Mon, 2009-10-19 at 11:07 -0400, Daniel J Walsh wrote:
>> On 10/19/2009 10:20 AM, Stephen Smalley wrote:
>>> On Wed, 2009-10-14 at 00:49 -0500, Manoj Srivastava wrote:
>>>> On Tue, Oct 13 2009, Joshua Brindle wrote:
>>>>
>>>>
>>>>> Yes, I'm not sure why you'd need libsemanage during early boot, we
>>>>> probably should apply this:
>>>>>
>>>>> diff --git a/libsemanage/src/Makefile b/libsemanage/src/Makefile
>>>>> index cfb9558..c531a2f 100644
>>>>> --- a/libsemanage/src/Makefile
>>>>> +++ b/libsemanage/src/Makefile
>>>>> @@ -1,7 +1,7 @@
>>>>>  # Installation directories.
>>>>>  PREFIX ?= $(DESTDIR)/usr
>>>>>  LIBDIR ?= $(PREFIX)/lib
>>>>> -SHLIBDIR ?= $(DESTDIR)/lib
>>>>> +SHLIBDIR ?= $(PREFIX)/lib
>>>>>  INCLUDEDIR ?= $(PREFIX)/include
>>>>>  PYLIBVER ?= $(shell python -c 'import sys;print "python%d.%d" %
>>>>> sys.version_info[0:2]')
>>>>>  PYINC ?= /usr/include/${PYLIBVER}
>>>>>
>>>>
>>>>         I've applied this patch in Debian unstable.
>>>
>>> My only concern with relocating libsemanage is whether it will create
>>> any compatibility problems for existing binaries previously linked
>>> against /lib/libsemanage.so.1.  Also it could get confusing if you build
>>> and install the newer version and existing binaries keep using the old
>>> library at the old location.  You likely need/want to
>>> symlink /lib/libsemanage.so.1 to the new location.
>>>
>> Why does it need to be moved?  Are you doing semanage functions during boot up?
> 
> It's moving the other direction (presently in /lib, moving to /usr/lib).
> Manoj pointed out that because of the ustr dependency, it no longer
> makes sense to keep libsemanage in /lib, because libustr lives
> in /usr/lib.
> 
Oh, I misread. I think  like a symbolic link should handle this

Although the only entry I see for this is 

 ls -l /lib | grep '\.\.'
lrwxrwxrwx.  1 root root      14 2009-10-11 07:36 cpp -> ../usr/bin/cpp




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: /lib/libsemanage.so.1 links to /usr/lib/libustr-1.0.so.1

[Joshua Brindle]

Daniel J Walsh wrote:
> On 10/19/2009 11:11 AM, Stephen Smalley wrote:
>> On Mon, 2009-10-19 at 11:07 -0400, Daniel J Walsh wrote:
>>> On 10/19/2009 10:20 AM, Stephen Smalley wrote:
>>>> On Wed, 2009-10-14 at 00:49 -0500, Manoj Srivastava wrote:
>>>>> On Tue, Oct 13 2009, Joshua Brindle wrote:
>>>>>
>>>>>
>>>>>> Yes, I'm not sure why you'd need libsemanage during early boot, we
>>>>>> probably should apply this:
>>>>>>
>>>>>> diff --git a/libsemanage/src/Makefile b/libsemanage/src/Makefile
>>>>>> index cfb9558..c531a2f 100644
>>>>>> --- a/libsemanage/src/Makefile
>>>>>> +++ b/libsemanage/src/Makefile
>>>>>> @@ -1,7 +1,7 @@
>>>>>>   # Installation directories.
>>>>>>   PREFIX ?= $(DESTDIR)/usr
>>>>>>   LIBDIR ?= $(PREFIX)/lib
>>>>>> -SHLIBDIR ?= $(DESTDIR)/lib
>>>>>> +SHLIBDIR ?= $(PREFIX)/lib
>>>>>>   INCLUDEDIR ?= $(PREFIX)/include
>>>>>>   PYLIBVER ?= $(shell python -c 'import sys;print "python%d.%d" %
>>>>>> sys.version_info[0:2]')
>>>>>>   PYINC ?= /usr/include/${PYLIBVER}
>>>>>>
>>>>>          I've applied this patch in Debian unstable.
>>>> My only concern with relocating libsemanage is whether it will create
>>>> any compatibility problems for existing binaries previously linked
>>>> against /lib/libsemanage.so.1.  Also it could get confusing if you build
>>>> and install the newer version and existing binaries keep using the old
>>>> library at the old location.  You likely need/want to
>>>> symlink /lib/libsemanage.so.1 to the new location.
>>>>
>>> Why does it need to be moved?  Are you doing semanage functions during boot up?
>> It's moving the other direction (presently in /lib, moving to /usr/lib).
>> Manoj pointed out that because of the ustr dependency, it no longer
>> makes sense to keep libsemanage in /lib, because libustr lives
>> in /usr/lib.
>>
> Oh, I misread. I think  like a symbolic link should handle this
>
> Although the only entry I see for this is
>
>   ls -l /lib | grep '\.\.'
> lrwxrwxrwx.  1 root root      14 2009-10-11 07:36 cpp ->  ../usr/bin/cpp
>

Having a symbolic link doesn't help. If someone sees libsemanage.so in 
/lib they should rightly believe that it is available during early boot 
when in fact it is not since /usr/lib/libustr.so might not be available.

The dynamic linker shouldn't really get upset if it moves so the only 
issue is leaving a stale one there on non-package managed systems.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: /lib/libsemanage.so.1 links to /usr/lib/libustr-1.0.so.1

[Manoj Srivastava]

On Mon, Oct 19 2009, Stephen Smalley wrote:

> On Wed, 2009-10-14 at 00:49 -0500, Manoj Srivastava wrote:
>> On Tue, Oct 13 2009, Joshua Brindle wrote:
>> 
>> 
>> > Yes, I'm not sure why you'd need libsemanage during early boot, we
>> > probably should apply this:
>> >
>> > diff --git a/libsemanage/src/Makefile b/libsemanage/src/Makefile
>> > index cfb9558..c531a2f 100644
>> > --- a/libsemanage/src/Makefile
>> > +++ b/libsemanage/src/Makefile
>> > @@ -1,7 +1,7 @@
>> >  # Installation directories.
>> >  PREFIX ?= $(DESTDIR)/usr
>> >  LIBDIR ?= $(PREFIX)/lib
>> > -SHLIBDIR ?= $(DESTDIR)/lib
>> > +SHLIBDIR ?= $(PREFIX)/lib
>> >  INCLUDEDIR ?= $(PREFIX)/include
>> >  PYLIBVER ?= $(shell python -c 'import sys;print "python%d.%d" %
>> > sys.version_info[0:2]')
>> >  PYINC ?= /usr/include/${PYLIBVER}
>> >
>> 
>>         I've applied this patch in Debian unstable.
>
> My only concern with relocating libsemanage is whether it will create
> any compatibility problems for existing binaries previously linked
> against /lib/libsemanage.so.1.  Also it could get confusing if you
> build and install the newer version and existing binaries keep using
> the old library at the old location.  You likely need/want to symlink
> /lib/libsemanage.so.1 to the new location.

        As long as the new library location is in the ld.so path, there
 is no issue, is there?  At run time, ld.so searches the path, loads the
 shared libraries from the new location, prepares the program to run,
 and then runs it. At worst, there might be two copies of the library
 loaded into memory, in case there are programs already running linked
 with libsemanage.

        If I am wrong, and long running programs might be affected when
 the library location is yanked out from under them, some mitigating
 action may be taken. I am not sure there are any daemons yet linked
 with libsemanage, but I can arrange for any such daemons to be
 restarted during installation, once I get any bug report.

        manoj
-- 
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: /lib/libsemanage.so.1 links to /usr/lib/libustr-1.0.so.1

[Stephen Smalley]

On Wed, 2009-10-21 at 09:03 -0500, Manoj Srivastava wrote:
> On Mon, Oct 19 2009, Stephen Smalley wrote:
> 
> > On Wed, 2009-10-14 at 00:49 -0500, Manoj Srivastava wrote:
> >> On Tue, Oct 13 2009, Joshua Brindle wrote:
> >> 
> >> 
> >> > Yes, I'm not sure why you'd need libsemanage during early boot, we
> >> > probably should apply this:
> >> >
> >> > diff --git a/libsemanage/src/Makefile b/libsemanage/src/Makefile
> >> > index cfb9558..c531a2f 100644
> >> > --- a/libsemanage/src/Makefile
> >> > +++ b/libsemanage/src/Makefile
> >> > @@ -1,7 +1,7 @@
> >> >  # Installation directories.
> >> >  PREFIX ?= $(DESTDIR)/usr
> >> >  LIBDIR ?= $(PREFIX)/lib
> >> > -SHLIBDIR ?= $(DESTDIR)/lib
> >> > +SHLIBDIR ?= $(PREFIX)/lib
> >> >  INCLUDEDIR ?= $(PREFIX)/include
> >> >  PYLIBVER ?= $(shell python -c 'import sys;print "python%d.%d" %
> >> > sys.version_info[0:2]')
> >> >  PYINC ?= /usr/include/${PYLIBVER}
> >> >
> >> 
> >>         I've applied this patch in Debian unstable.
> >
> > My only concern with relocating libsemanage is whether it will create
> > any compatibility problems for existing binaries previously linked
> > against /lib/libsemanage.so.1.  Also it could get confusing if you
> > build and install the newer version and existing binaries keep using
> > the old library at the old location.  You likely need/want to symlink
> > /lib/libsemanage.so.1 to the new location.
> 
>         As long as the new library location is in the ld.so path, there
>  is no issue, is there?  At run time, ld.so searches the path, loads the
>  shared libraries from the new location, prepares the program to run,
>  and then runs it. At worst, there might be two copies of the library
>  loaded into memory, in case there are programs already running linked
>  with libsemanage.
> 
>         If I am wrong, and long running programs might be affected when
>  the library location is yanked out from under them, some mitigating
>  action may be taken. I am not sure there are any daemons yet linked
>  with libsemanage, but I can arrange for any such daemons to be
>  restarted during installation, once I get any bug report.

No, I think my concern was misplaced.  As long as we ensure that we
don't leave a stale copy of the library around in the old location, we
should be fine.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: /lib/libsemanage.so.1 links to /usr/lib/libustr-1.0.so.1

[Joshua Brindle]

Joshua Brindle wrote:
> Manoj Srivastava wrote:
>> Hi,
>>
>> As demonstrated by
>>
>> $ ldd /lib/libsemanage.so.1
>> linux-gate.so.1 => (0xb8092000)
>> libsepol.so.1 => /lib/libsepol.so.1 (0xb8015000)
>> libselinux.so.1 => /lib/libselinux.so.1 (0xb7ffa000)
>> libbz2.so.1.0 => /lib/libbz2.so.1.0 (0xb7fe9000)
>> libustr-1.0.so.1 => /usr/lib/libustr-1.0.so.1 (0xb7fbf000)
>> libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7e60000)
>> libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7e5c000)
>> /lib/ld-linux.so.2 (0xb8093000)
>>
>> libsemanage1 links to libustr which is located under the,
>> possible separate or external, /usr partition, which would render
>> libsemanage unusable in such setups. (This dependency has been around
>> since 2.0.9).
>>
>> Should we move libsemanage1 to /usr/lib? The only reason for it
>> to be in /lib would be for early boot, where /usr might not be
>> available, but at this point, it is likely not usable without /usr
>> anyway.
>>
>> manoj
>
>
> Yes, I'm not sure why you'd need libsemanage during early boot, we
> probably should apply this:
>
> diff --git a/libsemanage/src/Makefile b/libsemanage/src/Makefile
> index cfb9558..c531a2f 100644
> --- a/libsemanage/src/Makefile
> +++ b/libsemanage/src/Makefile
> @@ -1,7 +1,7 @@
> # Installation directories.
> PREFIX ?= $(DESTDIR)/usr
> LIBDIR ?= $(PREFIX)/lib
> -SHLIBDIR ?= $(DESTDIR)/lib
> +SHLIBDIR ?= $(PREFIX)/lib
> INCLUDEDIR ?= $(PREFIX)/include
> PYLIBVER ?= $(shell python -c 'import sys;print "python%d.%d" %
> sys.version_info[0:2]')
> PYINC ?= /usr/include/${PYLIBVER}
>

Looks like I missed the libsemanage.so.1 libsemanage.so symlink, applied 
the following patch to libsemanage 2.0.43:

diff --git a/libsemanage/src/Makefile b/libsemanage/src/Makefile
index a249f0f..67afc60 100644
--- a/libsemanage/src/Makefile
+++ b/libsemanage/src/Makefile
@@ -1,7 +1,7 @@
  # Installation directories.
  PREFIX ?= $(DESTDIR)/usr
  LIBDIR ?= $(PREFIX)/lib
-SHLIBDIR ?= $(DESTDIR)/lib
+SHLIBDIR ?= $(PREFIX)/lib
  INCLUDEDIR ?= $(PREFIX)/include
  PYLIBVER ?= $(shell python -c 'import sys;print "python%d.%d" % 
sys.version_info[0:2]')
  PYINC ?= /usr/include/${PYLIBVER}
@@ -127,7 +127,7 @@ install: all
         test -d $(LIBDIR)/pkgconfig || install -m 755 -d 
$(LIBDIR)/pkgconfig
         install -m 644 $(LIBPC) $(LIBDIR)/pkgconfig
         test -f $(DEFAULT_SEMANAGE_CONF_LOCATION) || install -m 644 -D 
semanage.conf $(DEFAULT_SEMANAGE_CONF_LOCATION)
-       cd $(LIBDIR) && ln -sf ../../`basename $(SHLIBDIR)`/$(LIBSO) 
$(TARGET)
+       cd $(LIBDIR) && ln -sf $(LIBSO) $(TARGET)

  install-pywrap: pywrap
         test -d $(PYLIBDIR)/site-packages || install -m 755 -d 
$(PYLIBDIR)/site-packages

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.