Hi, I feel for you :-p
as a matter of fact, any parallel fs chimes in with its own quirks during a build process. More than a dozen years ago, GPFS/2.2 would not support symlinks from a given size and above, go figure! For this and few other reasons, I consider pointing EASYBUILD_BUILDPATH towards /dev/shm or /tmp or so, a totally essential move. I’d rather get a failure fi. because /dev/shm is full, than risk having variating builds across two different (versions of) parallel filesystems. Truth be told, there is a `make install` step which may still ruin the day; I am not isolating that yet, but it is not entirely impossible: use a container or RPM to deliver, then use that towards your final destination. Indeed, that’s a project of its own. On Jun 20, 2017, at 9:52 PM, Heywood, Todd <[email protected]> wrote: > You can see the issue here: > > > xyz@bnbmgmt2:~/tmp$ g++ hello.cpp ; ./a.out > > -bash: ./a.out: cannot execute binary file > > xyz@bnbmgmt2:~/tmp$ ./a.out # it work a couple seconds later Finally, this seems to be yet another example of the tension between metadata consistency and need for speed. What is a matter of wonder though is, why the compiler version is important! It could be that the way the compiler opens the output file for writing makes some kind of difference. (weird.. strace is your friend) Thanks for reporting this! F. On Jun 21, 2017, at 6:52 AM, Kenneth Hoste <[email protected]> wrote: > Hi Todd, > > We ran into this issue too a while ago, but it wasn't this extreme, I was > only able to reproduce this using OCaml... > > We reported this back to IBM, and we eventually applied a fix (GPFS update, I > think, in Aug'16), that resolved the problem for us. > > I can try to get more information on this if it would be useful for you. > > > regards, > > Kenneth > > On 20/06/2017 22:52, Heywood, Todd wrote: >> Has anyone installed easybuild on GPFS, not NFS? We just migrated our >> easybuild installation to GPFS, and now when we use an Easybuild-built >> compiler to build software (on GPFS), the “configure” step fails when tests >> the compiler to create an executable, and tests whether the executable >> works. You can see the issue here: >> >> >> xyz@bnbmgmt2:~/tmp$ g++ hello.cpp ; ./a.out >> >> -bash: ./a.out: cannot execute binary file >> >> xyz@bnbmgmt2:~/tmp$ ./a.out # it work a couple seconds later >> >> Hello World!heywood@bnbmgmt2:~/tmp$ >> >> xyz@bnbmgmt2:~/tmp$ >> >> xyz@bnbmgmt2:~/tmp$ g++ hello.cpp ; file a.out >> >> a.out: data >> >> xyz@bnbmgmt2:~/tmp$ file a.out # gives expected output a couple seconds later >> >> a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically >> linked (uses shared libs), for GNU/Linux 2.6.18, not stripped >> >> xyz@bnbmgmt2:~/tmp$ >> >> Thanks, >> >> T >> > cheers, Fotis -- echo "sysadmin know better bash than english" | sed s/min/mins/ \ | sed 's/better bash/bash better/' # signal detected in a CERN forum
