Bug 91444 - [PATCH] Fix compat?x library path of ldconfig_paths* in /etc/defaults/rc.conf
Summary: [PATCH] Fix compat?x library path of ldconfig_paths* in /etc/defaults/rc.conf
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: 6.0-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: Hiroki Sato
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-07 06:20 UTC by Yasuhiro Kimura
Modified: 2006-01-07 13:51 UTC (History)
0 users

See Also:


Attachments
patch-usr::src::etc::defaults::rc.conf (901 bytes, text/plain)
2006-01-07 06:20 UTC, Yasuhiro Kimura
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yasuhiro Kimura freebsd_committer freebsd_triage 2006-01-07 06:20:03 UTC
	Since compat?x libraries are provided as ports now and they are
	installed in /usr/local/lib/compat by default, the value of
	ldconfig_paths* in /etc/defaults/rc.conf should be changed so that
	it includes correct compat?x library path.
Comment 1 Hiroki Sato freebsd_committer freebsd_triage 2006-01-07 07:18:55 UTC
----Security_Multipart(Sat_Jan__7_16_18_55_2006_463)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

KIMURA Yasuhiro <yasu@utahime.org> wrote
  in <20060107061800.0BEFF49@eastasia.home.utahime.org>:

ya> 	Since compat?x libraries are provided as ports now and they are
ya> 	installed in /usr/local/lib/compat by default, the value of
ya> 	ldconfig_paths* in /etc/defaults/rc.conf should be changed so that
ya> 	it includes correct compat?x library path.

 IIRC each misc/compat?x already has a startup script to invoke
 ldconfig for ${PREFIX}/lib/compat, and especially compat5x
 needs a hack for the 32-bit libraries on FreeBSD/amd64.

 So I do not think simply adding an absolute directory
 /usr/local/lib/compat into the default rc.conf is useful.

--
| Hiroki SATO

----Security_Multipart(Sat_Jan__7_16_18_55_2006_463)--
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQBDv2tiTyzT2CeTzy0RAj/hAKCgsE/1gcd1WIKeu7HU1a9XCYZMIACffnK0
1fKpaTpiFZgR/LpyGJzF+NA=
=3gOP
-----END PGP SIGNATURE-----

----Security_Multipart(Sat_Jan__7_16_18_55_2006_463)----
Comment 2 Yasuhiro Kimura freebsd_committer freebsd_triage 2006-01-07 12:09:44 UTC
From: Hiroki Sato <hrs@FreeBSD.org>
Subject: Re: conf/91444: [PATCH] Fix compat?x library path of ldconfig_paths* in /etc/defaults/rc.conf
Date: Sat, 07 Jan 2006 16:18:55 +0900 (JST)

>  IIRC each misc/compat?x already has a startup script to invoke
>  ldconfig for ${PREFIX}/lib/compat, and especially compat5x
>  needs a hack for the 32-bit libraries on FreeBSD/amd64.

Following is my actual experience when I upgraded my home server from
4.11R/i386 to 6.0R/i386 recently. 

On 4.11R I used some commercial softwares which worked as daemon
process. I wanted to use them after upgrade, but unfortunately
binaries for 6.x are not provided.

So I installed misc/compat4x package from port. According to the
messages of install time, I added "compat4x_enable=YES" to
/etc/rc.conf and executed startup script of compat4x. Then I pkg_added
the packages of the commercial softwares. When I executed startup
scripts of them, programs were succssfully started up and worked as
daemon process. Everything seemed to fine.

But problem happened when I rebooted the system. On bootstrap stage,
some programs of commercial softwares complained they cannot find
shared libraries and did not startup. I investigated the problem and
found It was caused by the name of startup script. That is, startup
script of the commercial software in question is installed in
/usr/local/etc/rc.d and the file name begin with 'a'. so it was
invoked prior to the startup script of compat4x at boot time.

After some trials and errors, I solved this problem by adding
following 2 lines in /etc/rc.conf:

ldconfig_paths="/usr/local/lib/compat /usr/X11R6/lib /usr/local/lib /usr/local/lib/compat/pkg"
ldconfig_paths_aout="/usr/local/lib/compat/aout /usr/X11R6/lib/aout /usr/local/lib/aout"

and then I thought these value should be set properly in
/etc/default/rc.conf and sent this PR.

I admit this patch is not perfect solution for the ldconfig issue of
compat libraries. But surely there is the case that problem concerning
with compat library is solved by applying it.

And I would like to point out one more.

>  So I do not think simply adding an absolute directory
>  /usr/local/lib/compat into the default rc.conf is useful.

This patch does not add new directory entry. It only changes already
existing directory(/usr/lib/compat) entry to the more proper one.
Comment 3 Hiroki Sato freebsd_committer freebsd_triage 2006-01-07 13:47:31 UTC
----Security_Multipart(Sat_Jan__7_22_47_31_2006_973)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

KIMURA Yasuhiro <yasu@utahime.org> wrote
  in <20060107.210944.33530176.yasu@utahime.org>:

ya> But problem happened when I rebooted the system. On bootstrap stage,
ya> some programs of commercial softwares complained they cannot find
ya> shared libraries and did not startup. I investigated the problem and
ya> found It was caused by the name of startup script. That is, startup
ya> script of the commercial software in question is installed in
ya> /usr/local/etc/rc.d and the file name begin with 'a'. so it was
ya> invoked prior to the startup script of compat4x at boot time.

 I fixed misc/compat[45]x to make the startup scripts be invoked
 at earlier stage than before right now.  This should solve your
 problem, I think.

ya> >  So I do not think simply adding an absolute directory
ya> >  /usr/local/lib/compat into the default rc.conf is useful.
ya>
ya> This patch does not add new directory entry. It only changes already
ya> existing directory(/usr/lib/compat) entry to the more proper one.

 I meant changing the variable in defaults/rc.conf itself was pointless.

--
| Hiroki SATO

----Security_Multipart(Sat_Jan__7_22_47_31_2006_973)--
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQBDv8Z1TyzT2CeTzy0RApT9AKDJWncFqQZVCLhRYhsWJkD2udwWKACgnrI3
Bb+jBwkkyVT8QGfD5LmqR94=
=Zf86
-----END PGP SIGNATURE-----

----Security_Multipart(Sat_Jan__7_22_47_31_2006_973)----
Comment 4 Hiroki Sato freebsd_committer freebsd_triage 2006-01-07 13:50:13 UTC
State Changed
From-To: open->closed

The startup scripts of misc/compat[45]x have been renamed and it should 
solve this problem.  If your problem persists, please feel free to inform 
me again.  Thanks for the report! 


Comment 5 Hiroki Sato freebsd_committer freebsd_triage 2006-01-07 13:50:13 UTC
Responsible Changed
From-To: freebsd-bugs->hrs

I'll handle this.