• ANNOUNCE: DJGPP port of GNU binutils 2.35.1 uploaded.

    From [via djgpp-announce@delorie.com]" <@21:1/5 to All on Fri Feb 26 21:49:05 2021
    This is a port of GNU binutils 2.35.1 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

    - 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
    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
    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:

    withverylongname-1.2 wvln12

    Neither the prefix nor the suffix/extension of the library name is
    part of the table entry. For the above example the complete file
    name of the library would be:
    To get a valid entry strip the prefix "lib" and the suffix ".a" from
    the library name. The same applies to the short file name of the
    library. In the example above, the library has been renamed to:
    and that is the file name of the library that the linker will use.
    The original file name is always the first name and the substitute
    file name is the second name. Both names are separated by at least
    one space or tab character.
    Another example: the gettext port provides a library that has been
    renamed to libgtxtsrc.a. Its original name was libgettextsrc.a.
    The entry for this library looks like this:

    gettextsrc gtxtsrc

    As can be seen the "lib" prefix and the ".a" suffix have been stripped
    from both library names to get the table entry. In the actual version
    of libnames.tab there are only the three entries for the three renamed
    libraries provided by the gettext port.

    - For performance reasons, BFD tries to open and cache certain amount of
    files and its contents. How many files can be opened is determinated at
    program start using the getrlimit function. Unfortunately this function
    seems to be a placebo function. At least when using djdev204 on WinXP,
    this function always returns the hard coded value of 255. This is the
    value for the number of files that can be opened (RLIMIT_NOFILE). BFD
    takes one eight of this value but at least 10 and opens so mutch files
    as required. If your FILES entry in config.sys is not large enough (at
    least around 35) then the program aborts. The corresponding BFD function
    now assumes that there are at least 16 available and will use all of them
    if required. This has the consequence that the user must set his FILES
    entry in config.sys or config.nt to 20 or 25. The value depends on how
    much file handles the OS and the DPMI server has already consumed for its
    on needs.

    - The port has been configured and compiled on WinXP SP3 and on Win98SE.
    There is no guarantee that this may be possible with any other DOS-like
    OS. Due to the use of long file names it will not be possible to
    configure and compile without LFN support. The port has been compiled
    using gcc346b and bnu234b.

    - The port has been tested by using it. I have used them only on WinXP,
    Win98SE, MS-DOS 7.0 and MS-DOS 6.22. It has worked flawlessly. I do
    not konw if this will ever be the case on FreeDOS. I have never used
    nor tested them on that environment.

    As usual, all djgpp specific files (build.sh, diffs, README files, etc.)
    are stored in the /djgpp directory. The sources have not been configured
    so you must change into the /djgpp directory and start build.sh. This will
    configure the sources and start make.

    For further information about Binutils please read the info docs and NEWS

    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 2021-01-16):

    Binutils 2.35.1 binaries, info and man format documentation:

    Binutils 2.35.1 bfd, liberty and opcode libraries and headers:

    Binutils 2.35.1 dvi, html, ps and pdf format documentation:

    Binutils 2.35.1 source:

    Send GNU binutils specific bug reports to <bug-binutils@gnu.org>.
    Send suggestions and bug reports concerning the DJGPP port to
    comp.os.msdos.djgpp or <djgpp@delorie.com>.


    Guerrero, Juan Manuel <juan.guerrero@gmx.de>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)