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 <lustre-discuss-boun...@lists.lustre.org> on behalf of Patrick Farrell <p...@cray.com> 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 <lustre-discuss-boun...@lists.lustre.org> on behalf of Patrick Farrell <p...@cray.com> Date: Friday, March 23, 2018 at 3:03 PM To: "lustre-discuss@lists.lustre.org" <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
