info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
ANNOUNCE: DJGPP port of GNU binutils 2.27 uploaded.
40 views
Skip to first unread message
![Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp-announce@delorie.com]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp-announce@delorie.com]
Aug 9, 2016, 4:03:26 PM8/9/16
to djgpp-a...@delorie.com
This is a port of GNU binutils 2.27 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 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.
Please note, that due to limitations inherent to DOS and memory ressources
not every file can be compiled. E.g.: to be able to compile a single file
containing up to 3 * 65536 relocations I had to increment stack space of
cc1.exe from 2MB to 10MB. If the file contains 4 * 65536 relocations then
cc1.exe aborts because memory has become exhausted. Neither as.exe nor
ld.exe have shown memory issues. Both have the standard stack space of
512KB. In other words, even if 32 bit values for relocation and line
counters are now supported by DJGPP port of as.exe and ld.exe it does not
imply that large files can be successfully compiled and linked. There are
memory limitations that may not be solvable.
OFYI how the DJGPP specifc support for number of relocations greater than
64K works:
- If the number of relocations of an object file exceeds 65534 then
s_nreloc in the section header is set to 65535 to signal the overflow
and the real number of relocations is stored in an extra COFF relocation
directive. This is always the first relocation directive in the sequence
of relocation directives of this object file. The 32 bit field r_vaddr
is used to store the real number of relocations. This extra relocation
directive is later removed. To signal this overflow also the
STYP_NRELOC_OVFL bit (0x01000000) is set in the s_flags field of the
section header.
- If the number of lines of an object file exceeds 65535 then the assembler
will abort with an error message. This can only happen if COFF debug info
is used. There is no work around for this issue.
- When the linker creates an executable file from the objects files and
the total number of lines exceeds 65535 the lower 16 bit of that value
will be stored in the s_nlnno field and the higher 16 bit in the s_nreloc
field of the section header of the executable file. This can only happen
if COFF debug info is used.
- The support of more than 64k relocations can be disable 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 linker script has been adapted to discard LTO sections created by the
compiler if the -flto flag is passed to the compiler. This is due to LTO
specific file names that are not 8.3 clean especially if the -save-temps
option is used. This may change in the future when the djgpp port of the
compiler fully supports LTO. A syntax error concerning the i386go32.xr and
i386go32.xu build-in linker scripts has also been fixed.
- 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:
libwithverylongname-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:
libwvln12.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.
- 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 diffs file stored in the /djgpp directory documents the DJGPP specific
changes. It has been splitt 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.
- 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 massive use of long file names it will not be possible to configure
and compile without LFN support. The port has been compiled using gcc346
and bnu2261b.
- The port has been tested by using it. I have used them only on WinXP.
It has worked flawlessly. I do not konw if this will ever be the case on
FreeDOS. I have never used/tested them in 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 file.
The port consists of the usual four packages that have been compiled
using djdev205 and that can be downloaded from ftp.delorie.com and
mirrors as (time stamp 2016-08-07):
Binutils 2.27 binary and info format documentation:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu227b.zip
Binutils 2.27 bfd, liberty and opcode libraries and headers:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu227a.zip
Binutils 2.27 dvi, html, ps and pdf format documentation:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu227d.zip
Binutils 2.27 source:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu227s.zip
Send binutils specific bug reports to <bug-bi...@gnu.org>.
Send suggestions and bug reports concerning the DJGPP port to
comp.os.msdos.djgpp or <dj...@delorie.com>.
Enjoy.
Guerrero, Juan Manuel <juan.g...@gmx.de>
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 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.
Please note, that due to limitations inherent to DOS and memory ressources
not every file can be compiled. E.g.: to be able to compile a single file
containing up to 3 * 65536 relocations I had to increment stack space of
cc1.exe from 2MB to 10MB. If the file contains 4 * 65536 relocations then
cc1.exe aborts because memory has become exhausted. Neither as.exe nor
ld.exe have shown memory issues. Both have the standard stack space of
512KB. In other words, even if 32 bit values for relocation and line
counters are now supported by DJGPP port of as.exe and ld.exe it does not
imply that large files can be successfully compiled and linked. There are
memory limitations that may not be solvable.
OFYI how the DJGPP specifc support for number of relocations greater than
64K works:
- If the number of relocations of an object file exceeds 65534 then
s_nreloc in the section header is set to 65535 to signal the overflow
and the real number of relocations is stored in an extra COFF relocation
directive. This is always the first relocation directive in the sequence
of relocation directives of this object file. The 32 bit field r_vaddr
is used to store the real number of relocations. This extra relocation
directive is later removed. To signal this overflow also the
STYP_NRELOC_OVFL bit (0x01000000) is set in the s_flags field of the
section header.
- If the number of lines of an object file exceeds 65535 then the assembler
will abort with an error message. This can only happen if COFF debug info
is used. There is no work around for this issue.
- When the linker creates an executable file from the objects files and
the total number of lines exceeds 65535 the lower 16 bit of that value
will be stored in the s_nlnno field and the higher 16 bit in the s_nreloc
field of the section header of the executable file. This can only happen
if COFF debug info is used.
- The support of more than 64k relocations can be disable 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 linker script has been adapted to discard LTO sections created by the
compiler if the -flto flag is passed to the compiler. This is due to LTO
specific file names that are not 8.3 clean especially if the -save-temps
option is used. This may change in the future when the djgpp port of the
compiler fully supports LTO. A syntax error concerning the i386go32.xr and
i386go32.xu build-in linker scripts has also been fixed.
- 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:
libwithverylongname-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:
libwvln12.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.
- 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 diffs file stored in the /djgpp directory documents the DJGPP specific
changes. It has been splitt 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.
- 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 massive use of long file names it will not be possible to configure
and compile without LFN support. The port has been compiled using gcc346
and bnu2261b.
- The port has been tested by using it. I have used them only on WinXP.
It has worked flawlessly. I do not konw if this will ever be the case on
FreeDOS. I have never used/tested them in 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 file.
The port consists of the usual four packages that have been compiled
using djdev205 and that can be downloaded from ftp.delorie.com and
mirrors as (time stamp 2016-08-07):
Binutils 2.27 binary and info format documentation:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu227b.zip
Binutils 2.27 bfd, liberty and opcode libraries and headers:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu227a.zip
Binutils 2.27 dvi, html, ps and pdf format documentation:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu227d.zip
Binutils 2.27 source:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu227s.zip
Send binutils specific bug reports to <bug-bi...@gnu.org>.
Send suggestions and bug reports concerning the DJGPP port to
comp.os.msdos.djgpp or <dj...@delorie.com>.
Enjoy.
Guerrero, Juan Manuel <juan.g...@gmx.de>
Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]
Aug 11, 2016, 5:51:54 PM8/11/16
to dj...@delorie.com
On 8/9/16, Juan Manuel Guerrero (juan.g...@gmx.de) [via
./bfd/.libs/libbfd.a(coff-go32.o): In function `coff_swap_scnhdr_in':
/b227/bfd/coffswap.h:775: undefined reference to `coff_64k_relocation_enabled'
./bfd/.libs/libbfd.a(coff-go32.o): In function `coff_swap_scnhdr_out':
/b227/bfd/coffswap.h:815: undefined reference to `coff_64k_relocation_enabled'
./bfd/.libs/libbfd.a(coff-go32.o): In function `coff_set_alignment_hook':
/b227/bfd/coffcode.h:1990: undefined reference to `coff_64k_relocation_enabled'
./bfd/.libs/libbfd.a(coff-stgo32.o): In function `_bfd_go32_mkobject':
/b227/bfd/coff-stgo32.c:454: undefined reference to
`coff_64k_relocation_enabled'
./bfd/.libs/libbfd.a(coff-stgo32.o): In function `coff_swap_scnhdr_in':
/b227/bfd/coffswap.h:775: undefined reference to `coff_64k_relocation_enabled'
./bfd/.libs/libbfd.a(coff-stgo32.o):/b227/bfd/coffswap.h:815: more
undefined references to `coff_64k_relocation_enabled' follow
collect2: ld returned 1 exit status
make[4]: *** [as-new] Error 1
This is because coff_64k_relocation_enabled is in init.c, __DJGPP__ is
not defined (because this is a cross build), nor are COFF_GO32* defined
not as far as init.c knows, as those are defined only in coff-go32.c and
init.c cannot know such a thing. I do not have a patch for fixing this
mess, yet.
--
O.S.
djgpp-a...@delorie.com] <djgpp-a...@delorie.com> wrote:
> This is a port of GNU binutils 2.27 to MSDOS/DJGPP.
[...]
> This is a port of GNU binutils 2.27 to MSDOS/DJGPP.
> - The support of more than 64k relocations can be disable by defining the
> DISABLE_64K_RELOC_SUPPORT environment variable to either y or Y.
Building this as part of a djgpp cross-toolchain fails:
> DISABLE_64K_RELOC_SUPPORT environment variable to either y or Y.
./bfd/.libs/libbfd.a(coff-go32.o): In function `coff_swap_scnhdr_in':
/b227/bfd/coffswap.h:775: undefined reference to `coff_64k_relocation_enabled'
./bfd/.libs/libbfd.a(coff-go32.o): In function `coff_swap_scnhdr_out':
/b227/bfd/coffswap.h:815: undefined reference to `coff_64k_relocation_enabled'
./bfd/.libs/libbfd.a(coff-go32.o): In function `coff_set_alignment_hook':
/b227/bfd/coffcode.h:1990: undefined reference to `coff_64k_relocation_enabled'
./bfd/.libs/libbfd.a(coff-stgo32.o): In function `_bfd_go32_mkobject':
/b227/bfd/coff-stgo32.c:454: undefined reference to
`coff_64k_relocation_enabled'
./bfd/.libs/libbfd.a(coff-stgo32.o): In function `coff_swap_scnhdr_in':
/b227/bfd/coffswap.h:775: undefined reference to `coff_64k_relocation_enabled'
./bfd/.libs/libbfd.a(coff-stgo32.o):/b227/bfd/coffswap.h:815: more
undefined references to `coff_64k_relocation_enabled' follow
collect2: ld returned 1 exit status
make[4]: *** [as-new] Error 1
This is because coff_64k_relocation_enabled is in init.c, __DJGPP__ is
not defined (because this is a cross build), nor are COFF_GO32* defined
not as far as init.c knows, as those are defined only in coff-go32.c and
init.c cannot know such a thing. I do not have a patch for fixing this
mess, yet.
--
O.S.
Andrew Wu (andrewwu.tw@gmail.com) [via djgpp@delorie.com]
Feb 2, 2017, 3:06:26 AM2/2/17
to dj...@delorie.com
I think this patch for gnu/binutils-2.27/bfd/init.c can fix the cross
build problem :
=================
--- init.c.bak 2017-01-31 19:11:07.478074684 +0000
+++ init.c 2017-01-31 19:24:23.798041848 +0000
@@ -25,9 +25,7 @@
/* This controls if the coff 64k support shall be disabled or not.
By default always enabled. */
-#if defined(__DJGPP__) || defined(COFF_GO32_EXE) || defined(COFF_GO32)
bfd_boolean coff_64k_relocation_enabled = TRUE;
-#endif
/*
SECTION
=================
This patch always defines the global variable
coff_64k_relocation_enabled . Tested on Linux and OSX.
2016-08-12 5:51 GMT+08:00 Ozkan Sezer (sez...@gmail.com) [via
dj...@delorie.com] <dj...@delorie.com>:
build problem :
=================
--- init.c.bak 2017-01-31 19:11:07.478074684 +0000
+++ init.c 2017-01-31 19:24:23.798041848 +0000
@@ -25,9 +25,7 @@
/* This controls if the coff 64k support shall be disabled or not.
By default always enabled. */
-#if defined(__DJGPP__) || defined(COFF_GO32_EXE) || defined(COFF_GO32)
bfd_boolean coff_64k_relocation_enabled = TRUE;
-#endif
/*
SECTION
=================
This patch always defines the global variable
coff_64k_relocation_enabled . Tested on Linux and OSX.
2016-08-12 5:51 GMT+08:00 Ozkan Sezer (sez...@gmail.com) [via
dj...@delorie.com] <dj...@delorie.com>:
> On 8/9/16, Juan Manuel Guerrero (juan.g...@gmx.de) [via
> djgpp-a...@delorie.com] <djgpp-a...@delorie.com> wrote:
>> This is a port of GNU binutils 2.27 to MSDOS/DJGPP.
> [...]
>> - The support of more than 64k relocations can be disable by defining the
>> DISABLE_64K_RELOC_SUPPORT environment variable to either y or Y.
>
> Building this as part of a djgpp cross-toolchain fails:
>
> ../bfd/.libs/libbfd.a(coff-go32.o): In function `coff_swap_scnhdr_in':
> djgpp-a...@delorie.com] <djgpp-a...@delorie.com> wrote:
>> This is a port of GNU binutils 2.27 to MSDOS/DJGPP.
> [...]
>> - The support of more than 64k relocations can be disable by defining the
>> DISABLE_64K_RELOC_SUPPORT environment variable to either y or Y.
>
> Building this as part of a djgpp cross-toolchain fails:
>
> /b227/bfd/coffswap.h:775: undefined reference to `coff_64k_relocation_enabled'
> ../bfd/.libs/libbfd.a(coff-go32.o): In function `coff_swap_scnhdr_out':
> /b227/bfd/coffswap.h:815: undefined reference to `coff_64k_relocation_enabled'
> ../bfd/.libs/libbfd.a(coff-go32.o): In function `coff_set_alignment_hook':
> /b227/bfd/coffcode.h:1990: undefined reference to `coff_64k_relocation_enabled'
> ../bfd/.libs/libbfd.a(coff-stgo32.o): In function `_bfd_go32_mkobject':
> /b227/bfd/coff-stgo32.c:454: undefined reference to
> `coff_64k_relocation_enabled'
> ../bfd/.libs/libbfd.a(coff-stgo32.o): In function `coff_swap_scnhdr_in':
> `coff_64k_relocation_enabled'
> /b227/bfd/coffswap.h:775: undefined reference to `coff_64k_relocation_enabled'
> ../bfd/.libs/libbfd.a(coff-stgo32.o):/b227/bfd/coffswap.h:815: more
Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp@delorie.com]
Feb 2, 2017, 7:04:43 AM2/2/17
to dj...@delorie.com
Am 02.02.2017 08:41, schrieb Andrew Wu (andre...@gmail.com) [via dj...@delorie.com]:
> I think this patch for gnu/binutils-2.27/bfd/init.c can fix the cross
> build problem :
>
> =================
> --- init.c.bak 2017-01-31 19:11:07.478074684 +0000
> +++ init.c 2017-01-31 19:24:23.798041848 +0000
> @@ -25,9 +25,7 @@
>
> /* This controls if the coff 64k support shall be disabled or not.
> By default always enabled. */
> -#if defined(__DJGPP__) || defined(COFF_GO32_EXE) || defined(COFF_GO32)
> bfd_boolean coff_64k_relocation_enabled = TRUE;
> -#endif
>
> /*
> SECTION
> =================
>
> This patch always defines the global variable
> coff_64k_relocation_enabled . Tested on Linux and OSX.
>
[snip]
> I think this patch for gnu/binutils-2.27/bfd/init.c can fix the cross
> build problem :
>
> =================
> --- init.c.bak 2017-01-31 19:11:07.478074684 +0000
> +++ init.c 2017-01-31 19:24:23.798041848 +0000
> @@ -25,9 +25,7 @@
>
> /* This controls if the coff 64k support shall be disabled or not.
> By default always enabled. */
> -#if defined(__DJGPP__) || defined(COFF_GO32_EXE) || defined(COFF_GO32)
> bfd_boolean coff_64k_relocation_enabled = TRUE;
> -#endif
>
> /*
> SECTION
> =================
>
> This patch always defines the global variable
> coff_64k_relocation_enabled . Tested on Linux and OSX.
>
The goal of those lines is pretty clear; it shall identify and isolate
DJGPP specific changes that will never find their way into binutils.
But I have no objections in removing those lines if it works.
Regards,
Juan M. Guerrero
0 new messages