Re: [lustre-discuss] Static lfs?
Another off list note pointing out that lfs is likely a script now. So here's the bitter end: Ah, it looks like you're correct. There's still an lfs.c but it no longer generates the "lfs" executable as it previously - Instead there's a lengthy and complex script named "lfs" which is not invoked by "make", but only during the install process. That generates the lfs binary that is actually installed... Uck. Well, I found where it squirrels away the real binary when executed. Run the script lustre/utils/lfs in your build dir, and it will start lfs. Quit it, and you will find the actual lfs binary in lustre/utils/.libs/lt-lfs Maybe this particular bit of build tooling would be clearer if it didn't try to pretend it didn't exist by apeing the binary without actually being it? Thanks to John Bauer for help with this. From: lustre-discuss on behalf of Patrick Farrell Sent: Friday, March 23, 2018 3:17:14 PM To: lustre-discuss@lists.lustre.org Subject: Re: [lustre-discuss] Static lfs? Ah, interesting – I got a question off list about this, but I thought I’d reply here. ‘ldd’ on the lfs binary says “not a dynamic executable”. So it seems I’m confused (never was much for compilers and linkers). Here are the errors I get trying to run it on another node: ./lfs: line 202: cd: /home/build/paf/[……..]/lustre/utils: No such file or directory gcc: error: lfs.o: No such file or directory gcc: error: lfs_project.o: No such file or directory gcc: error: ./.libs/liblustreapi.so: No such file or directory gcc: error: ../../lnet/utils/lnetconfig/.libs/liblnetconfig.so From: lustre-discuss on behalf of Patrick Farrell Date: Friday, March 23, 2018 at 3:03 PM To: "lustre-discuss@lists.lustre.org" Subject: [lustre-discuss] Static lfs? Good afternoon, I’ve got a developer question that perhaps someone has some insight on. After some recent (a few months ago now) changes to make the Lustre libraries and utilities build dynamically linked rather than statically linked, I’ve got a problem. If I build an lfs binary just by doing “make”, the resultant binary looks for various libraries in the build directories and cannot be run on any system other than the one it was built on (well, I guess without replicating the build directory structure). When doing make rpms and installing the RPMs, it works fine. The problem is “make rpms” takes ~5 minutes, as opposed to ~1 second for “make” in /utils. (I assume “make install” works too, but I explicitly need to test on nodes other than the one where I’m doing the build, so that’s not an option.) Does anyone have any insight on a way around this for a developer? Either some tweak I can make locally to get static builds again, or some fix to make that would let the dynamically linked binary from “make” have correct library paths? (To be completely clear: The dynamically linked binary from “make” looks for libraries in the locations where they are built, regardless of whether or not they’re already installed in the normal system library locations.) Regards, Patrick Farrell ___ lustre-discuss mailing list lustre-discuss@lists.lustre.org http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
Re: [lustre-discuss] Static lfs?
Ah, interesting – I got a question off list about this, but I thought I’d reply here. ‘ldd’ on the lfs binary says “not a dynamic executable”. So it seems I’m confused (never was much for compilers and linkers). Here are the errors I get trying to run it on another node: ./lfs: line 202: cd: /home/build/paf/[……..]/lustre/utils: No such file or directory gcc: error: lfs.o: No such file or directory gcc: error: lfs_project.o: No such file or directory gcc: error: ./.libs/liblustreapi.so: No such file or directory gcc: error: ../../lnet/utils/lnetconfig/.libs/liblnetconfig.so From: lustre-discuss on behalf of Patrick Farrell Date: Friday, March 23, 2018 at 3:03 PM To: "lustre-discuss@lists.lustre.org" Subject: [lustre-discuss] Static lfs? Good afternoon, I’ve got a developer question that perhaps someone has some insight on. After some recent (a few months ago now) changes to make the Lustre libraries and utilities build dynamically linked rather than statically linked, I’ve got a problem. If I build an lfs binary just by doing “make”, the resultant binary looks for various libraries in the build directories and cannot be run on any system other than the one it was built on (well, I guess without replicating the build directory structure). When doing make rpms and installing the RPMs, it works fine. The problem is “make rpms” takes ~5 minutes, as opposed to ~1 second for “make” in /utils. (I assume “make install” works too, but I explicitly need to test on nodes other than the one where I’m doing the build, so that’s not an option.) Does anyone have any insight on a way around this for a developer? Either some tweak I can make locally to get static builds again, or some fix to make that would let the dynamically linked binary from “make” have correct library paths? (To be completely clear: The dynamically linked binary from “make” looks for libraries in the locations where they are built, regardless of whether or not they’re already installed in the normal system library locations.) Regards, Patrick Farrell ___ lustre-discuss mailing list lustre-discuss@lists.lustre.org http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
[lustre-discuss] Static lfs?
Good afternoon, I’ve got a developer question that perhaps someone has some insight on. After some recent (a few months ago now) changes to make the Lustre libraries and utilities build dynamically linked rather than statically linked, I’ve got a problem. If I build an lfs binary just by doing “make”, the resultant binary looks for various libraries in the build directories and cannot be run on any system other than the one it was built on (well, I guess without replicating the build directory structure). When doing make rpms and installing the RPMs, it works fine. The problem is “make rpms” takes ~5 minutes, as opposed to ~1 second for “make” in /utils. (I assume “make install” works too, but I explicitly need to test on nodes other than the one where I’m doing the build, so that’s not an option.) Does anyone have any insight on a way around this for a developer? Either some tweak I can make locally to get static builds again, or some fix to make that would let the dynamically linked binary from “make” have correct library paths? (To be completely clear: The dynamically linked binary from “make” looks for libraries in the locations where they are built, regardless of whether or not they’re already installed in the normal system library locations.) Regards, Patrick Farrell ___ lustre-discuss mailing list lustre-discuss@lists.lustre.org http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
Re: [lustre-discuss] Lustre client 2.10.3 build/install problem on Centos 6.7
Leo thanks a lot! The problem was that I somehow worked with lustre-2.10.3-1.src.rpm from el7 tree! (( The one from the link below built and updated perfectly Thanks again and sorry for such a mistake, Alex 2018-03-23 20:12 GMT+03:00 Leonardo Saavedra : > > On 03/23/2018 12:30 AM, Alex Vodeyko wrote: > > https://downloads.hpdd.intel.com/public/lustre/lustre-2.10.3/el6/client/SRPMS/lustre-2.10.3-1.src.rpm > <..> ___ lustre-discuss mailing list lustre-discuss@lists.lustre.org http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
Re: [lustre-discuss] Lustre client 2.10.3 build/install problem on Centos 6.7
On 03/23/2018 12:30 AM, Alex Vodeyko wrote: Hi, I'm trying to build/install Lustre 2.10.3 client on Centos 6.7. "rpmbuild --rebuild --without servers lustre/lustre-2.10.3-1.src.rpm" goes fine, but "yum localupdate kmod-lustre-client-2.10.3-1.el6.x86_64.rpm lustre-client-2.10.3-1.el6.x86_64.rpm" failed with: Error: Package: kmod-lustre-client-2.10.3-1.el6.x86_64 (/kmod-lustre-client-2.10.3-1.el6.x86_64) Requires: kernel >= 3.10.0-693 Centos 6.7 provides kernel series 2.6.32-* and it seems you are trying to build the lustre-client for centos/redhat 7.x (kernel 3.10.0-*) maybe you should try with: https://downloads.hpdd.intel.com/public/lustre/lustre-2.10.3/el6/client/SRPMS/lustre-2.10.3-1.src.rpm [lsaavedr@testupd /tmp]$ wget -c https://downloads.hpdd.intel.com/public/lustre/lustre-2.10.3/el6/client/SRPMS/lustre-2.10.3-1.src.rpm [root@testupd ~]# rpmbuild --rebuild --without servers /tmp/lustre-2.10.3-1.src.rpm Installing /tmp/lustre-2.10.3-1.src.rpm [...] Requires: /bin/bash /usr/bin/perl perl(File::Path) perl(Getopt::Long) perl(Getopt::Std) perl(POSIX) Processing files: lustre-client-debuginfo-2.10.3-1.el6.x86_64 Checking for unpackaged file(s): /usr/lib/rpm/check-files /root/kernel/rpmbuild/BUILDROOT/lustre-2.10.3-1.x86_64 Wrote: /root/kernel/rpmbuild/RPMS/x86_64/lustre-client-2.10.3-1.el6.x86_64.rpm Wrote: /root/kernel/rpmbuild/RPMS/x86_64/kmod-lustre-client-2.10.3-1.el6.x86_64.rpm Wrote: /root/kernel/rpmbuild/RPMS/x86_64/lustre-client-tests-2.10.3-1.el6.x86_64.rpm Wrote: /root/kernel/rpmbuild/RPMS/x86_64/kmod-lustre-client-tests-2.10.3-1.el6.x86_64.rpm Wrote: /root/kernel/rpmbuild/RPMS/x86_64/lustre-iokit-2.10.3-1.el6.x86_64.rpm Wrote: /root/kernel/rpmbuild/RPMS/x86_64/lustre-client-debuginfo-2.10.3-1.el6.x86_64.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.G2e68o [root@testupd ~]# rpm -Uvh /root/kernel/rpmbuild/RPMS/x86_64/lustre-client-2.10.3-1.el6.x86_64.rpm /root/kernel/rpmbuild/RPMS/x86_64/kmod-lustre-client-2.10.3-1.el6.x86_64.rpm Preparing... ### [100%] 1:kmod-lustre-client ### [ 50%] WARNING: /lib/modules/2.6.32-696.23.1.el6.x86_64/extra/lustre-client/fs/ptlrpc_gss.ko needs unknown symbol libcfs_next_nidstring WARNING: /lib/modules/2.6.32-696.23.1.el6.x86_64/extra/lustre-client/fs/ptlrpc_gss.ko needs unknown symbol lprocfs_stats_collector WARNING: /lib/modules/2.6.32-696.23.1.el6.x86_64/extra/lustre-client/fs/ptlrpc_gss.ko needs unknown symbol ktime_get_real_seconds WARNING: /lib/modules/2.6.32-696.23.1.el6.x86_64/extra/lustre-client/fs/ptlrpc_gss.ko needs unknown symbol libcfs_nid2str_r WARNING: /lib/modules/2.6.32-696.23.1.el6.x86_64/extra/lustre-client/fs/ptlrpc_gss.ko needs unknown symbol ktime_get_seconds WARNING: /lib/modules/2.6.32-696.23.1.el6.x86_64/extra/lustre-client/fs/ptlrpc_gss.ko needs unknown symbol lprocfs_str_to_s64 WARNING: /lib/modules/2.6.32-696.23.1.el6.x86_64/extra/lustre-client/fs/ptlrpc_gss.ko needs unknown symbol libcfs_next_nidstring WARNING: /lib/modules/2.6.32-696.23.1.el6.x86_64/extra/lustre-client/fs/ptlrpc_gss.ko needs unknown symbol lprocfs_stats_collector WARNING: /lib/modules/2.6.32-696.23.1.el6.x86_64/extra/lustre-client/fs/ptlrpc_gss.ko needs unknown symbol ktime_get_real_seconds WARNING: /lib/modules/2.6.32-696.23.1.el6.x86_64/extra/lustre-client/fs/ptlrpc_gss.ko needs unknown symbol libcfs_nid2str_r WARNING: /lib/modules/2.6.32-696.23.1.el6.x86_64/extra/lustre-client/fs/ptlrpc_gss.ko needs unknown symbol ktime_get_seconds WARNING: /lib/modules/2.6.32-696.23.1.el6.x86_64/extra/lustre-client/fs/ptlrpc_gss.ko needs unknown symbol lprocfs_str_to_s64 2:lustre-client ### [100%] [root@testupd ~]# --- Leo Saavedra NRAO ___ lustre-discuss mailing list lustre-discuss@lists.lustre.org http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
Re: [lustre-discuss] Lustre client 2.10.3 build/install problem on Centos 6.7
There are detailed build instructions on lustre.org wiki : http://wiki.lustre.org/Compiling_Lustre I built, installed and lustre client 2.10.3 works on SLF 6.x as below: > $ cat /etc/redhat-release > Scientific Linux Fermi release 6.9 (Ramsey) > $ uname -r > 2.6.32-696.1.1.el6.x86_64 > $ cat /etc/redhat-release > Scientific Linux Fermi release 6.8 (Ramsey) > $ uname -r > 2.6.32-642.15.1.el6.x86_64 Build script (in-kernel IB) to build lustre client to be installed on the same host: > $ cat lcb.inkernel-ib.sh > > #!/bin/bash > > DIR=../downloads/downloads.hpdd.intel.com > SRPM=lustre-2.10.3-1.src.rpm > > rpmbuild --rebuild --without servers --with lnet-dlc --with lustre-utils > $DIR/$SRPM > Essentially this is the command you use. There are extra arguments if you compile for different kernel, e.g. building on node with 3.10 for older kernel 2.6.32 . It looks like you are trying to install lustre client module built with newer kernel. Take a look at build logs. You have to install kernel-devel rpm for your kernel on build node. Alex. > On Mar 23, 2018, at 1:30 AM, Alex Vodeyko wrote: > > Hi, > > I'm trying to build/install Lustre 2.10.3 client on Centos 6.7. > "rpmbuild --rebuild --without servers lustre/lustre-2.10.3-1.src.rpm" goes > fine, but > "yum localupdate kmod-lustre-client-2.10.3-1.el6.x86_64.rpm > lustre-client-2.10.3-1.el6.x86_64.rpm" failed with: > Error: Package: kmod-lustre-client-2.10.3-1.el6.x86_64 > (/kmod-lustre-client-2.10.3-1.el6.x86_64) >Requires: kernel >= 3.10.0-693 > > Building and installing on the same system with 2.6.32-696.10.2.el6.x86_64 > kernel. > > Same procedure worked fine on the same system with lustre 2.10.1 client. > > Could you please help with it? > > Thanks, > Alex > > > > ___ > lustre-discuss mailing list > lustre-discuss@lists.lustre.org > http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org ___ lustre-discuss mailing list lustre-discuss@lists.lustre.org http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org