Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ROOT master] Get latest commits #5800

Conversation

mrodozov
Copy link
Contributor

@mrodozov mrodozov commented May 4, 2020

please test

@cmsbuild
Copy link
Contributor

cmsbuild commented May 4, 2020

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-run-pr-tests/5988/console Started: 2020/05/05 04:11

@cmsbuild
Copy link
Contributor

cmsbuild commented May 4, 2020

A new Pull Request was created by @mrodozov (Mircho Rodozov) for branch IB/CMSSW_11_1_X/rootmaster.

@cmsbuild, @smuzaffar, @mrodozov, @tulamor can you please review it and eventually sign? Thanks.
cms-bot commands are listed here

@cmsbuild
Copy link
Contributor

cmsbuild commented May 5, 2020

-1

Tested at: 5f80c00

CMSSW: CMSSW_11_1_ROOT6_X_2020-05-04-2300
SCRAM_ARCH: slc7_amd64_gcc820
You can see the results of the tests here:
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-370a62/5988/summary.html

I found follow errors while testing this PR

Failed tests: Build

  • Build:

I found compilation error when building:

>> Building Root dict from header file src/SimTransport/TotemRPProtonTransportParametrization/src/SimTransportTotemRPProtTranspParLinkDef.h 
>> Compiling root dictionary tmp/slc7_amd64_gcc820/src/SimTransport/TotemRPProtonTransportParametrization/src/SimTransportTotemRPProtonTransportParametrization/b/SimTransportTotemRPProtonTransportParametrization_yr.cc 
>> Compiling  /data/cmsbld/jenkins/workspace/ib-run-pr-tests/CMSSW_11_1_ROOT6_X_2020-05-04-2300/src/SimTransport/TotemRPProtonTransportParametrization/src/LHCOpticsApproximator.cc 
>> Compiling  /data/cmsbld/jenkins/workspace/ib-run-pr-tests/CMSSW_11_1_ROOT6_X_2020-05-04-2300/src/SimTransport/TotemRPProtonTransportParametrization/src/TMultiDimFet.cc 
/data/cmsbld/jenkins/workspace/ib-run-pr-tests/CMSSW_11_1_ROOT6_X_2020-05-04-2300/src/SimTransport/TotemRPProtonTransportParametrization/src/TMultiDimFet.cc: In member function 'virtual void TMultiDimFet::MakeRealCode(const char*, const char*, Option_t*)':
/data/cmsbld/jenkins/workspace/ib-run-pr-tests/CMSSW_11_1_ROOT6_X_2020-05-04-2300/src/SimTransport/TotemRPProtonTransportParametrization/src/TMultiDimFet.cc:1477:11: error: aggregate 'TDatime date' has incomplete type and cannot be defined
   TDatime date;
           ^~~~
gmake: *** [tmp/slc7_amd64_gcc820/src/SimTransport/TotemRPProtonTransportParametrization/src/SimTransportTotemRPProtonTransportParametrization/TMultiDimFet.cc.o] Error 1
>> Building shared library tmp/slc7_amd64_gcc820/src/SimTransport/TotemRPProtonTransportParametrization/src/SimTransportTotemRPProtonTransportParametrization/libSimTransportTotemRPProtonTransportParametrization.so
c++: error: tmp/slc7_amd64_gcc820/src/SimTransport/TotemRPProtonTransportParametrization/src/SimTransportTotemRPProtonTransportParametrization/TMultiDimFet.cc.o: No such file or directory


@cmsbuild
Copy link
Contributor

cmsbuild commented May 5, 2020

Comparison not run due to Build errors (RelVals and Igprof tests were also skipped)

fix the missing headers until cmake solution is provided or ROOT team suggestion
@cmsbuild
Copy link
Contributor

cmsbuild commented May 5, 2020

Pull request #5800 was updated.

@mrodozov
Copy link
Contributor Author

mrodozov commented May 5, 2020

please test with cms-sw/cmssw#29740

@cmsbuild
Copy link
Contributor

cmsbuild commented May 5, 2020

The tests are being triggered in jenkins.
Tested with other pull request(s) cms-sw/cmssw#29740
https://cmssdt.cern.ch/jenkins/job/ib-run-pr-tests/6113/console Started: 2020/05/05 22:11

@cmsbuild
Copy link
Contributor

cmsbuild commented May 6, 2020

-1

Tested at: 7b6fbf3

CMSSW: CMSSW_11_1_ROOT6_X_2020-05-04-2300
SCRAM_ARCH: slc7_amd64_gcc820
You can see the results of the tests here:
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-49d36f/6113/summary.html

I found follow errors while testing this PR

Failed tests: Build

  • Build:

I found compilation error when building:

>> Compiling  /data/cmsbld/jenkins/workspace/ib-run-pr-tests/CMSSW_11_1_ROOT6_X_2020-05-04-2300/src/Fireworks/Core/src/FWEveDigitSetScalableMarker.cc 
>> Building LCG reflex dict from header file src/Fireworks/Core/src/classes.h
>> Compiling LCG dictionary: tmp/slc7_amd64_gcc820/src/Fireworks/Core/src/FireworksCore/a/FireworksCore_xr.cc
>> Building shared library tmp/slc7_amd64_gcc820/src/Fireworks/Core/src/FireworksCore/libFireworksCore.so
/cvmfs/cms-ib.cern.ch/nweek-02627/slc7_amd64_gcc820/external/gcc/8.2.0-pafccj/bin/../lib/gcc/x86_64-unknown-linux-gnu/8.3.1/../../../../x86_64-unknown-linux-gnu/bin/ld: cannot find -lGLEW
collect2: error: ld returned 1 exit status
gmake: *** [tmp/slc7_amd64_gcc820/src/Fireworks/Core/src/FireworksCore/libFireworksCore.so] Error 1
Leaving library rule at Fireworks/Core
>> Compiling  /data/cmsbld/jenkins/workspace/ib-run-pr-tests/CMSSW_11_1_ROOT6_X_2020-05-04-2300/src/Fireworks/Core/bin/cmsShowSendReport.cc 
>> Building binary cmsShowSendReport
Copying tmp/slc7_amd64_gcc820/src/Fireworks/Core/bin/cmsShowSendReport/cmsShowSendReport to productstore area:


@cmsbuild
Copy link
Contributor

cmsbuild commented May 7, 2020

The tests are being triggered in jenkins.
Tested with other pull request(s) cms-sw/cmssw#29740
https://cmssdt.cern.ch/jenkins/job/ib-run-pr-tests/6167/console Started: 2020/05/08 01:43

@cmsbuild
Copy link
Contributor

cmsbuild commented May 8, 2020

-1

Tested at: 08f8caa

  • Build:

I found compilation error when building:

File "./pkgtools/cmsBuild", line 3396, in installPackage
installRpm(pkg, pkg.options.bootstrap)
File "./pkgtools/cmsBuild", line 3134, in installRpm
raise RpmInstallFailed(pkg, output)
RpmInstallFailed: Failed to install package root. Reason:
error: Failed dependencies:
	libGLEW.so.2.1()(64bit) is needed by lcg+root+6.21.01-49d36f-1-1.x86_64

* The action "build-external+rivet+3.1.0-49d36f" was not completed successfully because The following dependencies could not complete:
install-external+yoda+1.8.0-49d36f
* The action "install-external+fasthadd+2.3-49d36f" was not completed successfully because The following dependencies could not complete:


You can see the results of the tests here:
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-49d36f/6167/summary.html

@smuzaffar
Copy link
Contributor

@mrodozov , why external glew? what was wrong with root internal glew? Have they dropped it from root?

@smuzaffar
Copy link
Contributor

I think here we should only update the root branch/tag and every thing else should remain same (unless root build system has changed and needs external glew). If that does not work then report thr issue to root team instead of hacking

@oshadura
Copy link

oshadura commented May 8, 2020

@smuzaffar glew is external package and we moved it to builtins (it will allow people to build against newer versions of glew and update easier glew inside ROOT) as it is done with lz4/zstd/xxhash and etc. If you want to use Glew provided by ROOT just select CMake option -Dbuiltin_glew=ON

@smuzaffar
Copy link
Contributor

humm strange as we were already building with -Dbuiltin_glew=ON ( https://github.com/cms-sw/cmsdist/pull/5800/files#diff-81217efc115a8de6b75eeef2a6324e47L82 ) .

@oshadura
Copy link

oshadura commented May 8, 2020

Do you have opengl=ON? Glew depends on opengl...

Can you please try to build again with builtin_glew=ON after my changes in master?

Basically now you need to treat glew the same way you treat lz4 or xxhash, so I believe approach of Mircho could be correct.

@mrodozov
Copy link
Contributor Author

mrodozov commented May 8, 2020

I decided to get glew as external after ROOT changed their config and did not distribute it any more. I can retry with using the builtin_glew=ON but that's how I started - ROOT is using it, but not distribute it. I don't know if thats still the case with the latest ROOT changes

@smuzaffar
Copy link
Contributor

Normally we add an external if it is also used by other package. If glew is only used by root so there is no point building and distributing it as external.

@mrodozov
Copy link
Contributor Author

mrodozov commented May 8, 2020

CMSSW are also using glew as rootglew I also had to change that, in Fireworks/Core . I decided to get it as external after ROOT stopped distributing it. I'll retry with the latst config

@smuzaffar
Copy link
Contributor

@mrodozov , rootglew is the ROOT library. So it should stay as it is

@smuzaffar
Copy link
Contributor

just remove all your changes and only update root branch/tag

@oshadura
Copy link

oshadura commented May 8, 2020

@smuzaffar @mrodozov So if you are using glew only inside ROOT you need to have -Dbuiltin_glew=ON, but if you are relying on glew functionality outside of ROOT, you probably should have it build as external dependency.

I am not sure what is rootglew, we don't have such ROOT library. If it is libGLEW.so then it is simple Glew library that was shipped in the middle of of other ROOT libraries, very old and not updated and now since we move to mechanism of builtins, it is not distributed anymore. I am trying to understand if builtins (xz, lz4,zstd, glew and etc.) actually should be distributed... (cc: @Axel-Naumann)

@smuzaffar
Copy link
Contributor

@oshadura , are you planning to drop GLEW from root? if yes then sure we need to add it as cms external.

@smuzaffar
Copy link
Contributor

only usage of glew in cmssw is https://github.com/cms-sw/cmssw/search?q=glew&unscoped_q=glew . So I think if root does not need glew then may be we also do not need it in cmssw.

@mrodozov
Copy link
Contributor Author

mrodozov commented May 8, 2020

just remove all your changes and only update root branch/tag

Sure, but what I was saying is ROOT kept having it as builtin, but didn't distribute it in the ROOT/include and ROOT/lib anymore, thats when I had to add it (as external, since it wasn't present in the ROOT installation anymore)
I'm building ROOT with the builtin option ON, if the libs and headers are installed of course I'll keep it as it was.

@smuzaffar
Copy link
Contributor

I understand that @mrodozov . I would suggest to first check with root team to make sure that the change is on purpose. It could that due to a bug they might have changed something and then we have to patch it to make it work. If root team statement is that they do not want to make GLEW visible then good enough and we need to tell firework teams to update cmmsw.

@cmsbuild
Copy link
Contributor

Pull request #5800 was updated.

%define tag 384e06fed3d7305d8d438c34399d6e6e327256de
%define branch cms/master/73ae672
%define tag a2847019732b1b02e0cb1e437b4b9f4c913ddee1
%define branch cms/master/e2c9e16
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please open a new PR with only this change. All of other changes are needed now ... right?

Copy link
Contributor Author

@mrodozov mrodozov May 11, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll keep the branch if ROOT decide to ditch glew, apart from that yes no need to keep this one open. This is not merged yet so it also needs it root-project/root#5583

@mrodozov
Copy link
Contributor Author

Closed in favor of #5813

@mrodozov mrodozov closed this May 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants