Summary: | [PATCH] Fix compat?x library path of ldconfig_paths* in /etc/defaults/rc.conf | ||||||
---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | Yasuhiro Kimura <yasu> | ||||
Component: | conf | Assignee: | Hiroki Sato <hrs> | ||||
Status: | Closed FIXED | ||||||
Severity: | Affects Only Me | ||||||
Priority: | Normal | ||||||
Version: | 6.0-RELEASE | ||||||
Hardware: | Any | ||||||
OS: | Any | ||||||
Attachments: |
|
Description
Yasuhiro Kimura
2006-01-07 06:20:03 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)---- 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. ----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)---- 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! Responsible Changed From-To: freebsd-bugs->hrs I'll handle this. |