Hi David,
binutils-2.31-18.fc40 didn't land in f40 as Bodhi CI gating marked it
as failed. The failures don't seem to be related to binutils package
itself. Seems like CI test is/was broken, or maybe a temporary network
issue, or something else.
It looks like rpminspect does not like two of
Hi David, Hi Florian,
Here's the bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=31179
RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects
It refers to this change in binutils 2.41:
> Can you please mention which option disables
> which error(s) explicitly in the Change?
Done.
I have added the text to the Scope section in the notes for Other Developers.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
Hi Dominik,
> Does the `--no-warn-rwx-segments` disable erroring out on both loadable
> rwx segments and tls rwx segments?
Yes.
At the time I wrote the feature I did consider having separate options for the
two tests, but it seemed like overkill, so I decided to go with just a single
The warnings mentioned in the blog were added to the 2.39 release of the GNU
Binutils, so they should potentially be present in the build logs of any
package built for f38 or later.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
You can test for problems by searching the build logs for warnings from the
linker:
"has a LOAD segment with RWX permissions"
"has a TLS segment with execute permission"
"missing .note.GNU-stack section implies executable stack"
There are also two related warning messages, although
What do people think overall? Are there other pros and cons of a color prompt?
Any better ideas or direction?
I like the idea of using tput to get the correct strings for
setting different terminal effects, so I now use:
# Success prompt:
prompt_term[0]=$(tput bold)
# Fail prompt:
Hi Guys,
If it helps I would be happy to volunteer to be a co-maintainer, especially
when it comes to assembler and linker command line options...
Cheers
Nick
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
Hi Frédéric,
I think this is indeed the right choice and probably the more relevant info
with respect the original source file. If you need some help for testing/fixing
that, please don't hesitate. I would be happy to help. I'm also on IRC
#fedora-devel.
Are you able to test using F34 rpms
Hi Frédéric,
I'm currently working on reproducibility for Fedora packages and I'm hitting an issue with lto/annobin.
35: 2af0 0 NOTYPE LOCAL HIDDEN 13
.annobin_dummyqbs_drv.so.MDkv6z.ltrans0.o
Do you have any idea what would be the best strategy to fix that?
Hi Richard,
> guestfish on x86-64 was failing for me with something that looks a lot
> like the same PLT problem. But it's not aarch64. Very easy to
> reproduce, see:
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ULGH5JYL7MHKDKTINJLOEN2QG6LOHWH7/
This
Hi Guys,
>> Yes, because the commit adding the DWARF 4 patch has also
>> turned LTO back on...
*double sigh*. Yes I was trying to fix the LTO bug at the same time,
and forgot that I had re-enabled it in my local copy of the rawhide
sources in order to investigate the problems.
That binutils
Hi Guys,
> Looks like most are simply because the default DWARF version changed to
> 4 and the test expected another version even though it didn't specify
> one.
Yes - it was a silly snafu. I set the default to 4 but the tests are expecting
3.
I have now updated the patch and a new binutils
Hi Guys,
> Looks like most are simply because the default DWARF version changed to
> 4 and the test expected another version even though it didn't specify
> one.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
Hi Guys,
> But... in 2.35 you can give the DWARF level you want.
> The problem with not supplying -g (or --gdwarf-[VERSION]) is that the
> dwarf_level is never set! And then gas will happily create an
> .debug_info section with DWARF CUs that have a version of zero (!).
Doh!
> This, defaulting
*sigh* Sorry guys. Please try using annobin-9.21.1-fc33. This should fix
the issue.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
Hi Paolo,
> I can maintain nasm if no one else wants to take it.
Please do, if that it what you want. However I think that it
might be better in the long run if we can retire nasm (and yasm
too) and instead replace them with gas.
Cheers
Nick
PS. In case there is someone reading this
Hi Florian,
>> Linking dist/build/tests-asn1-encoding/tests-asn1-encoding ...
>> /tmp/ghc8eea_0/ghc_2.o(.gnu.build.attributes..text.startup+0x18): error:
>> relocation refers to local symbol "" [11], which is defined in a discarded
>> section
>> section group signature: "(null)"
This should
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
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
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
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
Hi Zbigniew,
>>> Also, what is the relationship between
>>> https://fedoraproject.org/wiki/Changes/BINUTILS230
>>> and
>>> https://fedoraproject.org/wiki/Changes/BINUTILS231
>>
>> BINUTILS230 was the change request to bring in FSF binutils 2.30. This
>> is the version that is currently used in
Hi Zbigniew,
>> Do you foresee any significant issues with this version upgrade in the
>> mass rebuild?
No. I am currently testing the 2.31 sources on the FSF branch, but so far
everything looks good.
>> Anything in particular that maintainers and upstreams
>> should looks at?
I hope not.
Hi Carlos,
> I've added 2 questions to the Toolchain/Watermark wiki but will post them
> here for posterity:
Thanks - I'll try answering them here first, and if my answers make sense
then I will update the wiki.
> (1) What happened to SHT_GNU_ATTRIBUTES and how does it relate to what
> you
Hi H.J.
> We have 2 different proposals for program properties. Mine:
>
> https://sourceware.org/ml/gnu-gabi/2016-q4/msg00025.html
>
> has a much smaller scope. New features on upcoming Intel platforms,
> like 5-level paging, need this extension for loader decision at run-time.
> How should
Hi Tristan,
>> https://fedoraproject.org/wiki/Toolchain/Watermark#Markup_for_ELF_objects
> This will generalise attributes used by some architectures (ppc, arm), won't
> it ?
Yes. Or at least it would if implemented as currently proposed. Maybe a better
solution would be to only record
with this application ?' then please take a minute
to have a look at the proposal.
Thanks very much.
Cheers
Nick Clifton
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
28 matches
Mail list logo
