From nobody@FreeBSD.org  Mon Jul 15 06:19:28 2013
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1])
	by hub.freebsd.org (Postfix) with ESMTP id 649D943C
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 15 Jul 2013 06:19:28 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from oldred.freebsd.org (oldred.freebsd.org [8.8.178.121])
	by mx1.freebsd.org (Postfix) with ESMTP id 56253ADB
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 15 Jul 2013 06:19:28 +0000 (UTC)
Received: from oldred.freebsd.org ([127.0.1.6])
	by oldred.freebsd.org (8.14.5/8.14.7) with ESMTP id r6F6JRqJ077582
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 15 Jul 2013 06:19:27 GMT
	(envelope-from nobody@oldred.freebsd.org)
Received: (from nobody@localhost)
	by oldred.freebsd.org (8.14.5/8.14.5/Submit) id r6F6JRIJ077578;
	Mon, 15 Jul 2013 06:19:27 GMT
	(envelope-from nobody)
Message-Id: <201307150619.r6F6JRIJ077578@oldred.freebsd.org>
Date: Mon, 15 Jul 2013 06:19:27 GMT
From: Taku YAMAMOTO <taku@tackymt.homeip.net>
To: freebsd-gnats-submit@FreeBSD.org
Subject: r251668 breaks applications which depends on dlopen("libc.so")
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         180568
>Category:       kern
>Synopsis:       r251668 breaks applications which depends on dlopen("libc.so") [regression]
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    jlh
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jul 15 06:20:00 UTC 2013
>Closed-Date:    
>Last-Modified:  Thu Aug 15 08:20:00 UTC 2013
>Originator:     Taku YAMAMOTO
>Release:        10-current as of r252907
>Organization:
Unique Vision Company, Japan
>Environment:
FreeBSD biotite.tackymt.homeip.net 10.0-CURRENT FreeBSD 10.0-CURRENT #274 r+410f38ed-dirty: Sun Jul 14 10:53:03 JST 2013     taku@biotite.tackymt.homeip.net:/home/taku/work/build/biotite/usr/src/sys/BIOTITE  i386
>Description:
After r251668 /usr/lib/libc.so becomes a plain ASCII text file which contains a linker script.

Unfortunately, now dlopen("libc.so") fails because it's not an ELF file, resulting applications which depend on dlopen("libc.so") get broken.

Applications which are broken by r251668 currently I know includes, but potentially not limited to:
 - Firefox (it boots, but exhibits broken behaviour)
 - Mono applications which P/Invoke libc functions (ends up with System.DllNotFoundException: libc.so)
>How-To-Repeat:
Firefox case:
Launch Firefox with libmap.conf empty.
Firefox boots, but it won't load the previous session, URL bar won't navigate us anywhere, etc.

Mono applications which use libgdiplus, or anything which P/Invoke's libc's functions:
Launch such applications with libmap.conf empty.
They ends up with: System.DllNotFoundException: libc.so
>Fix:
Note this is only a workaround!

Put the following line into libmap.conf:
libc.so	libc.so.7


>Release-Note:
>Audit-Trail:

From: Gleb Smirnoff <glebius@FreeBSD.org>
To: Taku YAMAMOTO <taku@tackymt.homeip.net>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: misc/180568: r251672 breaks applications which depends on
 dlopen("libc.so")
Date: Tue, 16 Jul 2013 16:46:10 +0400

 On Mon, Jul 15, 2013 at 06:19:27AM +0000, Taku YAMAMOTO wrote:
 T> >Description:
 T> After r251672 /usr/lib/libc.so becomes a plain ASCII text file which contains a linker script.
 
 r251672 is a comment only change, isn't it?
 
 
 -- 
 Totus tuus, Glebius.

From: Taku YAMAMOTO <taku@tackymt.homeip.net>
To: Gleb Smirnoff <glebius@FreeBSD.org>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: misc/180568: r251672 breaks applications which depends on
 dlopen("libc.so")
Date: Wed, 17 Jul 2013 00:54:45 +0900

 On Tue, 16 Jul 2013 16:46:10 +0400
 Gleb Smirnoff <glebius@FreeBSD.org> wrote:
 
 > On Mon, Jul 15, 2013 at 06:19:27AM +0000, Taku YAMAMOTO wrote:
 > T> >Description:
 > T> After r251672 /usr/lib/libc.so becomes a plain ASCII text file which contains a linker script.
 > 
 > r251672 is a comment only change, isn't it?
 > 
 > 
 > -- 
 > Totus tuus, Glebius.
 
 Oops, it's actually r251668 which I wanted to mean.
 
 -- 
 -|-__   YAMAMOTO, Taku
  | __ <     <taku@tackymt.homeip.net>
 
       - A chicken is an egg's way of producing more eggs. -
 
 [note: this PR was edited by linimon to reflect the proper Subject, per request]
Responsible-Changed-From-To: freebsd-bugs->jlh 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Thu Jul 18 02:06:14 UTC 2013 
Responsible-Changed-Why:  
Over to committer in question. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=180568 

From: Jeremie Le Hen <jlh@FreeBSD.org>
To: linimon@FreeBSD.org
Cc: bug-followup@FreeBSD.org, jlh@FreeBSD.org
Subject: Re: kern/180568: r251668 breaks applications which depends on
 dlopen("libc.so")
Date: Tue, 23 Jul 2013 20:34:17 +0200

 (Re-sending with the right GNATS email address.)
 
 On Thu, Jul 18, 2013 at 02:09:50AM +0000, linimon@FreeBSD.org wrote:
 > Old Synopsis: r251672 breaks applications which depends on dlopen("libc.so")
 > New Synopsis: r251668 breaks applications which depends on dlopen("libc.so")
 >
 > Responsible-Changed-From-To: freebsd-bugs->jlh
 > Responsible-Changed-By: linimon
 > Responsible-Changed-When: Thu Jul 18 02:06:14 UTC 2013
 > Responsible-Changed-Why:
 > Over to committer in question.
 >
 > http://www.freebsd.org/cgi/query-pr.cgi?pr=180568
 
 Thanks for reporting this.  I've done a quick sweep over firefox source
 code but the latest release is more than 700 MB.  Can you manage to get
 a stacktrace please?
 
 --
 Jeremie Le Hen
 
 Scientists say the world is made up of Protons, Neutrons and Electrons.
 They forgot to mention Morons.

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/180568: commit references a PR
Date: Thu,  1 Aug 2013 05:50:51 +0000 (UTC)

 Author: jlh
 Date: Thu Aug  1 05:50:42 2013
 New Revision: 253853
 URL: http://svnweb.freebsd.org/changeset/base/253853
 
 Log:
   Include /usr/local/etc/libmap.d/ by default.
   
   PR:		180568
   Reviewed by:	bapt
   Obtained from:	kib
   MFC after:	3 days
 
 Added:
   head/etc/libmap.conf   (contents, props changed)
 Modified:
   head/etc/Makefile
 
 Modified: head/etc/Makefile
 ==============================================================================
 --- head/etc/Makefile	Thu Aug  1 04:50:46 2013	(r253852)
 +++ head/etc/Makefile	Thu Aug  1 05:50:42 2013	(r253853)
 @@ -22,6 +22,7 @@ BIN1=	crontab \
  	hosts.equiv \
  	inetd.conf \
  	libalias.conf \
 +	libmap.conf \
  	login.access \
  	login.conf \
  	mac.conf \
 
 Added: head/etc/libmap.conf
 ==============================================================================
 --- /dev/null	00:00:00 1970	(empty, because file is newly added)
 +++ head/etc/libmap.conf	Thu Aug  1 05:50:42 2013	(r253853)
 @@ -0,0 +1,2 @@
 +# $FreeBSD$
 +includedir /usr/local/etc/libmap.d
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 

From: Jeremie Le Hen <jlh@FreeBSD.org>
To: Taku YAMAMOTO <taku@tackymt.homeip.net>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/180568: r251668 breaks applications which depends on
 dlopen("libc.so")
Date: Sat, 3 Aug 2013 12:23:52 +0200

 Hi Taku,
 
 On Tue, Jul 23, 2013 at 08:34:17PM +0200, Jeremie Le Hen wrote:
 > (Re-sending with the right GNATS email address.)
 > 
 > On Thu, Jul 18, 2013 at 02:09:50AM +0000, linimon@FreeBSD.org wrote:
 > > Old Synopsis: r251672 breaks applications which depends on dlopen("libc.so")
 > > New Synopsis: r251668 breaks applications which depends on dlopen("libc.so")
 > >
 > > Responsible-Changed-From-To: freebsd-bugs->jlh
 > > Responsible-Changed-By: linimon
 > > Responsible-Changed-When: Thu Jul 18 02:06:14 UTC 2013
 > > Responsible-Changed-Why:
 > > Over to committer in question.
 > >
 > > http://www.freebsd.org/cgi/query-pr.cgi?pr=180568
 > 
 > Thanks for reporting this.  I've done a quick sweep over firefox source
 > code but the latest release is more than 700 MB.  Can you manage to get
 > a stacktrace please?
 
 Can you please try the following in /etc/libmap.conf:
 
     [/usr/local/bin/firefox]
     libc.so	    libc.so.7
 
 If it does not work, try prepending "/lib/" before "libc.so.7".
 
 If that works, we will manage to provide a fix for 9.2-RELEASE, so we
 have to be swift because the release is done in August.
 
 
 If if still crashes, can you run firefox with ktrace and provide me with
 the resulting file please?
 
 
 -- 
 Jeremie Le Hen
 
 Scientists say the world is made up of Protons, Neutrons and Electrons.
 They forgot to mention Morons.

From: Taku YAMAMOTO <taku@tackymt.homeip.net>
To: Jeremie Le Hen <jlh@FreeBSD.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/180568: r251668 breaks applications which depends on
 dlopen("libc.so")
Date: Mon, 5 Aug 2013 01:33:56 +0900

 On Sat, 3 Aug 2013 12:23:52 +0200
 Jeremie Le Hen <jlh@FreeBSD.org> wrote:
 
 > Hi Taku,
 > 
 > On Tue, Jul 23, 2013 at 08:34:17PM +0200, Jeremie Le Hen wrote:
 > > (Re-sending with the right GNATS email address.)
 > > 
 > > On Thu, Jul 18, 2013 at 02:09:50AM +0000, linimon@FreeBSD.org wrote:
 > > > Old Synopsis: r251672 breaks applications which depends on dlopen("libc.so")
 > > > New Synopsis: r251668 breaks applications which depends on dlopen("libc.so")
 > > >
 > > > Responsible-Changed-From-To: freebsd-bugs->jlh
 > > > Responsible-Changed-By: linimon
 > > > Responsible-Changed-When: Thu Jul 18 02:06:14 UTC 2013
 > > > Responsible-Changed-Why:
 > > > Over to committer in question.
 > > >
 > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=180568
 > > 
 > > Thanks for reporting this.  I've done a quick sweep over firefox source
 > > code but the latest release is more than 700 MB.  Can you manage to get
 > > a stacktrace please?
 > 
 > Can you please try the following in /etc/libmap.conf:
 > 
 >     [/usr/local/bin/firefox]
 >     libc.so	    libc.so.7
 
 This is what I've already suggested as a *WORKAROUND* which has been working
 well for a month.
 
 But please see below...
 
 > If it does not work, try prepending "/lib/" before "libc.so.7".
 > 
 > If that works, we will manage to provide a fix for 9.2-RELEASE, so we
 > have to be swift because the release is done in August.
 
 At least firefox is concerned, we've already have a patch since
 ports/r319816 - it no longer resort to fallback to libc.so but loads libc.so.7
 explicitly - it looks promising, though I haven't had a time to update my ports
 tree to catch up and test with :(
 
 > If if still crashes, can you run firefox with ktrace and provide me with
 > the resulting file please?
 
 Again, I've rather been concerned about applications in general depending
 upon dlopen-able libc.so than particular ports which we can teach each
 and every one not to do so.
 
 -- 
 -|-__   YAMAMOTO, Taku
  | __ <     <taku@tackymt.homeip.net>
 
       - A chicken is an egg's way of producing more eggs. -

From: Jeremie Le Hen <jlh@FreeBSD.org>
To: Taku YAMAMOTO <taku@tackymt.homeip.net>
Cc: Jeremie Le Hen <jlh@FreeBSD.org>, bug-followup@FreeBSD.org,
	bapt@FreeBSD.org, kib@FreeBSD.org
Subject: Re: kern/180568: r251668 breaks applications which depends on
 dlopen("libc.so")
Date: Sun, 4 Aug 2013 19:35:30 +0200

 +Cc: bapt@ and kib@
 
 On Mon, Aug 05, 2013 at 01:33:56AM +0900, Taku YAMAMOTO wrote:
 > On Sat, 3 Aug 2013 12:23:52 +0200
 > Jeremie Le Hen <jlh@FreeBSD.org> wrote:
 > > Can you please try the following in /etc/libmap.conf:
 > > 
 > >     [/usr/local/bin/firefox]
 > >     libc.so	    libc.so.7
 > 
 > This is what I've already suggested as a *WORKAROUND* which has been working
 > well for a month.
 
 Oh sorry, I overlooked that.
 
 
 > But please see below...
 > 
 > > If it does not work, try prepending "/lib/" before "libc.so.7".
 > > 
 > > If that works, we will manage to provide a fix for 9.2-RELEASE, so we
 > > have to be swift because the release is done in August.
 > 
 > At least firefox is concerned, we've already have a patch since
 > ports/r319816 - it no longer resort to fallback to libc.so but loads libc.so.7
 > explicitly - it looks promising, though I haven't had a time to update my ports
 > tree to catch up and test with :(
 
 bapt@ should implement a simple framework in the ports to create a file
 in /usr/local/etc/libmap.d/${PORTNAME}.conf.  This will allow port
 maintainers to easily implement a workaround for this kind of softwares.
 
 
 > > If if still crashes, can you run firefox with ktrace and provide me with
 > > the resulting file please?
 > 
 > Again, I've rather been concerned about applications in general depending
 > upon dlopen-able libc.so than particular ports which we can teach each
 > and every one not to do so.
 
 The core problem is that libc.so (or any other .so) is historically
 used by both the linker and the runtime loader.  This worked well until
 the linker could read an ld script from the .so.  Now we have to
 decouple the rendez-vous point for the linker and rtld.
 
 I've implemented a patch that can solve this problem, but it is not
 perfect.  Basically, when installing a .so which contains an ld script,
 he will also create a .so.last symlink pointing to the real shared
 object (thus actually decouplin the rendez-vous point).  I modified rtld
 to try the .so.last first if it exists.
 
 http://people.freebsd.org/~jlh/rtld_last_so_suffix.patch
 
 I think this is slightly hackish but it works; if your application is
 linked to an older version of the lib, it will fail but just as it would
 fail today anyway.
 
 kib@ pointed that with the libmap.conf solution, your application will
 still work even after the shared object major number is bumped
 (libc.so.7 -> libc.so.8).
 
 This is more work for maintainers but on the other hand this means that
 this kind of problems must be solved now (I think there are probably
 less than 10 in the whole port tree) and this will be solved correctly.
 
 Whereas with my patch the problem doesn't exist and doen't have to be
 fixed as long as the shared object major number is not bumped, but may
 bite the user unexpectedly after a major FreeBSD upgrade (though he
 would probably be answered to recompile the port or reinstall the
 package).
 
 Do you have any thought on that?
 
 Regards,
 -- 
 Jeremie Le Hen
 
 Scientists say the world is made up of Protons, Neutrons and Electrons.
 They forgot to mention Morons.

From: Konstantin Belousov <kostikbel@gmail.com>
To: Jeremie Le Hen <jlh@FreeBSD.org>
Cc: Taku YAMAMOTO <taku@tackymt.homeip.net>, bug-followup@FreeBSD.org,
        bapt@FreeBSD.org
Subject: Re: kern/180568: r251668 breaks applications which depends on
 dlopen("libc.so")
Date: Mon, 5 Aug 2013 11:29:26 +0300

 --A7a15KRh1eqpVFgU
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Sun, Aug 04, 2013 at 07:35:30PM +0200, Jeremie Le Hen wrote:
 > +Cc: bapt@ and kib@
 >=20
 > On Mon, Aug 05, 2013 at 01:33:56AM +0900, Taku YAMAMOTO wrote:
 > > On Sat, 3 Aug 2013 12:23:52 +0200
 > > Jeremie Le Hen <jlh@FreeBSD.org> wrote:
 > > > Can you please try the following in /etc/libmap.conf:
 > > >=20
 > > >     [/usr/local/bin/firefox]
 > > >     libc.so	    libc.so.7
 > >=20
 > > This is what I've already suggested as a *WORKAROUND* which has been wo=
 rking
 > > well for a month.
 >=20
 > Oh sorry, I overlooked that.
 >=20
 >=20
 > > But please see below...
 > >=20
 > > > If it does not work, try prepending "/lib/" before "libc.so.7".
 > > >=20
 > > > If that works, we will manage to provide a fix for 9.2-RELEASE, so we
 > > > have to be swift because the release is done in August.
 > >=20
 > > At least firefox is concerned, we've already have a patch since
 > > ports/r319816 - it no longer resort to fallback to libc.so but loads li=
 bc.so.7
 > > explicitly - it looks promising, though I haven't had a time to update =
 my ports
 > > tree to catch up and test with :(
 >=20
 > bapt@ should implement a simple framework in the ports to create a file
 > in /usr/local/etc/libmap.d/${PORTNAME}.conf.  This will allow port
 > maintainers to easily implement a workaround for this kind of softwares.
 >=20
 >=20
 > > > If if still crashes, can you run firefox with ktrace and provide me w=
 ith
 > > > the resulting file please?
 > >=20
 > > Again, I've rather been concerned about applications in general dependi=
 ng
 > > upon dlopen-able libc.so than particular ports which we can teach each
 > > and every one not to do so.
 >=20
 > The core problem is that libc.so (or any other .so) is historically
 > used by both the linker and the runtime loader.  This worked well until
 > the linker could read an ld script from the .so.  Now we have to
 > decouple the rendez-vous point for the linker and rtld.
 >=20
 > I've implemented a patch that can solve this problem, but it is not
 > perfect.  Basically, when installing a .so which contains an ld script,
 > he will also create a .so.last symlink pointing to the real shared
 > object (thus actually decouplin the rendez-vous point).  I modified rtld
 > to try the .so.last first if it exists.
 >=20
 > http://people.freebsd.org/~jlh/rtld_last_so_suffix.patch
 >=20
 > I think this is slightly hackish but it works; if your application is
 > linked to an older version of the lib, it will fail but just as it would
 > fail today anyway.
 >=20
 > kib@ pointed that with the libmap.conf solution, your application will
 > still work even after the shared object major number is bumped
 > (libc.so.7 -> libc.so.8).
 >=20
 > This is more work for maintainers but on the other hand this means that
 > this kind of problems must be solved now (I think there are probably
 > less than 10 in the whole port tree) and this will be solved correctly.
 >=20
 > Whereas with my patch the problem doesn't exist and doen't have to be
 > fixed as long as the shared object major number is not bumped, but may
 > bite the user unexpectedly after a major FreeBSD upgrade (though he
 > would probably be answered to recompile the port or reinstall the
 > package).
 >=20
 > Do you have any thought on that?
 
 I also do not like the '.so.last' hack since it creates undocumented
 (in the ELF standard) behaviour deviating from the behaviour of the
 dynamic loaders on other ELF systems.  Any issues resulting from
 it would be very confusing and probably unpenetrable for the outside
 developer.
 
 --A7a15KRh1eqpVFgU
 Content-Type: application/pgp-signature
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.20 (FreeBSD)
 
 iQIcBAEBAgAGBQJR/2JlAAoJEJDCuSvBvK1BZzgP/3gq5AxH1V9CtBp1kijA+0d3
 /I02c42nCE1R7VdgmSMoXzjdavKR2Bb/YhEEOYmRsvF6018jn72S4pc09dJXJQaD
 HXk562c4wXJms5T+O1VwP5E51iOobzK6VE0B5GI/U6uN+M0bmVAai2A+IQGEZaDL
 8g3n5ziEhvvg4IxU/k0KFUwW91H7Qt9wLIu8rmS9NZfZVFH83M8Yahc7ikDtfife
 0obn8h7BKRDteMD2v2LI+HRXML+589xTH66xxnWibPol6XKaqQ+LuA8zDWYtWt1K
 tREnltJXEujfn1SNPDlE4/I/d3j8D1NnAkvEOrlZd+/NUCOKh+udVeO8Ewr+TMBE
 PKACUC0pXU63TMO7exjifFiG8ER/uSd9pGFAkDQmhwQssXT8mJloRSHBvlKM6UFS
 VZigIH0KfeBwR3auYOCezmWHvDBFz9E5yEYiI3+LT5+2ZSJcqE6OloBc0WAW4zdD
 HemkC/SoJSnSU9tYUpGoFgOS6Os+JlISiUasOSThLf0yCZW633yllVAFp8ggkHoz
 587NsAeqjVOuEzYI4EoOM4hYRJwBLgYFkefnmb5N7shjwKJslziZw/4INkjcwPNS
 ydPWkUSWtiMhSYo6+OKtHZE5TU3Lx4VsAWW3mEjjJgoKAoc/5CoEzdbR9iCmhETY
 DG40auk3o0GUpLIn0a+d
 =TPpy
 -----END PGP SIGNATURE-----
 
 --A7a15KRh1eqpVFgU--

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/180568: commit references a PR
Date: Wed, 14 Aug 2013 17:49:16 +0000 (UTC)

 Author: jlh
 Date: Wed Aug 14 17:49:08 2013
 New Revision: 254332
 URL: http://svnweb.freebsd.org/changeset/base/254332
 
 Log:
   MFC r253853:
     Include /usr/local/etc/libmap.d/ by default.
   
     PR:             180568
     Reviewed by:    bapt
     Obtained from:  kib
 
 Added:
   stable/9/etc/libmap.conf
      - copied unchanged from r253853, head/etc/libmap.conf
 Modified:
   stable/9/etc/Makefile
 Directory Properties:
   stable/9/etc/   (props changed)
 
 Modified: stable/9/etc/Makefile
 ==============================================================================
 --- stable/9/etc/Makefile	Wed Aug 14 16:15:14 2013	(r254331)
 +++ stable/9/etc/Makefile	Wed Aug 14 17:49:08 2013	(r254332)
 @@ -22,6 +22,7 @@ BIN1=	crontab \
  	hosts.equiv \
  	inetd.conf \
  	libalias.conf \
 +	libmap.conf \
  	login.access \
  	login.conf \
  	mac.conf \
 
 Copied: stable/9/etc/libmap.conf (from r253853, head/etc/libmap.conf)
 ==============================================================================
 --- /dev/null	00:00:00 1970	(empty, because file is newly added)
 +++ stable/9/etc/libmap.conf	Wed Aug 14 17:49:08 2013	(r254332, copy of r253853, head/etc/libmap.conf)
 @@ -0,0 +1,2 @@
 +# $FreeBSD$
 +includedir /usr/local/etc/libmap.d
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/180568: commit references a PR
Date: Thu, 15 Aug 2013 08:12:24 +0000 (UTC)

 Author: jlh
 Date: Thu Aug 15 08:12:16 2013
 New Revision: 254357
 URL: http://svnweb.freebsd.org/changeset/base/254357
 
 Log:
   MFC r253853:
     Include /usr/local/etc/libmap.d/ by default.
   
     PR:             180568
     Reviewed by:    bapt
     Obtained from:  kib
   
   Approved by:      re (delphij)
 
 Added:
   releng/9.2/etc/libmap.conf
      - copied unchanged from r254332, stable/9/etc/libmap.conf
 Modified:
   releng/9.2/etc/Makefile
 Directory Properties:
   releng/9.2/etc/   (props changed)
 
 Modified: releng/9.2/etc/Makefile
 ==============================================================================
 --- releng/9.2/etc/Makefile	Thu Aug 15 07:54:31 2013	(r254356)
 +++ releng/9.2/etc/Makefile	Thu Aug 15 08:12:16 2013	(r254357)
 @@ -22,6 +22,7 @@ BIN1=	crontab \
  	hosts.equiv \
  	inetd.conf \
  	libalias.conf \
 +	libmap.conf \
  	login.access \
  	login.conf \
  	mac.conf \
 
 Copied: releng/9.2/etc/libmap.conf (from r254332, stable/9/etc/libmap.conf)
 ==============================================================================
 --- /dev/null	00:00:00 1970	(empty, because file is newly added)
 +++ releng/9.2/etc/libmap.conf	Thu Aug 15 08:12:16 2013	(r254357, copy of r254332, stable/9/etc/libmap.conf)
 @@ -0,0 +1,2 @@
 +# $FreeBSD$
 +includedir /usr/local/etc/libmap.d
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
>Unformatted:
