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

Move to ROOT pre-6.06 (almost final) #12713

Merged
merged 4 commits into from Dec 9, 2015
Merged

Conversation

davidlt
Copy link
Contributor

@davidlt davidlt commented Dec 8, 2015

This is needed for ROOT 6.04 and 6.06 (this is what we have it CMSSW_8_0_ROOT64_X branch). This must go together with cms-sw/cmsdist#2023

David Abdurachmanov added 4 commits December 8, 2015 17:24
Chekcsum changed for `edm::StreamedProduct` class. Modify for ROOT
6.04.00.

Signed-off-by: David Abdurachmanov <David.Abdurachmanov@cern.ch>
The following always are unused rules and always fails `genreflex`.
Remove them as not needed.

Signed-off-by: David Abdurachmanov <David.Abdurachmanov@cern.ch>
Resolve the following run-time warnings/errors on ROOT 6.04.00:

    Warning in <TInterpreter::ReadRootmapFile>: class pair<const int,int> found in libCore.so is already in libDataFormatsStdDictionaries.so
    Warning in <TInterpreter::ReadRootmapFile>: class pair<const std::string,int> found in libCore.so is already in libDataFormatsStdDictionaries.so
    Warning in <TInterpreter::ReadRootmapFile>: class pair<const string,int> found in libCore.so is already in libDataFormatsStdDictionaries.so
    Warning in <TInterpreter::ReadRootmapFile>: class pair<double,double> found in libCore.so is already in libDataFormatsStdDictionaries.so
    Warning in <TInterpreter::ReadRootmapFile>: class pair<float,float> found in libCore.so is already in libDataFormatsStdDictionaries.so
    Warning in <TInterpreter::ReadRootmapFile>: class pair<int,double> found in libCore.so is already in libDataFormatsStdDictionaries.so
    Warning in <TInterpreter::ReadRootmapFile>: class pair<int,int> found in libCore.so is already in libDataFormatsStdDictionaries.so
    Warning in <TInterpreter::ReadRootmapFile>: class pair<std::string,int> found in libCore.so is already in libDataFormatsStdDictionaries.so
    Warning in <TInterpreter::ReadRootmapFile>: class pair<string,double> found in libCore.so is already in libDataFormatsStdDictionaries.so
    Warning in <TInterpreter::ReadRootmapFile>: class pair<string,float> found in libCore.so is already in libDataFormatsStdDictionaries.so
    Warning in <TInterpreter::ReadRootmapFile>: class pair<string,int> found in libCore.so is already in libDataFormatsStdDictionaries.so

There types are already defined in `libCore.so`. ROOT 6 built with
configure/Makfile does not generate `libCore.rootmap`, but it does
once built with CMake.
ROOT commit (8a44438d5707dd96eeab5fbf9a928378f92f07ce) renamed
`ROOT::TSchemaHelper` to `ROOT::Internal::TSchemaHelper`.

Christopher Jones checked the package history and it looks like
`TSchemaHelper` was just a victim of the original pattern being way to
inclusive. It also seems not to be used by CMSSW.

Signed-off-by: David Abdurachmanov <David.Abdurachmanov@cern.ch>
@cmsbuild
Copy link
Contributor

cmsbuild commented Dec 8, 2015

A new Pull Request was created by @davidlt for CMSSW_8_0_X.

It involves the following packages:

DataFormats/PatCandidates
DataFormats/Provenance
DataFormats/StdDictionaries
DataFormats/Streamer

@smuzaffar, @Dr15Jones, @cvuosalo, @monttj, @cmsbuild, @slava77, @vadler, @davidlange6 can you please review it and eventually sign? Thanks.
@gpetruc, @wddgit, @wmtan this is something you requested to watch as well.
@slava77, @Degano, @smuzaffar you are the release manager for this.

Following commands in first line of a comment are recognized

  • +1|approve[d]|sign[ed]: L1/L2's to approve it
  • -1|reject[ed]: L1/L2's to reject it
  • assign <category>[,<category>[,...]]: L1/L2's to request signatures from other categories
  • unassign <category>[,<category>[,...]]: L1/L2's to remove signatures from other categories
  • hold: L1/all L2's/release manager to mark it as on hold
  • unhold: L1/user who put this PR on hold
  • merge: L1/release managers to merge this request
  • [@cmsbuild,] please test: L1/L2 and selected users to start jenkins tests
  • [@cmsbuild,] please test with cms-sw/cmsdist#<PR>: L1/L2 and selected users to start jenkins tests using externals from cmsdist

@Dr15Jones
Copy link
Contributor

+1

@smuzaffar
Copy link
Contributor

please test with cms-sw/cmsdist#2023

@cmsbuild
Copy link
Contributor

cmsbuild commented Dec 8, 2015

@cmsbuild
Copy link
Contributor

cmsbuild commented Dec 9, 2015

-1
Tested at: 27ceb93
I found an error when building:

>> Building edm plugin tmp/slc6_amd64_gcc493/src/CalibMuon/CSCCalibration/test/CSCChipSpeedCorrectionPopConAnalyzer/libCSCChipSpeedCorrectionPopConAnalyzer.so
Leaving library rule at src/CalibMuon/CSCCalibration/test
@@@@ Running edmWriteConfigs for RecoParticleFlowPFClusterShapeProducerPlugins
Leaving library rule at src/CalibMuon/CSCCalibration/test
>> Building edm plugin tmp/slc6_amd64_gcc493/src/RecoParticleFlow/Configuration/test/BlockAnalyzer/libBlockAnalyzer.so
error: edmWriteConfigs caught an exception while loading a plugin library.
The executable will return success (0) so scram will continue,
but no cfi files will be written.
An exception of category 'PluginLibraryLoadError' occurred.
Exception Message:
unable to load /build/cmsbuild/jenkins-workarea/workspace/cmsdist-cmssw-test-pr/CMSSW_8_0_X_2015-12-07-1100/tmp/slc6_amd64_gcc493/src/RecoParticleFlow/PFClusterShapeProducer/plugins/RecoParticleFlowPFClusterShapeProducerPlugins/libRecoParticleFlowPFClusterShapeProducerPlugins.so because /afs/cern.ch/cms/sw/ReleaseCandidates/vol0/slc6_amd64_gcc493/cms/cmssw/CMSSW_8_0_X_2015-12-06-2300/lib/slc6_amd64_gcc493/libDataFormatsParticleFlowReco.so: undefined symbol: _ZN4ROOT14DefineBehaviorEPvS0_


you can see the results of the tests here:
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-12713/8/summary.html

The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic:
ec5722e
9a0765e
798f2ac
5c9d0a8
1a5e3dd
215912e
239b1de
ebeb0b1
20964d6
f8ef215
You can see more details here:
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-12713/8/git-log-recent-commits
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-12713/8/git-merge-result

@davidlt
Copy link
Contributor Author

davidlt commented Dec 9, 2015

I would advice building non-incremental build with this if you want to test.

@davidlange6
Copy link
Contributor

should we just start an IB?

On Dec 9, 2015, at 8:11 AM, davidlt notifications@github.com wrote:

I would advice building non-incremental build with this if you want to test.


Reply to this email directly or view it on GitHub.

@davidlt
Copy link
Contributor Author

davidlt commented Dec 9, 2015

I looked at a diff between CMSSW_8_0_X and CMSSW_8_0_ROOT64_X branches (which is small) and all the pieces seems to be here and it's the same ROOT that's running in DEVEL IBs, which works fine. Thus I would prefer a local test where you build cmssw-tool-conf, create a your custom CMSSW and build that as RPM (a clean build).

@smuzaffar
Copy link
Contributor

lets get this in IB

@smuzaffar
Copy link
Contributor

merge

cmsbuild added a commit that referenced this pull request Dec 9, 2015
Move to ROOT pre-6.06 (almost final)
@cmsbuild cmsbuild merged commit 748bf81 into CMSSW_8_0_X Dec 9, 2015
@smuzaffar smuzaffar deleted the move-to-root-pre-6.06 branch October 19, 2016 07:39
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.

None yet

5 participants