I was hoping we could leave the lto in the .cc->.o but take it out of the partial links, and that that would fix the problem. If you have a docker image I can try this all out on, that would be helpful. If I can get ahold of that somehow, I can try to figure out how to fix this on Monday. I'd speculate what's happening is that little inline functions, etc., which I think are called "common" symbols are showing up more than once. Normally that's ok and the linker will figure that out and get rid of the extra copies, but apparently here it isn't doing that. There's a scons variable which you can use to disable lto in the fast build if you want a workaround for right now, although using gem5.fast is a bit dangerous in the first place since I think it disables asserts, etc.
Gabe On Sun, Jun 4, 2017 at 2:11 PM, Jason Lowe-Power <[email protected]> wrote: > I tried passing -no-lto with ['-r', '-nostdlib'] on line SConstruct:688. > However, that caused the error/warning: > "/usr/bin/ld: build/X86/dev/io_device.fo: plugin needed to handle lto > object" for every lib.fo.partial. I guess the -lto option during .cc->.o > puts some data in the .o. Then, when partially linking with -r gcc gets > confused? > > Should I filter out the -lto=8 from all of the .cc->.o? I could have > mis-understood how to do this. > > Jason > > On Sun, Jun 4, 2017 at 4:08 PM Gabe Black <[email protected]> wrote: > >> Did you try filtering out the lto option from the partial link steps like >> I suggested? Look at how I do that for -shared as an example. >> >> Gabe >> >> On May 24, 2017 2:00 PM, "Jason Lowe-Power" <[email protected]> wrote: >> >>> Hi everyone, >>> >>> So I've been able to reproduce the problem. I would bet it's due to the >>> new partial linking code (https://gem5.googlesource.com/public/gem5/+/ >>> 6bdd897f04f4efdf90d0761c6d31d3f960f4eacf). I'm not sure what the >>> solution is, yet, or if I'll have time to look at it in the next few day. >>> Gabe might have an idea, though, if that is the problem. >>> >>> Here's a matrix of what compilers are working and which aren't (gcc-4.8 >>> is working, too, though not tested on travis). >>> https://travis-ci.org/powerjg/gem5-ci-test/builds/235779432 >>> >>> Jason >>> >>> On Tue, May 23, 2017 at 4:33 PM Moussa, Ayman < >>> [email protected]> wrote: >>> >>>> How can I check which compiler scons uses? These are the compilers on >>>> my system >>>> >>>> >>>> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 >>>> g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 >>>> Linux 4.4.0-75-generic #96-Ubuntu SMP >>>> >>>> ------------------------------ >>>> *From:* gem5-users <[email protected]> on behalf of Jason >>>> Lowe-Power <[email protected]> >>>> *Sent:* 23 May 2017 22:27:34 >>>> >>>> *To:* gem5 users mailing list >>>> *Subject:* Re: [gem5-users] Link error building gem5.fast >>>> >>>> I just tried again and still cannot reproduce the error. What compiler >>>> are you using? >>>> >>>> Jason >>>> >>>> On Tue, May 23, 2017 at 3:41 PM Moussa, Ayman < >>>> [email protected]> wrote: >>>> >>>>> Hey >>>>> >>>>> >>>>> I've encountered this exact problem with x86 and it only seems to be >>>>> for gem5.fast (gem5.opt works fine). I still have problems with a clean >>>>> build as Jason suggested so I reverted back to some random commit on the >>>>> gem5 repository and it works but it's not what I was looking for though. >>>>> Hope this gets fixed soon. >>>>> >>>>> >>>>> >>>>> ------------------------------ >>>>> *From:* gem5-users <[email protected]> on behalf of Alec >>>>> Roelke <[email protected]> >>>>> *Sent:* 23 May 2017 21:14:10 >>>>> *To:* gem5 users mailing list >>>>> *Subject:* [gem5-users] Link error building gem5.fast >>>>> >>>>> Hi Everyone, >>>>> >>>>> When I try to build gem5.fast using any ISA, I get a lot of multiple >>>>> definition errors during the final linking stage. For example, with x86: >>>>> >>>>> [ LINK] -> X86/gem5.fast.unstripped >>>>> build/X86/arch/x86/bios/lib.fo.partial: In function >>>>> `Drainable::drainResume()': >>>>> (.text+0x5b00): multiple definition of `Drainable::drainResume()' >>>>> build/X86/dev/x86/lib.fo.partial:(.text+0x0): first defined here >>>>> >>>>> There are way too many of these to list them all, but they're all >>>>> multiple definitions of symbols. Has anyone else encountered this? >>>>> >>>>> Thanks, >>>>> Alec Roelke >>>>> _______________________________________________ >>>>> gem5-users mailing list >>>>> [email protected] >>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> >>>> _______________________________________________ >>>> gem5-users mailing list >>>> [email protected] >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >>>
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
