Project

General

Profile

Bug #1028

Bug #1026: Installation issue - DataBaseAPI.cc and read/write

Incorrect calling of base functions fails to compile in gcc 4.8

Added by Rogers, Chris over 9 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Detector Integration
Target version:
Start date:
21 June 2012
Due date:
% Done:

100%

Estimated time:
Workflow:
New Issue

Description

Get an error message like

The error is

g++ -o src/common_cpp/JsonCppProcessors/HitProcessor.os -c -Wall -Dlong32='int' "-Dlong64='long long'" -O3 -m64 -pthread -rdynamic -fPIC -Ithird_party/install/include -Ithird_party/install/include/python2.7 -Ithird_party/install/include/root -Isrc/legacy -Isrc/common_cpp -Ithird_party/build/root_v5.30.03/include -Ithird_party/build/geant4.9.2.p04/include -I. src/common_cpp/JsonCppProcessors/HitProcessor.cc
In file included from src/common_cpp/JsonCppProcessors/HitProcessor.cc:17:0:
./src/common_cpp/JsonCppProcessors/HitProcessor.hh: In instantiation of 'void MAUS::HitProcessor<ChannelId>::RegisterBranches() [with ChannelId = MAUS::SciFiChannelId]':
src/common_cpp/JsonCppProcessors/HitProcessor.cc:28:5:   required from here
./src/common_cpp/JsonCppProcessors/HitProcessor.hh:54:5: error: 'RegisterValueBranch' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
./src/common_cpp/JsonCppProcessors/HitProcessor.hh:54:5: note: declarations in dependent base 'MAUS::ObjectProcessor<MAUS::Hit<MAUS::SciFiChannelId> >' are not found by unqualified lookup
./src/common_cpp/JsonCppProcessors/HitProcessor.hh:54:5: note: use 'this->RegisterValueBranch' instead

Files

test2.txt (141 KB) test2.txt Pradhan, Neetish, 21 June 2012 17:43

Related issues

Related to MAUS - Bug #1022: python style test failing if not in MAUS_ROOT_DIRClosedRogers, Chris14 June 2012

Actions
#1

Updated by Rogers, Chris over 9 years ago

  • Category set to Detector Integration
  • Assignee set to Rogers, Chris
  • Target version set to Future MAUS release

Ah, I meant gcc4.7.1

Okay, patch is:

=== modified file 'src/common_cpp/JsonCppProcessors/HitProcessor.cc'
--- src/common_cpp/JsonCppProcessors/HitProcessor.cc    2012-03-14 08:26:19 +0000
+++ src/common_cpp/JsonCppProcessors/HitProcessor.cc    2012-06-21 11:09:41 +0000
@@ -25,19 +25,19 @@
 template <>
 HitProcessor<SciFiChannelId>::HitProcessor()
     : _channel_id_proc(new SciFiChannelIdProcessor()) {
-    RegisterBranches();
+    this->RegisterBranches();
 }

 template <>
 HitProcessor<TOFChannelId>::HitProcessor()
     : _channel_id_proc(new TOFChannelIdProcessor()) {
-    RegisterBranches();
+    this->RegisterBranches();
 }

 template <>
 HitProcessor<SpecialVirtualChannelId>::HitProcessor()
     : _channel_id_proc(new SpecialVirtualChannelIdProcessor()) {
-    RegisterBranches();
+    this->RegisterBranches();
 }
 }
=== modified file 'src/common_cpp/JsonCppProcessors/HitProcessor.hh'
--- src/common_cpp/JsonCppProcessors/HitProcessor.hh    2012-03-14 08:46:38 +0000
+++ src/common_cpp/JsonCppProcessors/HitProcessor.hh    2012-06-21 11:10:19 +0000
@@ -51,31 +51,31 @@

 template <class ChannelId>
 void HitProcessor<ChannelId>::RegisterBranches() {
-    RegisterValueBranch("track_id", &_int_proc,
+    this->RegisterValueBranch("track_id", &_int_proc,
                         &Hit<ChannelId>::GetTrackId,
                         &Hit<ChannelId>::SetTrackId, true);
-    RegisterValueBranch("particle_id", &_int_proc,
+    this->RegisterValueBranch("particle_id", &_int_proc,
                         &Hit<ChannelId>::GetParticleId,
                         &Hit<ChannelId>::SetParticleId, true);
-    RegisterValueBranch("energy", &_double_proc,
+    this->RegisterValueBranch("energy", &_double_proc,
                         &Hit<ChannelId>::GetEnergy,
                         &Hit<ChannelId>::SetEnergy, true);
-    RegisterValueBranch("charge", &_double_proc,
+    this->RegisterValueBranch("charge", &_double_proc,
                         &Hit<ChannelId>::GetCharge,
                         &Hit<ChannelId>::SetCharge, true);
-    RegisterValueBranch("time", &_double_proc,
+    this->RegisterValueBranch("time", &_double_proc,
                         &Hit<ChannelId>::GetTime,
                         &Hit<ChannelId>::SetTime, true);
-    RegisterValueBranch("energy_deposited", &_double_proc,
+    this->RegisterValueBranch("energy_deposited", &_double_proc,
                         &Hit<ChannelId>::GetEnergyDeposited,
                         &Hit<ChannelId>::SetEnergyDeposited, true);
-    RegisterValueBranch("position", &_three_vec_proc,
+    this->RegisterValueBranch("position", &_three_vec_proc,
                         &Hit<ChannelId>::GetPosition,
                         &Hit<ChannelId>::SetPosition, true);
-    RegisterValueBranch("momentum", &_three_vec_proc,
+    this->RegisterValueBranch("momentum", &_three_vec_proc,
                         &Hit<ChannelId>::GetMomentum,
                         &Hit<ChannelId>::SetMomentum, true);
-    RegisterPointerBranch("channel_id", _channel_id_proc,
+    this->RegisterPointerBranch("channel_id", _channel_id_proc,
                         &Hit<ChannelId>::GetChannelId,
                         &Hit<ChannelId>::SetChannelId, true);
 }

Checked now the whole compile in gcc4.7.1 and it looks okay. Now running tests.

#2

Updated by Rogers, Chris over 9 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

Looks okay...

#3

Updated by Pradhan, Neetish over 9 years ago

Thanks, the patch worked and it compiled. When running the tests, there seemed to be one error. But it could be because the default python on this system is 3.2. Attaching test output, just in case.
(p.s. running analyze_data_offline.py on a data file right now, seems to be going fine so far.)

#4

Updated by Rogers, Chris over 9 years ago

Okay, you can ignore that one - it is a non-critical test fail fixed in the trunk.

If you are curious - we have an automated tool 'pylint' to do static code analysis on python code (the closest thing to a compiler for python). For some reason this was failing to import modules when run from a directory that was not the MAUS_ROOT_DIR. So now I force the style tests into the MAUS_ROOT_DIR before doing the style check.

Not sure why it is failing for you though. Python version shouldn't matter, as we install our own python 2.7.2 as part of the build process. Shrug. If it turns up again I will dig. The issue is #1022.

#5

Updated by Rogers, Chris about 9 years ago

  • Target version changed from Future MAUS release to MAUS-v0.3.0

Also available in: Atom PDF