svn commit: trunk/uClibc
Peter S. Mazinger
ps.m at gmx.net
Tue Jun 6 10:05:19 UTC 2006
On Wed, 31 May 2006, Peter Kjellerstedt wrote:
> > -----Original Message-----
> > From: Mike Frysinger [mailto:vapier at gentoo.org]
> > Sent: Wednesday, May 31, 2006 10:40
> > To: Peter S. Mazinger
> > Cc: Peter Kjellerstedt; uclibc at uclibc.org
> > Subject: Re: svn commit: trunk/uClibc
> >
> > On Tuesday 30 May 2006 16:27, Peter S. Mazinger wrote:
> > > On Tue, 30 May 2006, Mike Frysinger wrote:
> > > > On Tuesday 30 May 2006 07:13, Peter Kjellerstedt wrote:
> > > > > Upgrading is not really an option for me until I get a
> > > > > new computer.
> > > > > And I believe I am not the only one using an older installation
> > > > > which has been running fine for years, so it is very likely that
> > > > > others will run into this very subtle problem as well.
> > > >
> > > > broken is broken ... as you may have noticed, i care very
> > > > little for bending over for such situations
> > > >
> > > > > cd lib && $(TAR) -cf - *.so.* | $(TAR) -xf - -C
> > > > > $(PREFIX)$(RUNTIME_PREFIX)lib
> > > >
> > > > use '-C lib' rather than 'cd lib' and see if you can use
> > > > tar to install all libs rather than using `install` and
> > > > `tar` and that'll work for me
> > >
> > > why not cp/install *.so and run ldconfig -n on the
> > > destination directory?
> >
> > as we've seen, using cp is unreliable on old broken systems
> >
> > i really really dislike the idea of using ldconfig
> > -mike
>
> Ok, I will try to make a collective response here to the issues
> that have been addressed in this thread.
>
> * The *.so files have been installed with mode 644 since r3080 of
> the toplevel Makefile (July 2001)... But I cannot see a reason
> as to why this was done, and I too think they should be installed
> executable.
> * We cannot use tar to install all libraries. This is due to the
> separation of the install_dev and the install_runtime targets.
> Neither can we use cp due to its incompatibility issues.
> Thus I still suggest using tar as per my previous suggestion,
> since it will mean the least changes to how the build system
> works.
>
> Here is my suggested patch for these two issues:
>
> Index: Makefile.in
> ===================================================================
> --- Makefile.in (revision 15242)
> +++ Makefile.in (working copy)
> @@ -251,9 +251,9 @@
> install_runtime:
> ifeq ($(HAVE_SHARED),y)
> $(INSTALL) -d $(PREFIX)$(RUNTIME_PREFIX)lib
> - $(INSTALL) -m 644
> lib/lib*-$(MAJOR_VERSION).$(MINOR_VERSION).$(SUBLEVEL).so \
> + $(INSTALL)
> lib/lib*-$(MAJOR_VERSION).$(MINOR_VERSION).$(SUBLEVEL).so \
> $(PREFIX)$(RUNTIME_PREFIX)lib
> - cp -PRf lib/*.so.* $(PREFIX)$(RUNTIME_PREFIX)lib
> + cd lib && $(TAR) -cf - *.so.* | $(TAR) -xf - -C
> $(PREFIX)$(RUNTIME_PREFIX)lib
> @if [ -x
> lib/$(UCLIBC_LDSO_NAME)-$(MAJOR_VERSION).$(MINOR_VERSION).$(SUBLEVEL).so
> ] ; then \
> set -e; \
> $(SHELL_SET_X); \
>
> //Peter
ok with me, but now that I see it I recall another problem. The above
catches ld-uClibc-*.so.* as well, and that should go
SHARED_LIB_LOADER_PREFIX and RUNTIME_PREFIX/lib
limit maybe tar to lib*.so.* and correct ld-uClibc-*.so and ld-uClibc.so.0
installation.
Peter
--
Peter S. Mazinger <ps dot m at gmx dot net> ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
More information about the uClibc
mailing list