ROOT 5 compilation with gcc 9

ROOT
1

Dear all,
I’m trying to compile root 5.34.38 (latest from the 5 series) on Fedora 30 with gcc 9.

@Axel After a few minor tweaks, most of the code compiles but cint dictionaries. I’m facing errors like:

cint/cint/lib/dll_stl/G__cpp_list.cxx: In function ‘int G__list_52_0_10(G__value*, const char*, G__param*, int)’:
cint/cint/lib/dll_stl/G__cpp_list.cxx:693:109: error: ‘std::__cxx11::list<int, std::allocator >::iterator’ {aka ‘struct std::_List_iterator’} has no member named ‘operator==’; did you mean ‘operator=’?
693 | G__letint(result7, 103, (long) ((list<int,allocator >::iterator*) G__getstructoffset())->operator==((list<int,allocator >::iterator) libp->para[0].ref));

Any suggestions?

Thanks in advance
Mathieu

ROOT Version: 5.34.38
Platform: Linux Fedora 30
Compiler: gcc version 9.1.1 20190503 (Red Hat 9.1.1-1) (GCC)

2
3

I have to stick with the ROOT 5 release, but I’ll try your suggestion. However the error appear at a first glance unrelated.

Thanks

4

We’ve had ROOT 6 for nearly five years now (May 30, 2014). And real development stopped on ROOT 5 three years ago (5.34.36 on April 5, 2016). It may be time for all these older codes to move on. I see you are being cutting edge with gcc 9, but less so with ROOT?

Maybe this is only my opinion, but it is in interesting question to ask: how long should a superseded package be supported?

5

The problem is quite simple: we are an experiment running since ~ 15 years, the code has been adapted qui often to follow the ROOT development, but at some point it was decided to freeze the ROOT version. It was felt that ROOT 6 introduced major changes with respect to ROOT 5, and that adapting our code to ROOT 6 would have required major efforts.

However, we try to provide the user the capability to access the data on their modern laptops, thus running recent Linux distributions.

@Axel I can confirm that the error persists with the head of the v5-34-00-patches branch.

6

Hi Mathieu,

but at some point it was decided to freeze the ROOT version
It was felt that […] adapting our code to ROOT 6 would have required major efforts.

As e.g. @ksmith pointed out, the ROOT team cannot update old releases eternally. I understand it’s easier for you to ask us to do work, but…

We are already working on the next major ROOT release - of which you will only really benefit if you buy into actual changes. If you want frozen software then please freeze everything. We promise not to break 5.34 :wink:

If really needed we can accept patches for v5. What should worry you even more is that we do not get a lot of these patches for ROOT 5, as can be seen from the commit history: Commits · root-project/root · GitHub One commit during the last year.

I believe most folks saw that their investment into moving to ROOT 6 massively paid off: we have much happier ROOT 6 users than our ROOT 5 users have ever been :wink: We will do our best to help you migrate to ROOT 6, we would even offer a dedicated contact person in the ROOT team if that helps. Let me know!

Cheers, Axel.

1 Like
7

Dear Axel,

I’m perfectly aware of the impossibility to maintain endless “deprecated” versions of software and I also fully acknowledge the excellent support work your are doing. My purpose was no to ask you to do the work but just to check if someone, by chance, experienced a similar problem and found the solution.

I’ll have a look into ROOT 6 to see if it causes major problem to us (and eventually get back to you), and I’ll try to fix the problem in parallel.
I already managed to get ROOT 5.34.38 work properly on recent systems up to Fedora 29 with gcc 8.3.1.

Regards,

Mathieu

1 Like
8

see/tweak cint/cint/lib/prec_stl/list

9

While reading through this I thought of another possible solution that is probably unsatisfactory, but thought I would propose it anyhow.

You could install an older version of gcc to build ROOT. This would allow you to use a recent version of Fedora and an older version of ROOT. Although it sounds like you have corrected most of the issues already.

10

Thanks a lot, very much appreciated.
I had to remove == and != operators from most STL container iterators, such as:

sh-5.0# diff -u cint/cint/lib/prec_stl/map~ cint/cint/lib/prec_stl/map
--- cint/cint/lib/prec_stl/map~	2018-03-12 15:48:57.000000000 +0100
+++ cint/cint/lib/prec_stl/map	2019-05-14 12:53:53.800845729 +0200
@@ -117,8 +117,8 @@
     iterator operator--(int a);
 #if defined (G__VISUAL) || (defined(G__GNUC_VER) && G__GNUC_VER>=3004) || defined(G__INTEL_COMPILER)
 #if !defined(G__APPLE_LIBCXX)
-    bool operator==(const iterator& x) ;
-    bool operator!=(const iterator& x) ;
+//     bool operator==(const iterator& x) ;
+//     bool operator!=(const iterator& x) ;
 #endif
 #endif
 #ifdef G__HPUX

This done, I got it compiled and running.
Thanks a lot again.

2 Likes
11

Would you mind sharing the full patch?

12

@axel How about you finally agree to admit that “Number 5 is Alive!”.

13

Hello, the patch is attached but it’s currently very ugly because of 2 reasons:

  1. I did not enclose the changes in #ifdef GNUC > … statements
  2. I completely remove the offending functions instead of looking for working alternatives. As a consequence, iterator to stl container do not work anymore in CINT, quite annoying. For compiled code it’s working fine.

I also add to pass some new options to the linker, such as -Wl,–allow-multiple-definition.
root_5.34_fc30_patches.tgz (1.4 KB)

If someone points me towards the function replacement to be used, I’m willing to try to provide a cleaner patch.

Regards,

Mathieu de Naurois

14

@Wile_E_Coyote LOL yes, only question is: alive with a blood infusion and a lung pump, or already undead? (I heard there’s still folks using Windows XP out there…)

Look, what I state is more about what we can and cannot do. I do know that reality is sometimes an evil twist of what we want :wink: But that doesn’t mean we need to find it acceptable. That’s an amazingly generic statement right there!

15

I didn’t know it was a forum about philosophy! -:wink:

16

We certainly accept PRs for TPhilosophy! :wink:

17

Thanks!

I reworked this a bit:

gcc9_stl_iterators.tar.gz (894 Bytes)

This version includes the free friend operator functions instead of the class member functions for the various stl class iterators. Actually it would be better to check which libstdc++ version is being used instead of checking which GCC version is used as a compiler, but if you just need to compile with GCC this should work fine.

18

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.