I've encountered the following error which has interrupted most of my builds:
cp: preserving permissions for ‘/home/user/exciting/src/FoX/objs/lib/libFoX_fsys.a’: Operation not supported
cp: preserving ACL for ‘/home/user/exciting/src/FoX/objs/lib/libFoX_fsys.a’: Operation not supported
Has anyone experienced this and can anyone provide a solution?
Thanks
This is a strange error that is difficult to explain remotely. As pointed out already, the error appear due to "cp -p". Why don't you try compile FoX without the -p key? Here is what you have to do then.
1. Go to the src/FoX directory.
2. Edit common/makefile. There is a line containing CP=cp -p. Remove -p.
3. Type make (still within src/FoX).
If it still does not work, there should be a different excuse. :) If it worked, return to the root directory of exciting and finish compiling.
Please, let us know if it works.
Andris,
This is a good point, and unfortunately I tried this yesterday with no success, which doesn't make any sense. Even when I remove -p, I'm getting the same error. I've gone over every file I can find to see if there are any other sources of cp -p, but I can't find any. I'm going to try a new build now and let you know if anything changes.
Sean
Actually, I had some trouble using "make" in FoX and in FoX/common. I will post the results
Before I edit the makefile, if I attempt to "make" inside common, the output is
mpif90 -c -g -I../objs/finclude -DFC_HAVE_FLUSH -DFC_HAVE_ABORT -DFC_ABORT_ARG -DFC_EOR_LF -DRESTRICTED_ASSOCIATED_BUG m_common_charset.F90
m_common_charset.F90(7): error #7002: Error in opening the compiled module file. Check INCLUDE paths. [FOX_M_FSYS_STRING]
use fox_m_fsys_string, only: toLower
--^
m_common_charset.F90(7): error #6580: Name in only-list does not exist. [TOLOWER]
use fox_m_fsys_string, only: toLower
-------^
m_common_charset.F90(262): error #6406: Conflicting attributes or multiple declaration of name. [TOLOWER]
enc = toLower(encoding)
--^
m_common_charset.F90(262): error #6054: A CHARACTER data type is required in this context. [TOLOWER]
enc = toLower(encoding)
--^
m_common_charset.F90(285): error #6406: Conflicting attributes or multiple declaration of name. [TOLOWER]
enc = toLower(encoding)
--^
m_common_charset.F90(285): error #6054: A CHARACTER data type is required in this context. [TOLOWER]
enc = toLower(encoding)
--^
compilation aborted for m_common_charset.F90 (code 1)
make: *** [m_common_charset.o] Error 1
If I attempt to make in FoX,
mkdir -p objs/lib objs/finclude
(cd fsys; make VPATH=/fsys)
make[1]: Entering directory ‘/home/user/exciting/src/FoX/fsys’
==> Creating libFoX_fsys.a with fox_m_fsys_abort_flush.o fox_m_fsys_array_str.o fox_m_fsys_format.o fox_m_fsys_parse_input.o fox_m_fsys_string.o fox_m_fsys_string_list.o fox_m_fsys_realtypes.o
cp -p libFoX_fsys.a /home/user/exciting/src/FoX/objs/lib
cp: preserving permissions for ‘/home/user/exciting/src/FoX/objs/lib/libFoX_fsys.a’: Operation not supported
cp: preserving ACL for ‘/home/user/exciting/src/FoX/objs/lib/libFoX_fsys.a’: Operation not supported
make[1]: * [install] Error 1
make[1]: Leaving directory ‘/home/user/exciting/src/FoX/fsys’
make: * [fsys_lib] Error 2
Now, I'll remove the -p. The same output as before is given with common, and within FoX,
mkdir -p objs/lib objs/finclude
(cd fsys; make VPATH=/fsys)
make[1]: Entering directory ‘/home/user/exciting/src/FoX/fsys’
==> Creating libFoX_fsys.a with fox_m_fsys_abort_flush.o fox_m_fsys_array_str.o fox_m_fsys_format.o fox_m_fsys_parse_input.o fox_m_fsys_string.o fox_m_fsys_string_list.o fox_m_fsys_realtypes.o
cp -p libFoX_fsys.a /home/user/exciting/src/FoX/objs/lib
cp: preserving permissions for ‘/home/user/exciting/src/FoX/objs/lib/libFoX_fsys.a’: Operation not supported
cp: preserving ACL for ‘/home/user/exciting/src/FoX/objs/lib/libFoX_fsys.a’: Operation not supported
make[1]: * [install] Error 1
make[1]: Leaving directory ‘/home/user/exciting/src/FoX/fsys’
make: * [fsys_lib] Error 2
I'm still getting an error about cp -p!
I have realised that the CP variable is defined in makefiles in every subdirectory of FoX. Then, this error makes sense. Try to execute
make CP=cp
The supplied environmental variable should override whatever is defined in the makefiles.
This was a REALLY good call. I was able to make CP=cp in FoX and FoX/common. In the exciting directory, the same command seemed to be working, but now I have
/tmp/ifortJ1vP4U.i90(6661): catastrophic error: Too many errors, exiting
compilation aborted for ../../src/src_inputparser/inputmodules.f90 (code 1)
which follows after, as it says, too many errors for me to include here. I'm going to try a clean run again and use the default Makefile with just mpif90 and see what happens. I'll use Make CP=cp this time.
askubuntu.c*m/questions/193898/preserve-permission-switch-not-working-with-cp
Is this on a super computer? Are you perhaps copying files that you are not owner of?
"the -p argument works for all users in the constraint of that users abilities on the system. generally non-root users will be able to preserve ownership of their files that they own and are owned by a group that the specific non-root user belongs to. they cannot preserve ownership of files owned by other users (albeit, there may be ways around this depending on the suid, guid, and sticky bits). root can preserve the ownership of files owned by different users, because root has full system priveledges. but joe_schmoe can not preserve the ownership of files owned by root or files owned by billy, etc. depending on where the file will be copied to, joe_schmoe can only preserve file ownership of files owned by joe_schmoe and owned by a group joe_schmoe belongs to."
This may be what is occurring. If you are not using a supercomputer and can log as a super user, try this first then attempt the install.
command:
$su
One of my builds that is failing is on a supercomputer, yes. The other countless number that have failed for this reason are not. I have consistently had trouble building Exciting, except on my Macbook Air (believe it or not). I'm really frustrated with this, because the structural optimization feature is exactly what I need that Elk (sister program) is missing.
I'll try a sudo install on my personal computers as you recommended and see how that goes. Unfortunately, my optimization runs are about to be one week long on my poor Macbook Air, and if I could put this on the supercomputer it would really make my life easier.
After doing a bit of google work, I found this error is common among persons working in ZFS and especially those working across ZFS and NFS file systems.
You didn't happen to install a ZFS file system, did you? Do you know which file systems you are using?
Best,
Robert
I honestly don't even know what a ZFS system is. I'm using two different Ubuntu, one Mac Air, and a supercomputer, and (suprisingly) everything works fine only on the Mac. I've wasted a lot of time trying to get this working on powerful computers. This irritating libFoX error is only one of many I've run into, but I'm determined to get Exciting running on the university cluster.
Ah,
I know your frustration. I spent months trying to get WIEN2k to work in parallel on the OSC Oakley cluster. Have you contacted the super computing help center? They were unable to help me, but you may have better luck.
ZFS is a file system. Your macbook uses an HFS+ file system and the super computer most likely utilizes NFS. It is basically how your computer stores and retrieves files.
Did you post what install parameters you are using? Do you know the configuration of the super computer?
$ifort -v
$gcc -v
$cat /etc/*-release
what version of mpi/mpich are you using? Do you have OpenMP? mvapich2?
Months??? I don't know how you stayed sane dealing with this kind of problem for so long.
Well, I was using pretty much the same parameters (almost identical) to what I've used in my Elk build (which performs perfectly in parallel, and I've NEVER had trouble installing). My (perfectly working) elk make.inc is
MAKE = make
F90 = mpif90
F90_OPTS = -O3 -ffast-math -funroll-loops -fopenmp
F77 = mpif90
F77_OPTS = -O3 -ffast-math -funroll-loops -fopenmp
AR = ar
LIB_SYS =
LIB_LPK = lapack.a blas.a
LIB_FFT = fftlib.a
One of my Exciting make.inc (the one made automatically, with the replacement of gfortran with mpif90) is
F90=mpif90
F77=$(F90)
F90_OPTS = -O3 -march=native # -flto
F77_OPTS = $(F90_OPTS)
CPP_ON_OPT = -cpp -DXS -DISO -DTETRA -DLIBXC
LIB_ARP =libarpack.a
LIB_LPK = -L./ -llapack -lblas
LIB_FFT = fftlib.a
LIB_BZINT= libbzint.a
LIBS= $(LIB_ARP) $(LIB_LPK) $(LIB_FFT) $(LIB_BZINT) # -flto -fwhole-program
F90_DEBUGOPTS=-g -fbounds-check -fbacktrace -Wall
F77_DEBUGOPTS= $(F90_DEBUGOPTS)
#Ignore if you don't have MPI or smplibs
MPIF90=mpif90
MPIF90_OPTS=$(F90_OPTS) $(CPP_ON_OPT) -DMPI -DMPIRHO -DMPISEC
F77MT=$(F77)
F90MT=$(F90)
SMP_LIBS=$(LIBS)
SMPF90_OPTS=-fopenmp $(F90_OPTS)
SMPF77_OPTS=$(SMPF90_OPTS)
BUILDMPI=true
BUILDSMP=false
Which leads to the error I've reported. If I change the format to resemble my successful Elk build, i.e.
F90_OPTS = -O3 -ffast-math -funroll-loops -fopenmp,
the same thing happens. If I use ifort, the same thing happens as well. I think this particular problem has to to do with permissions, like you said. I'm not sure how to deal with that, but I'll try to find someone at the HPC that can help. Until then, my Macbook will be sitting under a fan for the forseeable future, I suppose.
This may be irrelevant, but I noticed in Elk, your settings are recommended but in all other instances I would see F77=$F90 and F90=ifort or gfortran. It would seem you're specifying a parallel compiler for serial compilation with those settings.
Here is my (currently not optimized) make.inc :
[osu6811@oakley01 exciting]$ cat build/make.inc
F90=ifort
F90_OPTS = -O3 -ip -unroll -scalar_rep
CPP_ON_OPT = -cpp -DXS -DISO -DTETRA -DLIBXC
F77=$(F90)
F77_OPTS = -O3 -ip -unroll -scalar_rep
LIB_ARP =libarpack.a
#export USE_SYS_LAPACK=true
LIB_LPK = liblapack.a libblas.a
LIB_FFT = fftlib.a
LIB_BZINT=libbzint.a
LIBS= $(LIB_ARP) $(LIB_LPK) $(LIB_FFT) $(LIB_BZINT)
F90_DEBUGOPTS=-g -O0 -std03 -warn declarations -warn uncalled -check all -traceback -ftrapuv
F77_DEBUGOPTS=-g -O0 -warn declarations -warn uncalled -check all -traceback -ftrapuv
#Ignore if you don't have MPI or smplibs
MPIF90=mpif90
MPIF90_OPTS=$(F90_OPTS) $(CPP_ON_OPT) -DMPI -DMPIRHO -DMPISEC
F77MT=$(F77)
F90MT=$(F90)
SMP_LIBS=$(LIBS)
SMPF90_OPTS=$(F90_OPTS)
SMPF77_OPTS=$(SMPF90_OPTS)
MPISMPF90_OPTS=$(SMPF90_OPTS) -DMPI -DMPIRHO -DMPISECBUILDMPI=false
BUILDMPI=true
BUILDSMP=true
This compiles with the "ifort" options when issuing the make command. Contents of the bin are:
[osu6811@oakley01 exciting]$ ls bin
excitingmpi* excitingser* excitingsmp* spacegroup* species* stateconvert* stateinfo*
The only thing missing is hybrid smp-mpi version.
I attempted compiling with other options that seemed correct "ifort.xe" "ifort64" and "ifort.mpi.mkl"
All other options resulted in errors and an empty bin, aside from ifort.xe which produced only excitingser.
Not sure if my message is noticeable. See above…
Ok, I've tried with ifort, gfortran, and with default and different settings, but the only way to get past the FoXlib problem looks to be make CP=cp, and that leads to the error I mentioned above:
/tmp/ifortCbxW42.i90(6661): catastrophic error: Too many errors, exiting
compilation aborted for ../../src/src_inputparser/inputmodules.f90 (code 1)
So I'm still stuck.
But now apparently the problem occures elsewhere. This file is generated automatically. Maybe something got wrong, while you were trying to compile FoX with different options. Try deleting src/src_inputparser/inputmodules.f90. If compilation nevertheless fails, would you mind posting the entire error message (assuming it is not one thousand lines long)?
I removed the line indicated by Andris, ran "make clean" and "make" (not make CP=cp). This gave me the FoXlib error. I repeated the process using CP=cp and encountered this:
Makefile.mkmf is ready.
make[3]: Entering directory ‘/home/usr/exciting/build/serial’
ifort -O3 -ip -unroll -scalar_rep -cpp -DXS -DISO -DTETRA -DLIBXC -I./finclude -c ../../src/src_inputparser/modinputdom.f90
ifort -O3 -ip -unroll -scalar_rep -cpp -DXS -DISO -DTETRA -DLIBXC -I./finclude -c ../../src/src_inputparser/inputmodules.f90
../../src/src_inputparser/inputmodules.f90(854): error #6460: This is not a field name that is defined in the encompassing structure. [POINTARRAY]
allocate(getstructplot1d%pointarray(len))
-----^
../../src/src_inputparser/inputmodules.f90(856): error #6158: The structure-name is invalid or is missing.
getstructplot1d%pointarray(i+1)%point=>getstructpoint(&
^
../../src/src_inputparser/inputmodules.f90(948): error #6460: This is not a field name that is defined in the encompassing structure. [ORIGIN]
getstructplot2d%origin=>null()
----—^
../../src/src_inputparser/inputmodules.f90(950): error #6795: The target must be of the same type and kind type parameters as the pointer. [ORIGIN]
getstructplot2d%origin=>getstructorigin(&
--—^
../../src/src_inputparser/inputmodules.f90(961): error #6460: This is not a field name that is defined in the encompassing structure. [POINTARRAY]
allocate(getstructplot2d%pointarray(len))
-----^
../../src/src_inputparser/inputmodules.f90(963): error #6158: The structure-name is invalid or is missing.
getstructplot2d%pointarray(i+1)%point=>getstructpoint(&
^
../../src/src_inputparser/inputmodules.f90(1067): error #6460: This is not a field name that is defined in the encompassing structure. [ORIGIN]
getstructplot3d%origin=>null()
----^
../../src/src_inputparser/inputmodules.f90(1069): error #6795: The target must be of the same type and kind type parameters as the pointer. [ORIGIN]
getstructplot3d%origin=>getstructorigin(&
--—^
../../src/src_inputparser/inputmodules.f90(1080): error #6460: This is not a field name that is defined in the encompassing structure. [POINTARRAY]
allocate(getstructplot3d%pointarray(len))
-----^
../../src/src_inputparser/inputmodules.f90(1082): error #6158: The structure-name is invalid or is missing.
getstructplot3d%pointarray(i+1)%point=>getstructpoint(&
^
../../src/src_inputparser/inputmodules.f90(1427): error #6460: This is not a field name that is defined in the encompassing structure. [ATOMARRAY]
allocate(getstructstructure%atomarray(len))
------^
../../src/src_inputparser/inputmodules.f90(1429): error #6158: The structure-name is invalid or is missing.
getstructstructure%atomarray(i+1)%atom=>getstructatom(&
^
../../src/src_inputparser/inputmodules.f90(1435): error #6460: This is not a field name that is defined in the encompassing structure. [LDAPLUSU]
getstructstructure%LDAplusU=>null()
---—^
../../src/src_inputparser/inputmodules.f90(1437): error #6795: The target must be of the same type and kind type parameters as the pointer. [LDAPLUSU]
getstructstructure%LDAplusU=>getstructLDAplusU(&
---^
../../src/src_inputparser/inputmodules.f90(2669): error #6460: This is not a field name that is defined in the encompassing structure. [PLOT1D]
getstructphonons%plot1d=>null()
---^
../../src/src_inputparser/inputmodules.f90(2671): error #6795: The target must be of the same type and kind type parameters as the pointer. [PLOT1D]
getstructphonons%plot1d=>getstructplot1d(&
---^
../../src/src_inputparser/inputmodules.f90(2873): error #6460: This is not a field name that is defined in the encompassing structure. [PLOT1D]
getstructproperties%plot1d=>null()
----^
../../src/src_inputparser/inputmodules.f90(2875): error #6795: The target must be of the same type and kind type parameters as the pointer. [PLOT1D]
getstructproperties%plot1d=>getstructplot1d(&
----^
../../src/src_inputparser/inputmodules.f90(2889): error #6460: This is not a field name that is defined in the encompassing structure. [PLOT2D]
getstructproperties%plot2d=>null()
----^
../../src/src_inputparser/inputmodules.f90(2891): error #6795: The target must be of the same type and kind type parameters as the pointer. [PLOT2D]
getstructproperties%plot2d=>getstructplot2d(&
----^
../../src/src_inputparser/inputmodules.f90(2909): error #6460: This is not a field name that is defined in the encompassing structure. [KSTLIST]
getstructproperties%kstlist=>null()
------^
../../src/src_inputparser/inputmodules.f90(2911): error #6795: The target must be of the same type and kind type parameters as the pointer. [KSTLIST]
getstructproperties%kstlist=>getstructkstlist(&
----^
../../src/src_inputparser/inputmodules.f90(2919): error #6795: The target must be of the same type and kind type parameters as the pointer. [PLOT1D]
getstructproperties%plot1d=>getstructplot1d(&
----^
../../src/src_inputparser/inputmodules.f90(2927): error #6795: The target must be of the same type and kind type parameters as the pointer. [PLOT2D]
getstructproperties%plot2d=>getstructplot2d(&
----^
../../src/src_inputparser/inputmodules.f90(2933): error #6460: This is not a field name that is defined in the encompassing structure. [PLOT3D]
getstructproperties%plot3d=>null()
----^
../../src/src_inputparser/inputmodules.f90(2935): error #6795: The target must be of the same type and kind type parameters as the pointer. [PLOT3D]
getstructproperties%plot3d=>getstructplot3d(&
----^
../../src/src_inputparser/inputmodules.f90(2959): error #6795: The target must be of the same type and kind type parameters as the pointer. [KSTLIST]
getstructproperties%kstlist=>getstructkstlist(&
----^
../../src/src_inputparser/inputmodules.f90(2983): error #6795: The target must be of the same type and kind type parameters as the pointer. [PLOT1D]
getstructproperties%plot1d=>getstructplot1d(&
----^
../../src/src_inputparser/inputmodules.f90(2991): error #6795: The target must be of the same type and kind type parameters as the pointer. [PLOT2D]
getstructproperties%plot2d=>getstructplot2d(&
----^
../../src/src_inputparser/inputmodules.f90(2999): error #6795: The target must be of the same type and kind type parameters as the pointer. [PLOT3D]
getstructproperties%plot3d=>getstructplot3d(&
----^
/tmp/iforta9SicA.i90(6661): catastrophic error: Too many errors, exiting
compilation aborted for ../../src/src_inputparser/inputmodules.f90 (code 1)
make[3]: * [inputmodules.o] Error 1
make[3]: Leaving directory ‘/home/user/exciting/build/serial’
make[2]: * [bin] Error 2
make[2]: Leaving directory ‘/home/user/exciting/build/serial’
make[1]: * [all] Error 2
make[1]: Leaving directory ‘/home/user/exciting/build/serial’
make: * [serial] Error 2
This is puzzling… I do not get the error in that spot, and the compilation runs smoothly for me. The line number for the spot where the error occurs is 854, while in my case the same thing is in line 893. Do you try to compile the exciting-lithium release?
No, helium is not necessary. Could you send me that file src/src_inputparser/inputmodules.f90 by email to gulans {ät} physik.hu-berlin.de? I will try it my computer to see whether I get the same syntax error messages.
Just to confirm, you got your exciting package from this very website from the Download section, right?
I'm tempted to say the errors are related. You had FoX lib errors prior and now you are having issues with the inputparser. The FoX lib is responsible for parsing the input files I believe.
exciting-code.0rg/access-exciting-input-files
I think this long conversation deserves a short summary.
There were two problems here.
1. Problem. libfox would not compile, since "cp -p" did not work for some reason (probably because of the way the system is configured).
Solution. Append CP=cp to your make command.
2. Problem. inputmodules.f90 would not compile due to syntax errors. We have realized that for some unclear reason inputmodules.f90 was different than it should be. In case if this file is missing, it is automatically generated, and apparently it was somehow improperly updated.
Solution. Restore the proper version of inputmodules.f90. It can be recovered from the file exciting.lithium.tar.gz that was downloaded from our website.
