Mail Archives: djgpp-announce/2014/04/19/21:38:55
This is a port of GNU binutils 2.24 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.
=======================
- This port update provides a version of the linker that will be capable
to resolve multiple symbol definitions conflicts when using DXE3 modules.
Multiple symbol definition always occur 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 dxe_tmp.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 run-time 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 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 run-time 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 and the
linker creates an executable in the usual way.
The linker version with this feature has been compiled using a freshly
compiled version of libc.a from the CVS repository. You can download
an archive of the repository tree at:
<http://www.ludd.luth.se/~ams/djgpp/cvs/djgpp.cvs.tar.gz>
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 gettext-0.18.3.2 that provide libraries with file
names that cannot be uniquely mapped to short file names without using
numeric tails. Usually in this case the files are renamed so they have
a valid short file name without having to use numeric tails. The
consequence 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 fails, 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 successful it
will try to load that file instead of the original one and if this was
also successful 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 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 same 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:
verylongname-1.2 vln12
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:
libverylongname-1.2.a
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:
libvln12.a
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.
- Some mounths ago a user complaint about the amount of file handles consumed
by the ar program. 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 on eight of this value but at least 10 and opens so much files
as required. If your FILES entry in config.sys is not large enough (at
least around 35) then the program aborts. To determinate the real number
of free file handles the specific BFD function has been modified to create
a temporary directory and open as much files as possible. This will be
the value used as RLIMIT_NOFILE to determinate the maximum of available
file handles. If this fails at least 10 file handles must be available
or the program will abort.
- For all other DJGPP specific changes see:
<http://www.delorie.com/archives/browse.cgi?p=djgpp-announce/2013/12/10/12:22:26>
To compile the sources you will need LFN support. I have compiled on
WinXP Prof SP3. I have not tried to compile the sources using any other
Windows version. Especially I have not tried to compile it on plain DOS.
To be able to configure and compile using djgpp 2.03 it will be necessary
to replace cat.exe and sort.exe with the versions compiled with djgpp 2.04.
As usual, all djgpp specific files (build.sh, diffs, README files, etc.)
are located 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 file.
The port consists of the usual four packages that have been compiled
using stock djdev203 and that can be downloaded from ftp.delorie.com
and mirrors as (time stamp 2014-04-19):
GNU binutils 2.24 binary and info format documentation:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu224br2.zip
GNU binutils 2.24 bfd, liberty and opcode libraries and headers:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu224ar2.zip
GNU binutils 2.24 dvi, html, ps and pdf format documentation:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu224dr2.zip
GNU binutils 2.24 source:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu224sr2.zip
The binaries have been produced a second time using a freshly compiled
version of libc.a from the CVS repository. This package is available
at ftp.delorie.com and mirrors as (time stamp 2014-04-19):
GNU binutils 2.24 binary and info format documentation:
ftp://ftp.delorie.com/pub/djgpp/beta/v2gnu/bnu224br2.zip
GNU binutils 2.24 bfd, liberty and opcode libraries and headers:
ftp://ftp.delorie.com/pub/djgpp/beta/v2gnu/bnu224ar2.zip
Send binutils specific bug reports to <bug-binutils AT gnu DOT org>.
Send suggestions and bug reports concerning the DJGPP port to
comp.os.msdos.djgpp or <djgpp AT delorie DOT com>.
Enjoy.
Guerrero, Juan Manuel <juan DOT guerrero AT gmx DOT de>
- Raw text -