Re: change in -fpic handling?

Hi Florian, >> * Weak symbols are not generated by the annobin plugin >>    when compiling with -ffunction-sections. >> >>    There was no point really.  Linker garbage collection will not >>    discard sections if they have annobin notes against them, since >>    the code sec

Re: change in -fpic handling?

Florian Weimer writes: >> I just tried a koji scratch build of libxsmm, where the problem showed >> up; it now builds, but the test failed with a numerical error which I >> haven't seen before and I probably can't debug on any reasonable >> timescale. Is that plausibly due to the binutils change

Re: change in -fpic handling?

On 07/02/2018 01:31 PM, Dave Love wrote: Florian Weimer writes: Can this still cause symbol clashes if two linkonce sections (of different names) contain functions which receive annobin annotations? Anyway, looks like these annobin changes exposed a binutils bug:

Re: change in -fpic handling?

Florian Weimer writes: > Can this still cause symbol clashes if two linkonce sections (of > different names) contain functions which receive annobin annotations? > > Anyway, looks like these annobin changes exposed a binutils bug: > > > > (W

Re: change in -fpic handling?

On 06/28/2018 02:39 PM, Nick Clifton wrote: Hi Dave, Hi Florian, Right - there is a new annobin rpm available - annobin-8.0-1.el8 - which has these changes: * Weak symbols are not generated by the annobin plugin when compiling with -ffunction-sections. There was no poi

Re: change in -fpic handling?

Hi Dave, Hi Florian, Right - there is a new annobin rpm available - annobin-8.0-1.el8 - which has these changes: * Weak symbols are not generated by the annobin plugin when compiling with -ffunction-sections. There was no point really. Linker garbage collection will not

Re: change in -fpic handling?

On 06/27/2018 06:50 PM, Florian Weimer wrote: On 06/27/2018 06:45 PM, Nick Clifton wrote: Hi Florian, Superficially, this will work. But I'm a bit worried that the .weak still makes the symbol global, so that it ends up in the dynamic symbol table. Hmm, if I make the symbols hidden rather

Re: change in -fpic handling?

On 06/27/2018 06:45 PM, Nick Clifton wrote: Hi Florian, Superficially, this will work. But I'm a bit worried that the .weak still makes the symbol global, so that it ends up in the dynamic symbol table. Hmm, if I make the symbols hidden rather than weak, will that work ? The problem was t

Re: change in -fpic handling?

Hi Florian, > Superficially, this will work. > > But I'm a bit worried that the .weak still makes the symbol global, so that > it ends up in the dynamic symbol table. Hmm, if I make the symbols hidden rather than weak, will that work ? I need to investigate... Cheers Nick _

Re: change in -fpic handling?

On 06/27/2018 06:25 PM, Nick Clifton wrote: OK - so if I change annobin so that it creates its own function start symbol, eg libxsmm_crc32_u64_start and then it references this symbol in the .weak directive, (instead of libxsmm_crc32_u64), then everything should be OK right ? Since the new symbol

Re: change in -fpic handling?

On Wed, Jun 27, 2018 at 05:25:17PM +0100, Nick Clifton wrote: > > Nick, this looks like an annobin bug.  This is really, really problematic > > from an ABI perspective. > > OK - so if I change annobin so that it creates its own function start symbol, > eg libxsmm_crc32_u64_start and then it refe

Re: change in -fpic handling?

Hi Florian, Hi Dave, >>    /usr/bin/ld: build/intel64/libxsmm_main.o: relocation R_X86_64_PC32 >> against symbol `libxsmm_crc32_u64' can not be used when making a shared >> object; recompile with -fPIC > GCC emits calls to the function using: > >     call    libxsmm_crc32_u64 > > This is

Re: change in -fpic handling?

On 06/27/2018 01:38 PM, Dave Love wrote: Florian Weimer writes: On 06/26/2018 02:53 PM, Dave Love wrote: What has changed in the last month to affect building shared libraries in rawhide? I tried to rebuild libxsmm in rawhide, after changing the spec to use python2 explicitly, and it failed

Re: change in -fpic handling?

Florian Weimer writes: > On 06/26/2018 02:53 PM, Dave Love wrote: >> What has changed in the last month to affect building shared libraries >> in rawhide? >> >> I tried to rebuild libxsmm in rawhide, after changing the spec to use >> python2 explicitly, and it failed with >> >>/usr/bin/ld: bu

Re: change in -fpic handling?

Petr Pisar writes: > On 2018-06-26, Dave Love wrote: >> What has changed in the last month to affect building shared libraries >> in rawhide? >> >> I tried to rebuild libxsmm in rawhide, after changing the spec to use >> python2 explicitly, and it failed with >> > Did you check continuous integr

Re: change in -fpic handling?

On 06/26/2018 02:53 PM, Dave Love wrote: What has changed in the last month to affect building shared libraries in rawhide? I tried to rebuild libxsmm in rawhide, after changing the spec to use python2 explicitly, and it failed with /usr/bin/ld: build/intel64/libxsmm_main.o: relocation R_X86

Re: change in -fpic handling?

On 2018-06-26, Dave Love wrote: > What has changed in the last month to affect building shared libraries > in rawhide? > > I tried to rebuild libxsmm in rawhide, after changing the spec to use > python2 explicitly, and it failed with > Did you check continuous integration results

change in -fpic handling?

What has changed in the last month to affect building shared libraries in rawhide? I tried to rebuild libxsmm in rawhide, after changing the spec to use python2 explicitly, and it failed with /usr/bin/ld: build/intel64/libxsmm_main.o: relocation R_X86_64_PC32 against symbol `libxsmm_crc32_u64'