binutils-2.39

[Xi Ruoyao]

New minor version.

[Xi Ruoyao]

This release contains numerous bug fixes, and also the following new features:

• The ELF linker will now generate a warning message if the stack is made executable. Similarly it will warn if the output binary contains a segment with all three of the read, write and execute permission bits set. These warnings are intended to help developers identify programs which might be vulnerable to attack via these executable memory regions.

The warnings are enabled by default but can be disabled via a command line option. It is also possible to build a linker with the warnings disabled, should that be necessary.

• The ELF linker now supports a --package-metadata option that allows embedding a JSON payload in accordance to the Package Metadata specification.

• In linker scripts it is now possible to use TYPE=<type> in an output section description to set the section type value.

• The objdump program now supports coloured/colored syntax highlighting of its disassembler output for some architectures. (Currently: AVR, RiscV, s390, x86, x86_64).

• The nm program now supports a --no-weak/-W option to make it ignore weak symbols.

• The readelf and objdump programs now support a -wE option to prevent them from attempting to access debuginfod servers when following links.

• The objcopy program's --weaken, --weaken-symbol, and --weaken-symbols options now works with unique symbols as well.

This release also added -z pack-relative-relocs for ld.bfd, which will be used by Glibc-2.36 (and maybe other packages) by default if the linker supports it. For some reason it's not mentioned in the release note.

[Bruce Dubbs]

I am doing an initial review of this package and not that in gcc-pass2 we are doing

sed '6009s/$add_dir' -i ltmain.sh

Looking at the diff, Xi put that in last February because binutils uses a 2009 version of libtoool. Looking at binutils-2.39/libtool.m4, it still shows a copyright of 2009 so I will leave it in the book for now.

My question if whether the issue has been reported upstream?

[Xi Ruoyao]

Replying to Bruce Dubbs:

I am doing an initial review of this package and not that in gcc-pass2 we are doing

sed '6009s/$add_dir' -i ltmain.sh

Looking at the diff, Xi put that in last February because binutils uses a 2009 version of libtoool. Looking at binutils-2.39/libtool.m4, it still shows a copyright of 2009 so I will leave it in the book for now.

My question if whether the issue has been reported upstream?

​https://sourceware.org/bugzilla/show_bug.cgi?id=28905

No response yet.

And libtool guys insist we are doing things wrong and I can't really parse out what should we do from the response, maybe my English is too bad:

​https://lists.gnu.org/archive/html/libtool/2022-02/msg00034.html

[DJ Lucas]

Hey, I think I can actually help here. :-) The dev effectively suggested adding 'lt_cv_sys_lib_dlsearch_path_spec="/usr/lib"' to the configure command line (or probably to export it with the multiple configure scripts in the toolchain packages - well, what he really said was to create a global config.site with this in it, but that's overkill since target and host are compatible) but I don't completely understand the original problem either, so I can't say whether that fixes it or not. So probably 'export lt_cv_sys_lib_dlsearch_path_spec="/usr/lib" && ../configure...'

[Bruce Dubbs]

Fixed at commit 1b11115cd2bde70178f0b600de85f64a12cc36dc

Update to binutils-2.38.
Update to util-linux-2.38.1.
Update to Python3-3.10.6.
Update to glibc-2.36.

[Xi Ruoyao]

Replying to DJ Lucas:

Hey, I think I can actually help here. :-) The dev effectively suggested adding 'lt_cv_sys_lib_dlsearch_path_spec="/usr/lib"' to the configure command line (or probably to export it with the multiple configure scripts in the toolchain packages - well, what he really said was to create a global config.site with this in it, but that's overkill since target and host are compatible) but I don't completely understand the original problem either, so I can't say whether that fixes it or not. So probably 'export lt_cv_sys_lib_dlsearch_path_spec="/usr/lib" && ../configure...'

It does not work. /usr/lib is already in the default lt_cv_sys_lib_dlsearch_path_spec, and forcing "lt_cv_sys_lib_dlsearch_path_spec=$LFS/usr/lib" also does not work.

I really hope libtool can suffer a painful death.