I see that we had a local version of libelf as far back as when we started using scons in 2004, where we referred to it's SConscript in m5/libelf/SConscript (not src/m5 or util/m5, just m5), although that directory and all its history seems to have been dropped during one of the times we switched version control systems I'd guess, probably from bitkeeper to mercurial. I think having a local version is a very old historical decision, and only someone who was contemporary could tell you about it. My guess is to ensure compatibility, probably particular when the gem5 binary gets shipped off to another system to actually run.
Gabe On Tue, Aug 11, 2020 at 6:49 PM Gabe Black <[email protected]> wrote: > I'm pretty sure it's been that way "forever", where forever is defined as > as far back as I can remember. Looking at the history, I see that Nate > replaced a GNU libelf with "autoconf nastiness" (I can imagine), and > replaced it with a freeBSD version in 2007, so it's been that way at least > as long as that. Maybe it was uncommon in package managers, annoying to > install, etc? Maybe there were interface differences? I'll see if I can > find record of the older GNU version and see if there are any more commit > message clues there. I don't *think* we've done anything to customize > libelf, but maybe we have or used to. > > As far as the linker, the short answer is I don't know how it chooses, but > I think I've run into that before with some of the fast model stuff. I > don't remember all the specifics, but my comment in > src/arch/arm/fastmodel/SConscript says: > > # We need to use the static libraries as files so that the linker > # doesn't use the shared versions of them instead. We need to use > # the shared libraries by name so that the linker will apply RPATH > # and be able to find them at run time. If a shared libary includes > # a path, the dynamic linker will apparently ignore RPATH when > looking > # for it. > > Or in other words, .../build/ARM/libfoo.a and -lfoo for libfoo.so so we > can embed what relative path to find that library at in the binary. > > Gabe > > On Tue, Aug 11, 2020 at 6:10 PM Jason Lowe-Power via gem5-dev < > [email protected]> wrote: > >> Hi all, >> >> Does anyone remember why we have our own libelf in ext? Gabe, you were >> recently changing the elf loader, do you have any idea? >> >> I'm having a huge frustration trying to get gem5 to work with openSUSE. >> For some reason, gem5 is picking up the libelf.so file in /usr/lib instead >> of the libelf.a in build/libelf/. This is causing a segfault in >> ElfObject::determineOpSys() because the Elf_Data returned by libelf.so is >> in a different format than what our "special" libelf expects. If I force >> gem5 to use libelf.a (by manually linking) things work fine. I've also >> double checked in gdb that all of the elf calls are going to the libelf.so >> in /usr. >> >> I guess I have two questions: >> 1. Why do we ship libelf and not use the generic one? >> 2. Why would the linker prefer the shared lib in /lib instead of the >> static lib in build/libelf? Does anyone know how to convince the linker to >> grab the right one? >> >> Thanks, >> Jason >> _______________________________________________ >> gem5-dev mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > >
_______________________________________________ gem5-dev mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
