Within star-sw-root5-base:latest Container, Build Fails at pkg stic #204
Comments
|
You need to apply this patch to not link libraries from star-sw/docker/Dockerfile.root5 Lines 108 to 120 in bf319f0 |
|
This seems to have fixed the first occurrence. However, the same problem reoccurs later in the build. Here are my exact steps. I started from a fresh clone of star-bnl/star-sw:
then:
I then applied the patch as suggested, though it had to go from lines 76 to 88 in the SL21c version of Dockerfile.root5. Lastly:
which eventually produces.... ... So, indeed it gets past the stic build but does not complete. |
|
Looking at your output, the piece that says Also, another important piece of information is that you try to build SL21c. While patching should definitely help with the linking error, you are likely to run into more issues when trying to compile "SL21c" with environment from "main", as this combination is not tested. I would suggest you figure out compiling the version of the code from "main" before moving on to "SL21c". |
|
Unfortunately, the current 'base' images are not directly compatible with the older releases. It means that in order to build a pre-Git release (< SL21c) with docker we need to either modify the Dockerfile (to recreate the base image) or patch the old code. The former should be preferred, but in either case I am afraid it can take a lot of work to make sure we get results close to the officially distributed binary releases... Nevertheless, it is possible to build some of the old releases with minimal modifications. I was able to come up with a common patch set that works for SL20a, SL20c, SL19d_2, SL18g, and SL18f_1. Below are the commands to give an idea how it all works. Of course "SL18f_1" can be replaced with another tag or branch name but there is absolutely no guarantee that these steps will work for any release. curl -L https://github.com/star-bnl/star-sw/archive/SL18f_1.tar.gz | tar xz
cd star-sw-SL18f_1
curl https://raw.githubusercontent.com/plexoos/star-sw/pr/pregit_patch/docker/Dockerfile.root5 -o Dockerfile
curl https://raw.githubusercontent.com/plexoos/star-sw/pr/pregit_patch/docker/pregit.patch -o pregit.patch
docker buildx build --load --tag star-sw-root5-build:SL18f_1 \
--cache-from ghcr.io/star-bnl/star-sw-root5-base:latest \
--build-arg PATCH_FILE=pregit.patch \
--build-arg BUILD_CMD="cons +StarVMC/Geometry && cons %OnlTools %St_geom_Maker" . |
|
Hi Dmitri, You wrote:
I assume by officially distributed binary releases you mean images built at BNL and made available? If so, where may I find them? Also, is there a hope of modifying the Dockerfile to recreate the base images as you mentioned? This would be an excellent data & software preservation technique and, I imagine, would be seen favorably by NP at DOE. |
|
Hi Richard, Is there a specific release (or releases) for which you want to have a container now? I would like to understand how far back we are looking at and focus the effort
By the official binary distributions I meant the libraries placed in /afs and /cvmfs volumes: I only mentioned it to stress that what we are trying to accomplish here with the Dockerfiles should be at some point verified against those. There are known differences in the environments although my expectation is that there is nothing critical. Just a warning.
Absolutely. That is our long term goal. I hope we can work out a more general solution for all. |
|
Hi Dmitri,
Thanks for your response and for asking about my release interests.
Yes, there are three in all, associated with the datasets I'm using.
Specifically, releases for the most recent productions of the 200 GeV
CuCu, the largest set of 200 GeV p+p available, and the largest set of
200 GeV AuAu available. I believe the releases are:
SL18h for the pp200 (from the 2015 run)
SL17i for the CuCu200
SL16k for the AuAu200
I certainly have an interest in the newer data sets as well, but my
most recent work has been based on the sets above (I thin the 2016 AuAu
is still the highest statistics run, but please correct me if I'm
wrong). Let me know if you need more information.
Best Regards,
Richard
…On 11/24/21 11:18 AM, Dmitri Smirnov wrote:
Hi Richard,
Is there a specific release (or releases) for which you want to have a
container now? I would like to understand how far back we are looking at
and focus the effort
I assume by officially distributed binary releases you mean images
built at BNL and made available? If so, where may I find them?
By the official binary distributions I meant the libraries placed in
/afs and /cvmfs volumes:
|/afs/rhic/star/packages/ /cvmfs/star.sdcc.bnl.gov/packages/ |
I only mentioned it to stress that what we are trying to accomplish here
with the Dockerfiles should be at some point verified against those.
There are known differences in the environments although my expectation
is that there is nothing critical. Just a warning.
Also, is there a hope of modifying the Dockerfile to recreate the
base images as you mentioned? This would be an excellent data &
software preservation technique and, I imagine, would be seen
favorably by NP at DOE.
Absolutely. That is our long term goal. I hope we can work out a more
general solution for all.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#204 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AWOIG64RA5HTASLNTQ2JZYDUNUF4LANCNFSM5IMRFZBA>.
--
"Education is the most powerful weapon which you can use to change
the world."
--Nelson Mandela
~~~***~~~***~~~***~~~***~~~***~~~***~~~***~~~***~~~***~~~***~~~***~~~
Dr. Richard Witt, Professor of Physics Phone (USNA): 410-293-6675
United States Naval Academy Email: ***@***.***
~~~***~~~***~~~***~~~***~~~***~~~***~~~***~~~***~~~***~~~***~~~***~~~
|
|
Using the procedure described in your post above (with appropriate changes to the library release of course):
I have attempted builds of the following library releases: SL12d, SL15e, SL16d, SL17d, SL18f_1, SL18h, and SL19d_2. Here are the results. == Two of the builds succeeded without issue, SL18f_1 and SL19d_2. ...
#22 317.9 #pragma link C++ class StDbServiceBroker+;
#22 317.9 #pragma link C++ class StDbTable+;
#22 317.9 #pragma link C++ class StlXmlTree+;
#22 317.9 cmd (normal)= rootcint -f .sl79_gcc485/OBJ/StRoot/StDbLib/StDbLib_Cint.cxx -c -DROOT_CINT -D__ROOT__ -I.sl79_gcc485/OBJ/StRoot/StDbLib -IStRoot/StDbLib -IStRoot/StDbLib -I. -IStRoot -I.sl79_gcc485/include -I/opt/software/linux-scientific7-x86_64/gcc-4.8.5/root-5.34.38-elvjk6rx43niicd6jxqj2uzxzth7vng2/include -I/opt/software/linux-scientific7-x86_64/gcc-4.8.5/mysql-5.7.27-pfyt3fwtkubcc5eazmoqfick3lgp67mf/include -DNoXmlTreeReader StDbTableDescriptor.h StDataBaseI.hh StDbConfigNode.hh StDbManager.hh StDbModifier.h StDbNode.hh StDbServiceBroker.h StDbTable.h StlXmlTree.h LinkDef.h
#22 318.1 Error: link requested for unknown class StDbServiceBroker .sl79_gcc485/OBJ/StRoot/StDbLib/LinkDef.h:12:
#22 318.1 Error: link requested for unknown class StlXmlTree .sl79_gcc485/OBJ/StRoot/StDbLib/LinkDef.h:14:
#22 318.1 Warning: Error occurred during reading source files
#22 318.1 Warning: Error occurred during dictionary source generation
#22 318.1 !!!Removing .sl79_gcc485/OBJ/StRoot/StDbLib/StDbLib_Cint.cxx .sl79_gcc485/OBJ/StRoot/StDbLib/StDbLib_Cint.h !!!
#22 318.1 Error: rootcint: error loading headers...
#22 318.1 cons: *** [.sl79_gcc485/OBJ/StRoot/StDbLib/StDbLib_Cint.cxx] Error 2
#22 318.1 cons: errors constructing .sl79_gcc485/OBJ/StRoot/StDbLib/StDbLib_Cint.h
------
Error: failed to solve: executor failed running [/bin/bash -c source /etc/profile && cd /star-sw && echo "${BUILD_CMD}" | bash -xe && find /star-sw/.$STAR_HOST_SYS -name *.o -exec rm '{}' \;]: exit code: 2(The above is for SL16d. SL17d is identical except for the leading step numbers. For SL17d they are #22 382.7 and #22 382.9. == The SL18h build fails in StShadowMaker. ...
#22 2006.1 .sl79_gcc485/OBJ/StRoot/StSpectraPool/StRareMaker/StRareMaker_Cint.cxx:4939:69: warning: deprecated conversion from string constant to 'Char_t* {aka char*}' [-Wwrite-strings]
#22 2006.1 p = new((void*) gvp) StReadRare((Int_t) G__int(libp->para[0]));
#22 2006.1 ^
#22 2016.2 .sl79_gcc485/OBJ/StRoot/StShadowMaker/StShadowMaker.cxx:1:1: error: stray '\' in program
#22 2016.2 yEB66HV9K?Z=\DTN`IDQJ/ZWKK]kN`TO2Q9ICU>9F?$OL@@R`CUIdGfN^XjSN[TxDA55GU8J>Y<[
#22 2016.2 ^
#22 2016.2 .sl79_gcc485/OBJ/StRoot/StShadowMaker/StShadowMaker.cxx:1:1: error: stray '`' in program
#22 2016.2 .sl79_gcc485/OBJ/StRoot/StShadowMaker/StShadowMaker.cxx:1:1: error: stray '`' in program
#22 2016.2 .sl79_gcc485/OBJ/StRoot/StShadowMaker/StShadowMaker.cxx:1:46: error: stray '@' in program
#22 2016.2 yEB66HV9K?Z=\DTN`IDQJ/ZWKK]kN`TO2Q9ICU>9F?$OL@@R`CUIdGfN^XjSN[TxDA55GU8J>Y<[
#22 2016.2 ^
#22 2016.2 .sl79_gcc485/OBJ/StRoot/StShadowMaker/StShadowMaker.cxx:1:47: error: stray '@' in program
#22 2016.2 yEB66HV9K?Z=\DTN`IDQJ/ZWKK]kN`TO2Q9ICU>9F?$OL@@R`CUIdGfN^XjSN[TxDA55GU8J>Y<[
#22 2016.2 ^
#22 2016.2 .sl79_gcc485/OBJ/StRoot/StShadowMaker/StShadowMaker.cxx:1:1: error: stray '`' in program
#22 2016.2 yEB66HV9K?Z=\DTN`IDQJ/ZWKK]kN`TO2Q9ICU>9F?$OL@@R`CUIdGfN^XjSN[TxDA55GU8J>Y<[followed by many lines of errors containing garbage characters. == The SL15e build fails in StBTofSimMaker with the following: ...
#22 176.7 ConstructTable.pl pams/sim/idl/g2t_vpd_hit.idl .sl79_gcc485/include/tables/St_g2t_vpd_hit_Table.h
#22 176.7 g++ -m64 -fPIC -pipe -Wall -Woverloaded-virtual -std=c++0x -Wno-long-long -falign-loops=2 -falign-jumps=2 -falign-functions=2 -pthread -std=c++11 -Wno-deprecated-declarations -m64 -O -g -Dsl79_gcc485 -D__ROOT__ -DNEW_DAQ_READER -I. -IStRoot -I.sl79_gcc485/include -I/opt/software/linux-scientific7-x86_64/gcc-4.8.5/root-5.34.38-elvjk6rx43niicd6jxqj2uzxzth7vng2/include -c .sl79_gcc485/OBJ/StRoot/StBTofSimMaker/StBTofSimMaker.cxx -o .sl79_gcc485/OBJ/StRoot/StBTofSimMaker/StBTofSimMaker.o
#22 177.4 In file included from .sl79_gcc485/OBJ/StRoot/StBTofSimMaker/StBTofSimMaker.cxx:45:0:
#22 177.4 .sl79_gcc485/OBJ/StRoot/StBTofSimMaker/StBTofSimMaker.h:86:35: error: 'constexpr' needed for in-class initialization of static data member 'const float StBTofSimMaker::mVHRBIN2PS' of non-integral type [-fpermissive]
#22 177.4 const static float mVHRBIN2PS = 24.4; //! Very High resolution mode, ps/bin
#22 177.4 ^== Lastly, the SL12d build fails almost immediately due to what looks like a compiler error (the compiler in the base container is too new). ... (several warnings about invalid suffix on literal; C++11 requires a space between literal and identifier)
#22 24.83 StRoot/RTS/include/rtsLog.h:243:38: warning: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wliteral-suffix]
#22 24.83 rtsLogUnix_v(""SEV": "__FILE__" [line %d]: "STRING"\n" , __LINE__ , ##ARGS) ;\
#22 24.83 ^
#22 24.83 StRoot/RTS/include/rtsLog.h:243:55: warning: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wliteral-suffix]
#22 24.83 rtsLogUnix_v(""SEV": "__FILE__" [line %d]: "STRING"\n" , __LINE__ , ##ARGS) ;\
#22 24.83 ^
#22 24.85 In file included from .sl79_gcc485/OBJ/StRoot/RTS/src/RTS_EXAMPLE/daqFileChopper.C:24:0:
#22 24.85 StRoot/RTS/src/DAQ_READER/daq_dta.h: In member function 'virtual const char* daq_dta::GetCVS() const':
#22 24.85 StRoot/RTS/src/DAQ_READER/daq_dta.h:147:112: error: inconsistent user-defined literal suffixes '__DATE__' and '__TIME__' in string literal
#22 24.85 static const char cvs[]="Tag $Name: $: $Id: daq_dta.h,v 1.6 2010/12/02 07:28:20 tonko Exp $: built "__DATE__" "__TIME__ ;
#22 24.85 ^
#22 24.85 StRoot/RTS/src/DAQ_READER/daq_dta.h:147:112: error: unable to find string literal operator 'operator"" __DATE__'
#22 24.85 In file included from .sl79_gcc485/OBJ/StRoot/RTS/src/RTS_EXAMPLE/daqFileChopper.C:19:0:
#22 24.85 .sl79_gcc485/OBJ/StRoot/RTS/src/RTS_EXAMPLE/daqFileChopper.C: In function 'void displayHelp()':
#22 24.85 StRoot/RTS/include/rtsLog.h:243:75: error: unable to find string literal operator 'operator"" __FILE__'
#22 24.85 rtsLogUnix_v(""SEV": "__FILE__" [line %d]: "STRING"\n" , __LINE__ , ##ARGS) ;\
#22 24.85 ^
#22 24.85 .sl79_gcc485/OBJ/StRoot/RTS/src/RTS_EXAMPLE/daqFileChopper.C:28:5: note: in expansion of macro 'LOG'
#22 24.85 LOG(ERR,"Usage: daqFileChopper filename <filterlist>");
#22 24.85 ^Please let me know how I can help in resolving these. It looks like a single fix might work for SL16d and SL17d, but the others are more challenging. Best Regards, |
|
Hi, I am reviewing old issues on rainy Sunday afternoon ... this particular issue has not been followed up in ~2 years. Is there still a need to leave it open? Has it been followed up in some other way? Please advise. |
|
Closed after consultation with @R-Witt |
Command was (within directory star-sw):
docker run -it --rm -v $PWD:/star-sw ghcr.io/star-bnl/star-sw-root5-base:latest /bin/bash -lc "cd star-sw && cons"Result:
...
build root4star with cons
DEBUG -Wl,--whole-archive -Wl,-Bstatic -Wl,-z -Wl,muldefs -lstarsim -Wl,--no-whole-archive -Wl,-Bdynamic -lCore -lCint -lRIO -lNet -lHist -lGraf -lGraf3d -lGpad -lTree -lRint -lPostscript -lMatrix -lPhysics -lMathCore -lThread -lGeom -lTable -lgeant321 -lgcalor /cern/pro/lib/libpawlib.a /cern/pro/lib/liblapack3.a /cern/pro/lib/libblas.a /cern/pro/lib/libpacklib.a /cern/pro/lib/libgraflib.a /cern/pro/lib/libgrafX11.a /cern/pro/lib/libpacklib.a /cern/pro/lib/libmathlib.a /cern/pro/lib/libkernlib.a -L/usr/X11R6/lib -lX11 -lnsl -lcrypt -ldl -Wl,--whole-archive -Wl,-Bstatic -Wl,-z -Wl,muldefs -lmysqlclient -lpthread -lm -lrt -ldl -Wl,--no-whole-archive -Wl,-Bdynamic -lgfortran -L/usr/X11R6/lib64 -lXt -lXpm -lX11 -lm -ldl -lrt -rdynamic -pthread
build stic with cons
DEBUG CXX_VERSION -- 4.8.5
Run Conscript-standard in pams/ctf for libctf_Tables
Run Conscript-standard in pams/ctf for St_ctf
Run Conscript-standard in pams/emc for libemc_Tables
Run Conscript-standard in pams/ftpc for libftpc_Tables
Run Conscript-standard in pams/gen for libgen_Tables
Run Conscript-standard in pams/geometry for libgeometry_Tables
Run Conscript-standard in pams/geometry for geometry
Run Conscript-standard in pams/geometry for geometryNoField
Run Conscript-standard in pams/global for libglobal_Tables
Run Conscript-standard in pams/l3 for l3
Run Conscript-standard in pams/sim for libsim_Tables
Run Conscript-standard in pams/sim/control for control
Run Conscript-standard in pams/sim/dig for dig
Run Conscript-standard in pams/sim/flux for flux
Run Conscript-standard in pams/sim/g2r for g2r
Run Conscript-standard in pams/sim/g2t for St_g2t
Run Conscript-standard in pams/sim/gstar for gstar
Run Conscript-standard in pams/svt for libsvt_Tables
Run Conscript in pams/tables for St_Tables
g++ -O2 -g -falign-loops -falign-jumps -falign-functions -m64 -Wl,-export-dynamic -Wl,-noinhibit-exec,-Bdynamic .sl88_gcc789/OBJ/asps/rexe/MAIN_rmain.o .sl88_gcc789/OBJ/asps/rexe/df.o .sl88_gcc789/OBJ/asps/rexe/root4star_Cint.o .sl88_gcc789/OBJ/asps/rexe/TGeant3/StarMC.o .sl88_gcc789/OBJ/asps/rexe/TGeant3/TGiant3.o .sl88_gcc789/OBJ/asps/rexe/TGeant3/gcadd.o .sl88_gcc789/OBJ/asps/rexe/TGeant3/galicef.o .sl88_gcc789/OBJ/asps/rexe/TGeant3/gcomad.o -L/opt/software/linux-scientific7-x86_64/gcc-4.8.5/root-5.34.38-elvjk6rx43niicd6jxqj2uzxzth7vng2/lib -L.sl88_gcc789/LIB -L/opt/software/linux-scientific7-x86_64/gcc-4.8.5/root-5.34.38-elvjk6rx43niicd6jxqj2uzxzth7vng2/lib -L/opt/software/linux-scientific7-x86_64/gcc-4.8.5/mysql-5.7.27-pfyt3fwtkubcc5eazmoqfick3lgp67mf/lib -L/opt/software/lib -L/opt/software/linux-scientific7-x86_64/gcc-4.8.5/mysql-5.7.27-pfyt3fwtkubcc5eazmoqfick3lgp67mf/lib -Wl,--whole-archive -Wl,-Bstatic -Wl,-z -Wl,muldefs -lstarsim -Wl,--no-whole-archive -Wl,-Bdynamic -lCore -lCint -lRIO -lNet -lHist -lGraf -lGraf3d -lGpad -lTree -lRint -lPostscript -lMatrix -lPhysics -lMathCore -lThread -lGeom -lTable -lgeant321 -lgcalor /cern/pro/lib/libpawlib.a /cern/pro/lib/liblapack3.a /cern/pro/lib/libblas.a /cern/pro/lib/libpacklib.a /cern/pro/lib/libgraflib.a /cern/pro/lib/libgrafX11.a /cern/pro/lib/libpacklib.a /cern/pro/lib/libmathlib.a /cern/pro/lib/libkernlib.a -L/usr/X11R6/lib -lX11 -lnsl -lcrypt -ldl -Wl,--whole-archive -Wl,-Bstatic -Wl,-z -Wl,muldefs -lmysqlclient -lpthread -lm -lrt -ldl -Wl,--no-whole-archive -Wl,-Bdynamic -lgfortran -L/usr/X11R6/lib64 -lXt -lXpm -lX11 -lm -ldl -lrt -rdynamic -pthread -o .sl88_gcc789/OBJ/asps/rexe/root4star
/usr/bin/ld: cannot find -lpthread
/usr/bin/ld: cannot find -lrt
/usr/bin/ld: cannot find -ldl
collect2: error: ld returned 1 exit status
cons: *** [.sl88_gcc789/OBJ/asps/rexe/root4star] Error 1
cons: errors constructing .sl88_gcc789/OBJ/asps/rexe/root4star
However, all libraries are present in container. For example:
$> docker run -it --rm -v $PWD:/star-sw ghcr.io/star-bnl/star-sw-root5-base:latest /bin/bash -lc "cd star-sw && bash"[root@b1bdb971190f star-sw]# ll /lib64/libpthread*[root@b1bdb971190f star-sw]# ll /lib64/librt*[root@b1bdb971190f star-sw]# ll /lib64/libdl*The text was updated successfully, but these errors were encountered: