This is a port of GNU binutils 2.37 to MSDOS/DJGPP.

The GNU binutils are utilities of use when dealing with binary files,
either object files or executables. These tools consist of the linker
(ld), the assembler (gas), and the profiler (gprof). There is also a
collection of other binary tools, including the disassembler (objdump).
These tools make use of a pair of libraries (bfd and opcodes) and a
common set of header files.

DJGPP specific changes.
=======================

- There are no DJGPP specific changes compared with the previous port.
The DJGPP specific changes enumerated below are the same than the ones
already available in the previous port.

- This port allows a maximal number of 4294967296 relocations per object
file and a maximal number of 4294967296 of lines per executable file.
The previous limits were the classical COFF limitations of 65536 for
boths.

- The support of more than 64k relocations can be disabled by defining the
DISABLE_64K_RELOC_SUPPORT environment variable to either y or Y. Any
other value is ignored and automatically enables the greather than 64k
relocations support. The same applies if the variable is not defined at
all. This is true for all applications linked with libbfd.a if and only
if they call the bfd_init function that will check for this environment
variable. If this is not done the support is always enabled. All this
means that the enabled support is always the default.

- The linker script changes, are based on the diff files taken from Andris
Pavenis' bnu219s2.zip and djcross-binutils-2.19.1-10ap.src.rpm. Both are
available at ftp.delorie.com and mirrors.
I have only made those adjustments necessaries to get those patches fit
with the current source files.

- The diffs file that contains all changes I have done is stored in the
/djgpp directory. Also in this directory is stored the small build.sh
script that I have used to adjust all configure and libtool scripts of
the package. The well known issues that must been fixed are that:
1) the gawk test for setting the CR coding to be used does not work at
all.
2) inhibit that gawk prepends a leading slash to DOS style path names.
3) a libtool function needs to be adjusted to get the install target
working.
4) the target alias is removed from the tooldir and scriptdir path to
get the programs and linker scripts installed in the canonical places
of a DJGPP installation.
That script is very simple and will only work to configure and compile
the sources in the /djgpp directory. If you want to make changes or pass
more or other options to configure, you will have to edit it or write your
own script. build.sh shall not be smart, it shall only DTRT.

- The diffs file stored in the /djgpp directory documents the DJGPP specific
changes. It has been split into three different files. diffs-bfd contains
all DJGPP specific changes to libbfd and libiberty. These changes are
shared with the DJGPP port of gdb. The diffs file contains all DJGPP
specific changes for the rest of binutils. The diffs-bugs file contain
those DJGPP specific changes to fix bugs discovered during porting of
binutils. If these changes are accepted by the binutils maintainers or
the bug is fixed in some other way then this file will be removed for the
next port release. All these files are located in the /djgpp directory.
If you want to apply them to the original sources, diffs and diffs-bfd
must be apllied first (in any order) and diffs-bugs always as last one.
The elf support has proven not to work so it no longer provided at all.

- This port provides a version of the linker that will be capable to resolve
multiple symbol definitions conflicts when using DXE3 modules. Multiple
symbol definition always occure when an application is linked with various
libraries and more than one of its provides an object file defining the
same function (symbol). E.g.: when compiling an arbitrary GNU source
package like grep with NLS enabled and using the DXE3 module versions of
the iconv library and the gettext library, a definition of the locale_charset
function (aka symbol) will appear three times. One definition (aka
function implementation) will be provided by the grep code itself via its
own code (aka libgreputils.a). The other two will be provided by the import
libraries libiconv.a and libintl.a of both DXE3 modules used. The linker
will note that the different libraries provide different implementations of
the same function and will abort operation with an error message like this:

c:/djgpp-2.04/lib/libintl.a(dxe_tmp.o):dxe_tmp.c:(.text+0x7a4): multiple definition of `locale_charset'
../lib/libgreputils.a(localcharset.o):h:/g/srcs/gnu/grep-2.18/_build.204/lib/.././../lib/localcharset.c:363: first defined here
c:/djgpp-2.04/lib/libiconv.a(dxe_tmp.o):dxe_tmp.c:(.text+0x248): multiple definition of `locale_charset'
../lib/libgreputils.a(localcharset.o):h:/g/srcs/gnu/grep-2.18/_build.204/lib/.././../lib/localcharset.c:363: first defined here
collect2.exe: error: ld returned 1 exit status

In case of multiple symbol definitions, the linker will check if one of
the definitions comes from an import library (all import libraries contain
only one single object file called either dxe_tmp.o or $$dxe$$.o).
If the symbol definition is stored in a file called dxe_tmp.o, all other
definitions will be ignored/discarded. This means that the symbol
definition of the DXE3 module has __always__ precedence over any other
symbol definition. This will guarantee that all compiled programs that
use the same DXE3 module will use at runtime the same implementation of
the required function and not a particular implementation provided by the
sources of the program being compiled. That implementation may not even
have been ported to djgpp and thus will be useless at all. There is no
linker switch to change this behaviour and to give any other function
implementation precedence over the DXE3 implementation. If more than one
import library provides a definition for the same symbol, always the first
is used and all other import library definitions are ignored. This is not
an issue because the import libraries only provide wrapper functions that
call at runtime the real functions stored in the DXE3 modules and these
wrapper functions look all the same. Without this capability, the DXE3
modules become almost useless for NLS support, because the porter of every
package that has NLS enabled would have to take care to remove all NLS
specific functions from the port code that are already provided either by
the gettext library or by the iconv library. Please note that the linker
cannot resolve any other multiple symbol definition conflict than the one
described for the DXE3 modules. Of course, if static library versions of
those NLS libraries are used, these symbol conflicts do not arise at all
and the linker creates an executable in the usual way. To be able to
compile the linker with this feature you must uncomment the line that
defines the DXE3_SUPPORT_ENABLED variable in the /djgpp/build.sh file.

- There are ports like the one of GNU gettext that provide libraries with
file names that cannot be uniquely mapped to short file names without
using numeric tails. Usualy in this case the files are renamed so they
have a valid short file name without having to use numeric tails. The
consecuence of this renaming is that a lot of Makefiles need to be
adjusted in a DJGPP/DOS specific way. To avoid this inconvenience, this
version of the linker will provide a mapping feature between the original
long file names and the DOS specific short file names. This port provides
a new file called libnames.tab located in /dev/env/DJDIR/lib. When the
linker tries to open a library with its original name and failes, it will
try to open /dev/env/DJDIR/lib/libnames.tab and load it content into a
static array/table. With the aid of this table it will try to map the
long file name to a short file name. If this mapping is succesfull it
will try to load that file instead of the original one and if this was
also succesfull it will continue working. For every other library that
cannot be loaded by its original name, the linker will search for an
alternative name in the array/table and load that library instead. Please
note that you cannot specific the location of libnames.tab. If required,
the linker will load it from the canonical location and there will be no
error message if libnames.tab cannot be found or loaded. If the linker
cannot load the library neither by its original name nor by its short
name it will abort the operation in the usual way and issue an error
message about file loading error printing the original file name.
The syntax for the entries is quite simple and the scanning/reading of
the file is not bullet-proof. This means that syntax errors will not be
detected and will produce nonsense file name translations that will very
likely make abort the linker. I do not think that this is a great
inconvenience because most of the users should never add any entry to
this file. It is the job of the port of some package that must provide
an update of libnames.tab if his port contains renamed libraries.
Syntax of libnames.tab entries:
1) The # character defines comment line that will be skipped.
The comment is the complete line and NOT only the text following the
# character!
2) Empty lines will be skipped.
3) A valid entry looks like:

On 2021-11-25 06:54, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp-announce@delorie.com] wrote:
> This is a port of GNU binutils 2.37 to MSDOS/DJGPP.

Hi, thanks for this release.

>   - The linker script changes, are based on the diff files taken from Andris
>     Pavenis' bnu219s2.zip and djcross-binutils-2.19.1-10ap.src.rpm.  Both are
>     available at ftp.delorie.com and mirrors.
>     I have only made those adjustments necessaries to get those patches fit
>     with the current source files.

Recent binutils (>= 2.35) and gcc (>= 10.1) will create .bss.* sections with
the correct attributes, so this hack is no longer necessary. Same applies to
lib/djgpp.djl in CVS. I think I mentioned this before, but maybe I forgot.

Am 25.11.2021 13:07, schrieb J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]:
> On 2021-11-25 06:54, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp-announce@delorie.com] wrote:
>> This is a port of GNU binutils 2.37 to MSDOS/DJGPP.
>
> Hi, thanks for this release.
>
>> - The linker script changes, are based on the diff files taken from Andris
>> Pavenis' bnu219s2.zip and djcross-binutils-2.19.1-10ap.src.rpm. Both are
>> available at ftp.delorie.com and mirrors.
>> I have only made those adjustments necessaries to get those patches fit
>> with the current source files.
>
> Recent binutils (>= 2.35) and gcc (>= 10.1) will create .bss.* sections with
> the correct attributes, so this hack is no longer necessary. Same applies to
> lib/djgpp.djl in CVS. I think I mentioned this before, but maybe I forgot.

Is this also true for the users of gcc 3.4.6 and gcc 2.8.N?

Regards,
Juan M. Guerrero

On 2021-11-25 17:47, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp@delorie.com] wrote:
> Am 25.11.2021 13:07, schrieb J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]:
>> On 2021-11-25 06:54, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp-announce@delorie.com] wrote:
>>> This is a port of GNU binutils 2.37 to MSDOS/DJGPP.
>>
>> Hi, thanks for this release.
>>
>>>   - The linker script changes, are based on the diff files taken from Andris
>>>     Pavenis' bnu219s2.zip and djcross-binutils-2.19.1-10ap.src.rpm.  Both are
>>>     available at ftp.delorie.com and mirrors.
>>>     I have only made those adjustments necessaries to get those patches fit
>>>     with the current source files.
>>
>> Recent binutils (>= 2.35) and gcc (>= 10.1) will create .bss.* sections with
>> the correct attributes, so this hack is no longer necessary. Same applies to
>> lib/djgpp.djl in CVS. I think I mentioned this before, but maybe I forgot.
>
>
> Is this also true for the users of gcc 3.4.6 and gcc 2.8.N?
>
> Regards,
> Juan M. Guerrero

No, only gcc 10 creates these sections with the correct attributes. It does so
by emitting a "b" flag on the .section directive, eg.:

.globl _foo
.section .bss.foo,"wb"
_foo:
.space 4

Then the assembler from binutils 2.35+ makes sure the CONTENTS / LOAD / DATA
attributes for that section are cleared.

For older gcc versions, this linker script workaround is actually incomplete:
the CONTENTS attribute will also be set on '.gnu.linkonce.b.*' sections. So
you would have to link those sections in '.data' too, but that will then waste
more space for gcc 10 users. I think it's best to just remove it.

If you want a universal solution that works for all gcc versions, then we need
to find some way of determining section attributes in binutils/bfd, based on
the section name. I believe that is how these are handled in ELF.

Am Thu, 25 Nov 2021 06:54:25 +0100
schrieb "Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp-announce@delorie.com]":

> This is a port of GNU binutils 2.37 to MSDOS/DJGPP.
[snip]

Due to the issue reported by Jamie Bainbridge in:
https://www.delorie.com/archives/browse.cgi?p=djgpp/2021/12/31/23:15:08
and another issue found by me also related to the file handling, I have
decided to delete the DJGPP port of binutils 2.37 and to replace it again
with the port of binutils 2.35.1. The zip files are those ones that have
been stored in the "deleted" directory. From a DJGPP specific point of
view I am not aware of any benefit of using binutils 2.37. When I have
some time I will check what has been broken in the DJGPP port.

The port consists of the usual four packages that have been produced using
djdev205 (CVS repository code) and can be downloaded from ftp.delorie.com
and mirrors as (time stamp 2022-01-08):

Binutils 2.35.1 binaries, info and man format documentation:
http://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu2351b.zip

Binutils 2.35.1 bfd, liberty and opcode libraries and headers:
http://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu2351a.zip

Binutils 2.35.1 dvi, html, ps and pdf format documentation:
http://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu2351d.zip

Binutils 2.35.1 source:
http://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu2351s.zip

Regards,
Juan M. Guerrero