Details

    • Bug
    • Resolution: Incomplete
    • Minor
    • None
    • Lustre 2.7.0
    • automake 1.15, autoconf 2.69, make 4.1, gcc 4.9.2, linux 3.19.0
    • 3
    • 17480

    Description

      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.

      I ran:
      1) sh ./autogen.sh
      2) ./configure --disable-modules --prefix=/home/tureba/lustre-bin
      3) make
      4) make install

      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.

      According to ./configure --help, those files should be installed somewhere under the provided prefix.

      Attachments

        Issue Links

          Activity

            [LU-6240] make install not honouring --prefix

            Can be reopened when patch is available.

            adilger Andreas Dilger added a comment - Can be reopened when patch is available.

            Arthur, we'd be happy for you to submit a patch to improve the build system. Please see https://wiki.hpdd.intel.com/display/PUB/Submitting+Changes for more details.

            adilger Andreas Dilger added a comment - Arthur, we'd be happy for you to submit a patch to improve the build system. Please see https://wiki.hpdd.intel.com/display/PUB/Submitting+Changes for more details.

            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.

            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.

            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.

            tureba Arthur Filipe Martins Nascimento added a comment - 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. 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. 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.
            simmonsja James A Simmons added a comment - - edited

            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 LU-3958.

            simmonsja James A Simmons added a comment - - edited 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 LU-3958 .

            People

              wc-triage WC Triage
              tureba Arthur Filipe Martins Nascimento
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: