Hi Eric, Thanks for your input.
The dependency is indeed generating some additional issues in the type of environments you describe, and Scientific Linux does seem to be a bit behind. Luckily, it should not involve more than a configure, make and make install to get it up and running. The big question is: what portion of the users does it affect (I would think most people could get away with installing the package), and are the benefits of protobuf large enough to warrant the additional burden? Independent of the answer to this question, we need a path forward to support input/output of memory traces and execution traces. The protobuf solution seems to be much better than any other option in solving this problem, in many aspects, e.g. portability, size, speed, effort. What do you suggest instead? Kind regards, Andreas On 10/12/2012 11:58, "Erik Tomusk" <[email protected]> wrote: >As one of the proverbial users whose experience is under discussion, >maybe I can butt in. > >I think it's important to realize that not everyone uses self-managed >machines with root access. I, for one, don't have root or access to a >package manager on my regular work machine (Scientific Linux 6). SL6 >seems to lag RHEL with package support, so as far as I can tell, >protobuf (and even tcmalloc) are not installed and not even available >(http://ftp.scientificlinux.org/linux/scientific/6rolling/x86_64/os/Packag >es/) > >If I want these libraries, I need to build them and any dependencies >locally from tarballs or convince the admins to do it. If the admins are >convinced and manually build the libs (unlikely), they then need to >schedule reboots for all the machines in the school. Fun fun. > >I could, of course, switch to a self-managed desktop machine, except >that I need to regularly run lots of things on our server farm. This is >where it gets really interesting. Given that the farm admins have a >responsibility to keep the farm running for all the various groups >buying compute resources, there's no way they're going to manually build >libraries not officially supported by the distro and then support those >libraries for the rest of time (I already tried to convince them on >libperftools--no dice). Again I need to build the libraries locally and >then make sure that everything works across a finicky server farm, all >it's various nodes and whatnot. > >Since I've already invested so much time into using gem5, if another >dependency comes on board, I'll just have to make it work (or not >upgrade). I doubt a newbie would go through all this trouble, though. > >-Erik > > >On 09/12/12 16:09, Ali Saidi wrote: >> On Dec 9, 2012, at 8:53 AM, Nilay Vaish wrote: >> >>> On Sun, 9 Dec 2012, Andreas Hansson wrote: >>> >>>> May I ask why you see this as a problem? Any Unix/Linux/OSx system >>>>from the last 5+ years has these dependencies as packages (and I bet >>>>they work smoother than e.g. swig :-) >>>> >>> I doubt that this statement is true. I am using RHEL 6 and it does not >>>have protoc installed. I am guessing that would mean people who use >>>Fedora will not have it installed either. Ubuntu (12.10) has it. I >>>don't know about Mint or other distributions. >> As far as package availability protobufs is available since Fedora 16 >>as well as EL6. It's also available in all currently supported Ubuntu >>versions as well as mint and debian and just about everything else: >>http://pkgs.org/search/?keyword=protobuf >> >> So I think package availability is a separate concern from user >>experience. It's absolutely true that there would be another dependency, >>the question in my mind is that dependency a larger burden than we >>currently expect from the user and are the benefits of the library worth >>it? I think this is the best possible path toward being able to output >>memory traces, which we do seem to get a fair number of requests for on >>the mailing list. >> >>> This may not affect ARM, but one of the reasons why I am involved with >>>gem5 is that I would like people in architecture to be using the >>>simulator that I have contributed to. >> I think ARM is completely committed making gem5 successful in the >>broader architecture community, as evidenced by the large number of >>change sets with committers from ARM. >> >> Ali >> >> >> _______________________________________________ >> gem5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/gem5-dev >> > >-- >The University of Edinburgh is a charitable body, registered in >Scotland, with registration number SC005336. > >_______________________________________________ >gem5-dev mailing list >[email protected] >http://m5sim.org/mailman/listinfo/gem5-dev > -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
