https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-6240 Lustre <p>Using git master, I'm trying to configure/compile/install with different options in order to compare the end result, as a way to learn more about Lustre.</p> <p>I ran:<br/> 1) sh ./autogen.sh<br/> 2) ./configure --disable-modules --prefix=/home/tureba/lustre-bin<br/> 3) make<br/> 4) make install</p> <p>The last step showed install errors as make tried files to install to places outside the prefix I informed. The output of "make -ks" is attached.</p> <p>According to ./configure --help, those files should be installed somewhere under the provided prefix.</p> automake 1.15, autoconf 2.69, make 4.1, gcc 4.9.2, linux 3.19.0 LU-6240

make install not honouring --prefix

Bug Minor Resolved Incomplete WC Triage Arthur Filipe Martins Nascimento configure install make prefix Thu, 12 Feb 2015 20:00:25 +0000 Wed, 13 Oct 2021 01:44:08 +0000 Wed, 13 Oct 2021 01:44:08 +0000 Lustre 2.7.0 0 4 <p>mkfs.lustre is hardcoded to /sbin and you will have problems with the /etc files as they are hard coded too. I recommend you look at <a href="https://jira.whamcloud.com/browse/LU-3958" title="Reevaluate method for installing rpms in different root" class="issue-link" data-issue-key="LU-3958"><del>LU-3958</del></a>.</p> <p>I see. The not-yet-relocatable is enough justification for the files to be in exactly these places at run time, but not necessarily for them to be put there on build time. Specially in systems in which package managers are responsible for the actual run time installations, having install scripts messing with the build machine's root is really not ideal.</p> <p>So if I provide a small patch so that "make install" will honour the prefix, it won't solve the other issue's main problem, but it will make the build more self-contained, which is an advantage so I don't have to build it inside a nspawn anymore and other people won't need a dedicated build machine either.</p> <p>Would that be acceptable? It would solve all my problems and would be a step forward for the build system. The hardcodes never prevented anyone from shooting their own foot by trying to use rpm --root anyway, so I don't see why keep the behaviour.</p> <p>Arthur, we'd be happy for you to submit a patch to improve the build system. Please see <a href="https://wiki.hpdd.intel.com/display/PUB/Submitting+Changes" class="external-link" target="_blank" rel="nofollow noopener">https://wiki.hpdd.intel.com/display/PUB/Submitting+Changes</a> for more details. </p> <p>Can be reopened when patch is available.</p> Related LU-3953 Development Rank 1|hzx69z: Rank (Obsolete) 17480 Severity