[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why relink the library during make install?
From: |
Paul Lew |
Subject: |
Re: Why relink the library during make install? |
Date: |
Wed, 24 Jul 2002 14:03:28 -0700 |
>>>>> "Bruno" == Bruno Haible <address@hidden> writes:
Bruno> This only means that the one who does
Bruno> configure --prefix=/A
Bruno> make
Bruno> make install prefix=/B
Bruno> cannot expect that auxiliary files (in lib, share, doc,
Bruno> etc) will be found. The "make" process has no chance to put
Bruno> the pathnames /B/lib, /B/share etc. into the executables
Bruno> and libraries because it doesn't know about /B at that
Bruno> moment. In most cases, the installed package will not run.
When I specify prefix=/B, I am taking the responsibility to make sure
the package can be accessed correctly with the /A prefix. The
post processing is beyond the knowledge of the package.
ams>> If gettext doesn't follow this, then it should be fixed at
ams>> once.
Bruno> It cannot be fixed, because of the way shared library
Bruno> dependencies work.
Why not? If you trust the original 'make' produce the correct
libraries and use 'make install' to just copy files. Then it will be
the responsibilty of the person who issue the prefix=/B to make sure
files can be accessed correctly. The problem only happen when /A/foo
is the same as /B/foo at the end. In our setup here, the /B/foo will
be a symlink to /A/foo.
Paul>> Guess why in the world people using prefix=... in the 'make
Paul>> install' at all?
Bruno> a. Because they don't know about DESTDIR.
Or c. Because DESTDIR is not documented in the INSTALL.
Bruno> b. Because they think that all packages are automatically
Bruno> relocatable, as if they were single executables with no
Bruno> dependencies.
Bruno> You said that you have a post-installation process which
Bruno> whill make symlinks from /somewhere/bin to these various
Bruno> bin directories. Where is then the problem?
Two problems: (1) the process is not clean as it used to be. The
meaning of 'make install' has changed. (2) the installed version is
using prefix=/B and when I move package around in my filesystem I only
make sure the prefix=/A will work and this will the relocating of the
package impossible.
Bruno> On some operating systems, it cannot build the stuff
Bruno> completely until the shared libraries have been
Bruno> installed. This is why "make install" must relink.
On what kind of system? Dont you think we should keep the standard
and have specific setup for specific os rather than do the relink in
the make install process?
I will vote (not saying that it will count :-)) for keeping the 'make
install' to straight copy files and added new target like 'make
install-check' to relink the libraries for the specific os when
necessary. This way it will make everyone happy.
- Why relink the library during make install?, Paul Lew, 2002/07/24
- Re: Why relink the library during make install?, Bruno Haible, 2002/07/24
- Re: Why relink the library during make install?, Paul Lew, 2002/07/24
- Re: Why relink the library during make install?, Alfred M. Szmidt, 2002/07/24
- Re: Why relink the library during make install?, Russ Allbery, 2002/07/24
- Re: Why relink the library during make install?, Ralph Corderoy, 2002/07/31
- Re: Why relink the library during make install?, Miles Bader, 2002/07/31
- Re: Why relink the library during make install?, Thomas Bushnell, BSG, 2002/07/24
- Re: Why relink the library during make install?, Miles Bader, 2002/07/25
- Re: Why relink the library during make install?, Albert Chin, 2002/07/25
- Re: Why relink the library during make install?, Albert Chin, 2002/07/25
- Re: Why relink the library during make install?, Miles Bader, 2002/07/25
- Re: Why relink the library during make install?, Albert Chin, 2002/07/26