This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Out of date GNU binutils, and (slightly) broken binutils 2.27


I've been responsible for porting a large [primarily] C++ project from 
Linux to Cygwin. This project generates object files at one point in the 
build process which exceed the object file symbol count limit (around 
32k, but if I recall correctly there was actually a binutils bug 
limiting this further to 16k). As such, I needed an assembler and linker 
that supported the windows big-obj format. That was added in more recent 
versions of GNU binutils, however the version that is available in the 
Cygwin repository is discouragingly old. So the first point I want to 
make is to ask whether the maintainers of Cygwin binutils can be pinged 
to update the supported version, or to know why the last supported 
version is from 2014 (is there something that breaks with newer versions?).

The next step I took was to get a recent version (2.27) that does 
support big-obj, compile it on the system, point gcc toward that 
installation, and try to proceed from there. This fixed the big-obj 
issue, and for the most part lots of the sub-projects were working just 
fine. But one sub-project in particular is having an issue: the 
resulting binary (a dll, in this case) has a flaw in the import lookup 
table (.idata subsection). The import lookup table of one 
runtime-dependent DLL is overwriting the null entry that *ends* the 
previous DLL's table. So, the previous DLL tries to link with a symbol 
that is actually contained in the other DLL, while the other DLL still 
correctly points to needing that symbol as well. In other words, this 
makes it impossible to use the resulting DLL, because it has a dependent 
symbol that will never be resolved correctly. It's worth noting that 
lots of other things link correctly without this bug, and other DLLs 
within that file do not have import lookup tables that overrun each 
other. I thought it would be reasonable to send to this mailing list 
because, from what I read in the binutils source, it seemed like most of 
the pe/pe+ code that has been added to binutils was from Cygwin 
developers. I tried to find the root of the problem, but after hours of 
searching and debugging the linker and BFD code, I haven't found the 
source of the discrepancy.

Any advice would be greatly appreciated!
-Alex Franchuk
Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]